T.R | Title | User | Personal Name | Date | Lines |
---|
868.1 | I have the same problem, any solution | DAVIDR::WALKER | | Wed Jun 14 1989 14:28 | 8 |
| I am experiencing scenario #1 on both VAXstation 2000 satellites of
a LAVC (uVAX II boot member). Has there been any resolution of the problem?
I'm to add add'l VS2000's and will be switching to a uVAX3800 boot member.
Will I have the same problem?
-d
|
868.2 | Still a mystery... | TRLIAN::CROGERS | Chris Rogers - DTN 264-4254 | Wed Jun 14 1989 15:03 | 10 |
| No, I have yet to find a solution - I do know that other people
are running into it, though. One person found that by replacing
DCLTABLES.EXE on the boot node after an application installation
solved it (so far). This doesn't fit the pattern here, although
the problem seems to go away for a few days after a full cluster
reboot, coming back with a vengeance.
I'm hoping that someone in DECwindows-land will be able
to shed more light on this...
|
868.3 | I'm having a similar problem... | JCR::RZUCIDLO | John Rzucidlo - INDEC New Products | Fri Jun 16 1989 15:05 | 122 |
| My problem is similar in that I get a SM crash and process stack dump,
but I have a standalone mayfair/GPX, not in a LAVc, and my traceback dump addresses
are different. I have big quotas, and ocassionally, the SM says "duplicate process
name" in an error box... any ideas?
jr
-------------------------------------------------------------------------------
%SET-I-NEWLIMS, new working set: Limit = 200 Quota = 200 Extent = 5000
$begin:=spawn/nowait/input=nl:
$! DECW$LOGIN.COM
$!
$ if f$trnlnm("decw$display") .eqs. "" then exit
$ @dua0:[rzucidlo.commands]logical.com
$!
$ card := $decw$cardfiler
$ define/user card$ disk$sdd_user:[rzucidlo]
$ begin /process="ROLODEX..." -
CARD card$:cardfiler.card
%DCL-S-SPAWNED, process ROLODEX... spawned
$!
$ begin /process="EDITOR..." -
EDIT -
/TPU -
/SECTION=DISK$SDD_USER:[RZUCIDLO.TPU]WS_EVEPLUS.TPU$SECTION -
/DISPLAY=DECWINDOWS
%DCL-S-SPAWNED, process EDITOR... spawned
$!
$ begin /process="MAIL..." -
RUN SYS$SYSTEM:DECW$MAIL
%DCL-S-SPAWNED, process MAIL... spawned
$!
$ begin /process="CALENDAR..." -
! RUN SYS$SYSTEM:DECW$CALENDAR
@dua1:[dw_calendar_v2]decw$calendar_start
%DCL-S-SPAWNED, process CALENDAR... spawned
$!
$! begin /process="BOOKREADER..." -
! RUN SYS$SYSTEM:DECW$BOOKREADER
$!
$ begin /process="NOTES..." -
NOTES
%DCL-S-SPAWNED, process NOTES... spawned
$ Loc = F$Environment( "Procedure" )
$ Loc = F$Parse( Loc,,,"Device" ) + F$Parse( Loc,,,"Directory" )
$ Define/User DECW$CALENDAR_PROLOG DUA1:[DW_CALENDAR_V2]DECW$CALENDAR_PROLOG.PS
$ Define/User SYS$HELP DUA1:[DW_CALENDAR_V2]
$ Define/User DECW$SYSTEM_DEFAULTS DUA1:[DW_CALENDAR_V2]
$ Run/NoDebug DUA1:[DW_CALENDAR_V2]DECW$CALENDAR
$EXIT
$ !
$ ! DECW$STARTSM.COM - Initialize the DECwindows session manager
$ !
$ !****************************************************************************
$ !* *
$ !* COPYRIGHT (c) 1987 BY *
$ !* DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS. *
$ !* ALL RIGHTS RESERVED. *
$ !* *
$ !* THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED *
$ !* ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE *
$ !* INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER *
$ !* COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY *
$ !* OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY *
$ !* TRANSFERRED. *
$ !* *
$ !* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE *
$ !* AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT *
$ !* CORPORATION. *
$ !* *
$ !* DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS *
$ !* SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. *
$ !* *
$ !* *
$ !****************************************************************************
$ !
$ ! This command procedure sets up the DECwindows session manager
$ ! development environment.
$ ! It is not advisable to edit this procedure as it may be replaced in
$ ! future software updates.
$ !
$! if no command files executed, then status will be blank
$!
$if $status .EQS. "" then goto do_session
$!
$! if status is ok, no errors in command procedures, so start session manager
$!
$if $status then goto do_session
$do_session:
$define decw$doing_session T
$run sys$system:decw$session
Session Message: Started DECterm controller
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=7FF13400, PC=000CBDC1, PSL=0BC00
Improperly handled condition, image exit forced.
Signal arguments Stack contents
Number = 00000005 00000000
Name = 0000000C 20FC0000
00000004 00007FF0
7FF13400 7FF124E0
000CBDC1 0000BEED
0BC00009 7FF12790
00001538
00000000
00000000
00000001
Register dump
R0 = 06007084 R1 = 7FF12430 R2 = 00000000 R3 = 7FF13400
R4 = FFFF8011 R5 = 000000CE R6 = 00007FEF R7 = 00007FEF
R8 = 0000156E R9 = 0020D0C6 R10= 000F47B8 R11= 00000000
AP = 7FF123F4 FP = 7FF123B4 SP = 7FF12430 PC = 000CBDC1
PSL= 0BC00009
RZUCIDLO logged out at 16-JUN-1989 13:45:55.80
|
868.4 | QAR time, I'd say | HANNAH::MESSENGER | Bob Messenger | Fri Jun 16 1989 16:42 | 10 |
| Re: .3 etc.
Have these problems been QARed? There seems to be a non-trivial amount of
work needed to investigate them.
I admit that it's suspicious that in both cases the last message before
the crash was "starting DECterm controller"...
-- Bob
|
868.5 | slightly different DECterm problems | SALSA::MOELLER | Never say 'forget it' to a computer. | Thu Jun 22 1989 17:27 | 22 |
| I found this topic and 861.. I'm having some DECterm troubles that
don't quite match any mentioned so far. On a VS2000 monochrome,
14MB memory, VMS 5.1B. 20,000 block pagefile, 20,000 block PGFLQUOTA
for each account.
My typical screen has 2 DECterms, one of which is SET HOST to another
system in the building, clock and calculator. Every few days the
DECterms will stop accepting input, keyboard or mouse, and then
disappear. Fileview stays active, and all I have to do is request
DECterms windows again. After they crash, and before I re-request,
the Session Manager window shows :
DECterm controller process stopped
message number 12DB821C
started DECterm controller
.. when, of course, there is no DECterm controller running. I took
a quick look at note 537.1 and believe the system params are set
correctly, but will check again.
karl moeller SWS Tucson AZ
|
868.6 | ULTRIX .Xdefaults -> VMS decw$sm_general.dat | TOWNS::BAGWILL | Zenzen wakarimasen. | Thu Sep 14 1989 20:49 | 8 |
| I copied my ULTRIX .Xdefaults file to decw$sm_general.dat, and told the SM to
[Use Last Saved Settings] and it crashed. How robust is the SM?
I notice that there is also a decw$sm_color.dat file. Do all color-related
attributes have to be in there? Sorry if this has been discussed before, or is
documented in copious detail SOMEWHERE IN THE MANUALS.
Bob Bagwill
|
868.7 | | STAR::ORGOVAN | Vince Orgovan | Fri Sep 15 1989 20:25 | 17 |
| > I copied my ULTRIX .Xdefaults file to decw$sm_general.dat, and
> told the SM to [Use Last Saved Settings] and it crashed. How robust
> is the SM?
It is easy to break DECwindows applications with bogus resource
files. The rules are: play with anything you like, but if it breaks
be prepared to back out your last change.
> I notice that there is also a decw$sm_color.dat file. Do all
> color-related attributes have to be in there? Sorry if this has
> been discussed before, or is documented in copious detail SOMEWHERE
> IN THE MANUALS.
You should try copying your Ultrix .Xdefaults file to
decw$user_defaults:decw$xdefaults.dat. This isn't documented on VMS
systems precisely because it isn't robust.
|