| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 201.1 | More questions/problems | RDGENG::PRATT | | Mon Jul 23 1990 16:16 | 12 |
| Further investigation suggests that although I can open two windows into 2
different domains I can only actually use one window - and if I drop out of one
window and then try to fire it up again then it fails with
PHASE5_Ian>manag/enterpr/inter=decwindow
X Toolkit Error: Can't Open display
%DWT-F-DWTABORT, xtoolkit fatal error
%DWT-E-DWTABORT, xtoolkit fatal error
Question - Are multiple users/windows supported in this release of MCC?
Ian
|
| 201.2 | Try increasing your account quotas... | POLE::LEMMON | | Mon Jul 23 1990 20:13 | 18 |
| I have noticed this behavior in the past. MCC appears to use more
memory when logged in via a set host. Why it does is unclear to me.
I suggest you set your account quotas (and anyone else who is running
mcc) to the following:
Maxjobs: 0 Fillm: 64 Bytlm: 32768
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 40 JTquota: 1024
Prclm: 10 DIOlm: 40 WSdef: 256
Prio: 4 ASTlm: 100 WSquo: 3000
Queprio: 0 TQElm: 128 WSextent: 8000
CPU: (none) Enqlm: 600 Pgflquo: 32768
I am able to run the iconic map from a remote terminal successfully
with these values.
/Jim
|
| 201.3 | Need more info.... | POLE::LEMMON | | Mon Jul 23 1990 20:20 | 17 |
| re: .2
I need more info. Are you running mcc, opening two domains,
and on the second open you get the can't open display error message?
Or are you running mcc from two decterm windows at the same time?
The can't open display error message appears when the xwindow client
is unable to connect to the server. This could be caused by
insufficient priviledges (Select "Security" from the session manager
customize pulldown menu). Other causes are the server doesn't have
the clients node info in it's database, or the display wasn't set
prior running mcc (e.g., SET DISPLAY/NODE=node/CREATE). The last
two only apply if you set host to the system running MCC and want
the output to be displayed on your workstation.
/Jim
|
| 201.4 | Quotas look okay to me | RDGENG::PRATT | | Tue Jul 24 1990 11:22 | 97 |
| Jim,
My account has the following quotas...
Maxjobs: 0 Fillm: 100 Bytlm: 200000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 50 JTquota: 1024
Prclm: 90 DIOlm: 50 WSdef: 512
Prio: 4 ASTlm: 1000 WSquo: 4000
Queprio: 0 TQElm: 1000 WSextent: 12288
CPU: (none) Enqlm: 3000 Pgflquo: 60000
Authorized Privileges:
CMKRNL CMEXEC SYSNAM GRPNAM ALLSPOOL DETACH DIAGNOSE LOG_IO
GROUP ACNT PRMCEB PRMMBX PSWAPM ALTPRI SETPRV TMPMBX WORLD
OPER EXQUOTA NETMBX VOLPRO PHY_IO BUGCHK PRMGBL SYSGBL MOUNT
PFNMAP SHMEM SYSPRV BYPASS SYSLCK SHARE GRPPRV READALL
SECURITY
Default Privileges:
TMPMBX NETMBX
Which are all equal to or greater than the values specified. I have carried out
some more tests today and the problem doesn't appear to be confined to the
iconic pm.
The first session is from a local Fileview session on my workstation...
PHASE5_Ian>manag/enterpr
DECmcc (T1.0.1)
MCC> show node4 phase5 all coun
Node4 42.629
Counters
AT 24-JUL-1990 11:46:25
Examination of Attributes shows:
Seconds Since Last Zeroed = 65535 Seconds
User Bytes Received = 1407982 Bytes
User Bytes Sent = 1407853 Bytes
Total Messages Received = 8418 Messages
Total Messages Sent = 8461 Messages
Connects Received = 43 Connects
Connects Sent = 43 Connects
Response Timeouts = 0 Timeouts
Received Connect Resource Errors = 0
Maximum Logical Links Active = 15 Links
Aged Packet Loss = 0 Packets
Node Unreachable Packet Loss = 0 Packets
Node Out-of-Range Packet Loss = 0 Packets
Oversized Packet Loss = 0 Packets
Packet Format Error = 0
Partial Routing Update Loss = 0
Verification Reject = 0
MCC>
The second session is a SET HOST into my workstation...
PHASE5_Ian>manag/enter
DECmcc (T1.0.1)
MCC> show node4 phase5 all count
%MCC-E-DEFNOTREGISTRD, Definition not registered
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=4013ED14, PC
=000AA587, PSL=03C00000
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC
=0000000A, PSL=0000000F
PHASE5_Ian>
I also get similiar errors using the PhaseV am remotely.
I am running V5.3, and the only 'unsupported' s/w on my workstation is the V2.0
DNS clerk from the phaseV migration tools - my workstation is also a DNS server
with a private namespace. I don't think that this is a DNS problem, but I can go
back to the V1.1 clerk if that is any help.
Re .1
The problems I had were that I could have 2 windows open - one on my workstation
and another one pushed out to another workstation. The window that had been
pushed out was unable to open a previously created domain - I forget the exact
error message but it was along the lines of 'no such entity' (it could create
new domains okay though). I then found out that if I exited from MCC on my
workstation (but with the window still open on the remote workstation) then I
couldn't fire up the window again on my own workstation.
PHASE5_Ian>manag/enterpr/inter=decwindow
X Toolkit Error: Can't Open display
%DWT-F-DWTABORT, xtoolkit fatal error
%DWT-E-DWTABORT, xtoolkit fatal error
The only way to do it was to close the remote window first, and then it would be
okay after that. If you want more information /error messages then I will be
happy to provide them - but maybe if we resolve the above problem then the
windows will work okay as well.
Ian
|
| 201.5 | re .4 | POLE::LEMMON | | Thu Jul 26 1990 14:51 | 65 |
|
re .4
>>The second session is a SET HOST into my workstation...
>>
>>PHASE5_Ian>manag/enter
>>DECmcc (T1.0.1)
>>
>>MCC> show node4 phase5 all count
>>%MCC-E-DEFNOTREGISTRD, Definition not registered
>>%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=4013ED14, PC
>>=000AA587, PSL=03C00000
>>%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC
>>=0000000A, PSL=0000000F
It appears that setting host to a system and running MCC uses
up more resources than logging into the account directly.
How or why is unclear to me at this time.
It is possible to see exactly where it is crapping out by defining the
logical MCC_LOG to be 12. By doing this MCC will print out the calls
being made across the interface. Please set host/log, define the logical,
and then mail me the log file (BARREL::LEMMON).
>>I am running V5.3, and the only 'unsupported' s/w on my workstation is the V2.0
>>DNS clerk from the phaseV migration tools - my workstation is also a DNS server
>>with a private namespace. I don't think that this is a DNS problem, but I can go
>>back to the V1.1 clerk if that is any help.
Send mail to Pat Mulligan (TOOK::MULLIGAN) asking her if this is a
problem. Please post the answer here.
>>re .1
>>
>>The problems I had were that I could have 2 windows open - one on my workstation
>>and another one pushed out to another workstation. The window that had been
>>pushed out was unable to open a previously created domain - I forget the exact
>>error message but it was along the lines of 'no such entity' (it could create
>>new domains okay though). I then found out that if I exited from MCC on my
>>workstation (but with the window still open on the remote workstation) then I
>>couldn't fire up the window again on my own workstation.
>>
>>PHASE5_Ian>manag/enterpr/inter=decwindow
>>X Toolkit Error: Can't Open display
>>%DWT-F-DWTABORT, xtoolkit fatal error
>>%DWT-E-DWTABORT, xtoolkit fatal error
>>The only way to do it was to close the remote window first, and then it would be
>>okay after that. If you want more information /error messages then I will be
>>happy to provide them - but maybe if we resolve the above problem then the
>>windows will work okay as well.
I want to make sure I got this right. You were RUNNING mcc on the
same workstation with the output of one MCC going to the
workstation itself, the other going to another workstation because
you did a SET DISPLAY/NODE=node/CREATE. Both MCCs running were
using the the same DNS namespace. I will see if I can
duplicate that here.
/Jim
|
| 201.6 | I don't believe the error message! | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Mon Jul 30 1990 11:53 | 38 |
| I am seeing the same "insufficient virtual memory" error that Ian is. I am
trying to run MCC on a large timesharing system (that possibly has someone
else also trying to use it). I have SET DISPLAY back to my workstation. I
am using LAT to log in to the cluster.
I do not believe that the problem is really a resource problem. I have very
large quotas and the system has a very large pagefile and high
VIRTUALPAGCNT.
Here is the error:
$ manage/enter/int=decw
%MCC-E-OUTOFMEM, insufficient virtual memory available to MCC
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=00000007, PC=000D7E43, PSL=03C00004
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual
address=0000000A, PC=0000000A, PSL=0000000F
Here are my process quotas:
$ show proc/quot
30-JUL-1990 12:43:05.11 User: COBB Process ID: 2B00026B
Node: KRIKIT Process name: "Graham "
Process Quotas:
Account name: PSI
CPU limit: Infinite Direct I/O limit: 100
Buffered I/O byte count quota: 49136 Buffered I/O limit: 100
Timer queue entry quota: 40 Open file quota: 60
Paging file quota: 148209 Subprocess quota: 10
Default page fault cluster: 64 AST quota: 98
Enqueue quota: 2000 Shared file limit: 0
Max detached processes: 0 Max active jobs: 0
I tried defining MCC_LOG to be 12 but I didn't get any extra output.
Graham
|
| 201.7 | File protection | MARVIN::COBB | Graham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917 | Tue Jul 31 1990 12:31 | 28 |
| My problem was nothing to do with quotas or terminal types. It was
privileges/file protection. I got the OUTOFMEM error and ACCVIOs if I just
had TMPMBX and NETMBX but if I turned on SYSPRV they went away! See the
following terminal output:
$ set proc/priv=(noall,netmbx,tmpmbx)
$ manage/ent/interf=decw
%MCC-E-OUTOFMEM, insufficient virtual memory available to MCC
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=00000007, PC=000D7E43, PSL=03C00004
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual
address=0000000A, PC=0000000A, PSL=0000000F
$
$ set proc/priv=(noall,netmbx,tmpmbx,sysprv)
$ manage/ent/interf=decw
%MCC-E-ABORTCTRLY, Image aborted by Ctrl\y
[it worked and I used ^Y to get out]
Using security auditing I was able to determine that the file it can't
access is MCC_META_DEFINITION.DAT -- it has no world access. Should it be
W:RE? I don't know if the problem is a bug in the installation procedures or
whether the person who installed MCC caused it to be changed.
Graham
P.S. small but still very annoying bug: the text for the ABORTCTRLY message
starts with a capital letter. It shouldn't: VMS deals with the necessary
capitalisation for the first letter of a message.
|
| 201.8 | V10 file protections | GOSTE::CALLANDER | | Tue Jul 31 1990 14:18 | 8 |
| HO BOY...
We just did some re-evaluation of the default privileges found on
files after installation. The dictionary files (of which the meta
file is one) we supposed to be changed to world readable. This is
a good example as to why this is useful. I wil check to see that
this file was one of the ones changed.
|
| 201.9 | DEFNOTREGISTRD error is a bug | TOOK::GUERTIN | Wherever you go, there you are. | Tue Jul 31 1990 17:59 | 20 |
| The dictionary lookup routines calls an initialization routine which it
declares as a void function (Pascal equivalent of a Procedure). In
fact, the routine may return the status of a failure to open the
mcc_meta_definition.dat file (if there is a protection problem, for
example). Not realizing that there is an error, the Dictionary routines
continue to access the dictionary as if everything is okay. The result is
the following error messages:
%MCC-E-DEFNOTREGISTRD, Definition not registered
%MCC-E-OUTOFMEM, insufficient virtual memory available to MCC
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000007, PC
=000E37E4, PSL=03C00004
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC
=0000000A, PSL=0000000F
This is a bug and will be fixed as soon as it can be. However, the
meta files have ALWAYS been installed as world:read. I am curious how
they got to be no world access.
-Matt.
|
| 201.10 | ouch that hurts... | SMAUG::BELANGER | Quality is not a mistake! | Wed Aug 01 1990 21:32 | 15 |
|
To add insult to injury, I did an experiment (with Jim Lemmon)
where I set hosted from his workstation to mine. When I started
DECmcc (/interface=decwindows), I got the insufficient memory problem.
When I set hosted again to my workstation, from the previous set host
session, everything worked fine (no insufficient memory errors). So
what I did was:
jims ws> SET HOST jons_ws
jons ws> SET HOST 0
jons_ws> mana/ent/i=d
Go figure.
~Jon.
|
| 201.11 | | NSSG::R_SPENCE | Nets don't fail me now... | Thu Aug 02 1990 19:10 | 7 |
| I am fairly sure that the file protection changes were intentional.
The release notes discuss this (I don't have a copy handy to check
though) and reccomend that protections or ACLs be used to GRANT
appropriate access to MCC files since the default kit doesn't make
them WORLD avaialable.
s/rob
|