[fa.info-vax] VMS V4.0 gotcha

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)