Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!jade!ucbvax!venus.ycc.yale.EDU!leichter
From: leichter@venus.ycc.yale.EDU ("Jerry Leichter")
Newsgroups: comp.os.vms
Subject: re: DEC/Shell and SYS$SYLOGIN clash - help
Message-ID: <8711040940.AA17832@ucbvax.Berkeley.EDU>
Date: Sun, 1-Nov-87 14:39:00 EST
Article-I.D.: ucbvax.8711040940.AA17832
Posted: Sun Nov  1 14:39:00 1987
Date-Received: Sat, 7-Nov-87 10:03:52 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: "Jerry Leichter" <leichter@venus.ycc.yale.edu>
Organization: The ARPA Internet
Lines: 59


	We have a VMS 4.5 system on which some users want to run DEC/Shell as
	their default CLI, while most users want to run DCL.  The problem is
	how to make the system not try to execute SYS$SYLOGIN when a DEC/Shell
	user logs in.  Anyone know a solution?  We don't want to get rid of
	SYS$SYLOGIN since it does a lot of useful things for DCL users, but it
	makes DEC/Shell barf and therefore fail to execute the user's private
	shell startup file (.profile)

Default file specs to the rescue again!  When DCL goes looking for the
system-wide login command file, it doesn't specify just SYS$SYLOGIN: as the
spec; it uses RMS defaulting.  It does something essentially like the
DCL lexical call:

		F$PARSE("SYS$SYLOGIN",".COM")

When other CLI's start up, they make similar calls, with different file types
corresponding to their conventions for command files.  For example, VAX-11 RSX
command files have type .CMD, so the MCR CLI uses:

		F$PARSE("SYS$SYLOGIN",".CMD")

If I remember right, the Shell uses an explictly null file type:

		F$PARSE("SYS$SYLOGIN",".")

So, what does this mean to you?  It means that you shoudl define SYS$SYLOGIN
WITHOUT any file type:

		DEFINE/MANAGER/EXEC SYS$SYLOGIN SYS$MANAGER:SYLOGIN

When DCL is the CLI, it will try to open SYS$MANAGER:SYLOGIN.COM.  When the
Shell is the CLI, it will open SYS$MANAGER:SYLOGIN. (explict null type).
You can provide whatever Shell-style commands you like - or none at all -
in the latter file.

Note that the same behavior applies for the command file specified in the
UAF entry for an account:  If LGICMD is something like "LOGIN", when the
user logs in using DCL, his LOGIN.COM file is executed, while when he logs
in under the Shell, it's his LOGIN. file that is executed.

Finally, a note about using SYS$SYLOGIN.  The user cannot override execution
of this command file.  That makes it suitable for security-related things,
or anything you as system manager think is absolutely essential for ALL users
ALL the time.  Large and inappropriate SYS$SYLOGIN files are a pain to users.
If you have a lot of standard setup, it's generally better to create another
system-wide file, terminate it with @SYS$LOGIN:LOGIN, and point everyone's
UAF entry to it.  That way, users who don't want the system-wide file (or
their private file) executed on a particular occasion need only specify
/NOCOMMAND after their username.  (This is ignored for CAPTIVE accounts to
maintain their security, however.)  Also, individual users who NEVER want to
execute the system-wide file can be easily accomodated by the system manager,
who need merely change the definition of LGICMD for their account.

One warning, though:  Don't put an @SYS$LOGIN:LOGIN command at the end of a
file pointed to by SYS$SYLOGIN, or the user's login file will be executed
twice!
							-- Jerry
------