info-vax@ucbvax.ARPA (03/07/85)
From: Richard Garland <OC.GARLAND%CU20B@COLUMBIA.ARPA> Gotcha: SET TERM/VT100 no longer sets /HOSTSYNCH by default. This can lead to a number of changes in behavior and we had a few job failures (Data overrun's) before discovering this and setting /HOSTSYNCH explicitly when needed. Rg -------
info-vax@ucbvax.ARPA (03/09/85)
From: Richard Garland <OC.GARLAND@CU20B.ARPA> 'nother gotcha: Changing UIC via the command "SET UIC [m,n]" no longer provides access to the group logical names of group n. Example: In our SYSTARTUP file, in V3.x we use to set up a bunch of group logical names for several groups with code like the following: . . $ SET UIC [100,0] $ DEFINE/GROUP FOO BAR $ DEFINE/GROUP ASH CAN $ SET UIC [170,0] $ DEFINE/GROUP TWEEDLE DEE $ DEFINE/GROUP DUMDEE DUMDUM . . $ SET UIC [1,4] . (rest of SYSTARTUP.COM) Then these various logical names would be available to members of these groups. Under VMS V4.0, these logical names are all put into the group logical name table for [1,4] - i.e. the "SET UIC" command no longer switches group logical name tables. This apparently has to do with the new complicated logical name structure and I don't know whether to call this a feature or a bug. Workaround: Another V4.0 feature provides a workaround - the SUBMIT command has a "/USERNAME" qualifier allowing a privileged user to submit a batch job on behalf of another user. So to set up the group names desired you must: 1) have a user in the appropriate group with GRPNAM privilege (say a user called GROUPGURU). 2) create a command file with the various /GROUP assignments for that group (say GROUPNAMES.COM). 3) Submit the file as a batch job on behalf of the user: $ SUBMIT/USERNAME=GROUPGURU GROUPNAMES This submit command replaces the other lines in SYSTARTUP.COM (don't forget to start the batch queues first). It works. The diagnosis and workaround were provided by Carl Friedberg (Seaport Systems) who recalls picking it up in a VMS V4.0 seminar sometime ago. Rg -------
info-vax@ucbvax.ARPA (03/10/85)
From: Gail Rubin <grubin@bbn-spca> 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)