Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: VMS V4.0 gotcha
Message-ID: <5391@ucbvax.ARPA>
Date: Sat, 9-Mar-85 16:38:45 EST
Article-I.D.: ucbvax.5391
Posted: Sat Mar  9 16:38:45 1985
Date-Received: Sun, 10-Mar-85 07:39:23 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 25

From: Gail Rubin 

I wouldn't consider something as well documented as the SET UIC not
affecting your group logical name table change to be a 'Gotcha'.  I heard
about it MANY times; at DECUS, at the Upgrade course, in the release notes.
They explicitly mentioned that this would affect systartup's that used SET
UIC and ASSIGN to fill group logical name tables and told of the workaround
of SUBMIT. I'm surprised you managed to not see any info on this before. 

Which group logical name table you are associated with is set at
login based on your uic. It does not change when you change your
uic. In fact, there is a logical name (LNM$GROUP) which is
in the logical name table LNM$PROCESS_DIRECTORY which points
to your group logical name table. You can actually re-assign
this logical name if you want to. However, group logical name tables are
only created when a user with a uic in that group logs in. You can,
if you change your uic to one in a different group, manage to lose
access to your own group and job logical name tables, which can
result in some pretty strange behavior if you don't have sysprv or
bypass. This is because logical name tables have protection, and the
job one has no access for group and world, and the group one has no
access for world.

-- Gail Rubin
(grubin@bbn-spca or @bbn-unix)