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 RubinI 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)