[comp.os.vms] DEC/Shell and SYS$SYLOGIN clash - help

mkhaw@teknowledge-vaxc.UUCP (10/28/87)

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)

Thanks,
Mike Khaw
-- 
internet:  mkhaw@teknowledge-vaxc.arpa
usenet:	   {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail:	   Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

mxc@ecsvax.UUCP (Mark Cooperstein) (10/29/87)

In article <18342@teknowledge-vaxc.ARPA>, mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes:
> 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)
> 
> Thanks,
> Mike Khaw
> -- 


  
     Your problem is very simple... Go into the authorize utility, and
set all DEC Shell users lgicmd to be something (or nothing!) other then 
mgr$login (which is a logical that points to syslogin.com).  Our
DEC Shell users have lgicmd set to .PROFILE  (which is what dec
suggests).  They have a file called .PROFILE in their sys$login
directory (naturally!), with Shell commands.  All of this is modeled 
somewhat after unix I suppose.  
     Hope this helps!

              Mark Cooperstein
                   NCSU School of Veterinary Medicine
                   Raleigh  NC

ted@blia.BLI.COM (Ted Marshall) (10/29/87)

My memory on this is a little hazy and I am unfamiliar with the DEC/Shell,
but this should work:

The problem has come up before with users who wanted to have MCR as their
default CLI. The trick is to define SYS$SYLOGIN without specifying a file type.
For example, "DEFINE/SYSTEM SYS$SYLOGIN SYS$MANAGER:SYLOGIN" (not SYS$MANAGER:
SYLOGIN.COM). Each CLI then supplies its default command file type. DCL users
get SYLOGIN.COM and MCR users get SYLOGIN.xxx (damn if I can remember what it
is).

Anyway, I would expect that DEC/Shell will have its own default file type,
maybe null (i.e. SYLOGIN.).

Hope this helps.

-- 
Ted Marshall       ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU
Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.

awp8101@ritcv.UUCP (Andrew W. Potter) (10/29/87)

>> 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)
>> 
>set all DEC Shell users lgicmd to be something (or nothing!) other then 
>mgr$login (which is a logical that points to syslogin.com).  Our
>DEC Shell users have lgicmd set to .PROFILE  (which is what dec
>suggests).  They have a file called .PROFILE in their sys$login
>directory (naturally!), with Shell commands.  All of this is modeled 
>somewhat after unix I suppose.  

Wrong:

	The behavior of LOGINOUT is to attempt to run the procedure
pointed to by the logical name SYS$SYLOGIN and THEN run the procedure
specified in the authorize field LGICMD.  (This changed in VMS from V2 to
V3). If SYS$SYLOGIN does not translate then LOGINOUT goes directly to
the LGICMD specified procedure.  IF the UAF field LGICMD is blank
as the default record is normally then LOGINOUT does a simple @LOGIN
(or equivilant for the DEC shell I would assume)  In our 2 CLI shop
(DCL and MCR) this results in either LOGIN.COM or LOGIN.CMD being
run depending on the CLI. (.CMD is what MCR wants).  We have
the logical name SYS$SYLOGIN ( $ DEFINE/EXEC natch) pointing to
the file SYS$MANAGER:SYLOGIN.  Note: NO .COM extension on the
logical name.  we then have SYLOGIN.COM (DCL) and SYLOGIN.CMD (MCR) flavors
of our system login routines.

I assume a similar action can happen with DECshell. SYLOGIN.PROFILE maybe?
If not. I would  set up a SYLOGIN.COM that has a command that will do
2 actions depending on whether it is running DCL or SHELL. If it
is a DCL command then it would be a No operation command.  If it was
under DECshell then it would run some shell script and exit. 

- Andrew W. Potter
- Rochester Institute of Technology

mkhaw@teknowledge-vaxc.UUCP (10/31/87)

Several people have posted the correct solution:

The logical symbol SYS$SYLOGIN should not translate to a filename that
has an extension (filetype?) on it; i.e., it should be

	define sys$sylogin sys$manager:sylogin

So, for DCL users, you have sys$manager:sylogin.com, for MCR users, 
sys$manager:sylogin.cmd, and for DEC/Shell, sys$manager:sylogin. (there's
a dot on the end of that name).

Similarly, the UAF file should have LGICMD = LOGIN (with no extension).
The DEC/Shell documentation DOES point out that this works fine if your
sys$login:login. file says ". .profile" (assuming you want to use .profile
as your startup dot file).

Thanks all,
Mike Khaw
-- 
internet:  mkhaw@teknowledge-vaxc.arpa
usenet:	   {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail:	   Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303

leichter@venus.ycc.yale.EDU ("Jerry Leichter") (11/01/87)

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

kvc@nrcvax.UUCP (Kevin Carosso) (11/03/87)

The solution is to make sure your definition of SYS$SYLOGIN does
NOT specify a file type.  For example:

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

If the user specifies DCL as his CLI at login time, DCL will open the
file SYS$SYLOGIN with a default file specification of ".COM", and
so will open and read SYS$MANAGER:SYLOGIN.COM

The Shell does not specify a default file specification with a file
type, and so will open and read SYS$MANAGER:SYLOGIN.

You should then create SYLOGIN.COM with appropriate DCL commands and
SYLOGIN. with appropriate Shell commands.  I assume the same would work
for MCR with SYLOGIN.CMD.

Users can also have LOGIN.COM and LOGIN. files if the LGICMD field
of their entry in SYSUAF does not specify the file type.

	/Kevin Carosso            kvc@nrcvax.uucp
	 Network Research Co.

carl@CITHEX.CALTECH.EDU (Carl J Lydick) (11/03/87)

 > In article <18342@teknowledge-vaxc.ARPA>, mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes:
 > > 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)
 > > 
 > > Thanks,
 > > Mike Khaw
 > > -- 
 >   
 >      Your problem is very simple... Go into the authorize utility, and
 > set all DEC Shell users lgicmd to be something (or nothing!) other then 
 > mgr$login (which is a logical that points to syslogin.com).  Our
 > DEC Shell users have lgicmd set to .PROFILE  (which is what dec
 > suggests).  They have a file called .PROFILE in their sys$login
 > directory (naturally!), with Shell commands.  All of this is modeled 
 > somewhat after unix I suppose.  
 >      Hope this helps!
 > 
 >               Mark Cooperstein
 >                    NCSU School of Veterinary Medicine
 >                    Raleigh  NC
   
It's rather unlikely to help, since it's dead wrong.  The LGICMD field in
SYSUAF.DAT specifies the procedure to be executed AFTER SYS$SYLOGIN: is
executed.  Thus, changing that entry WILL NOT solve the problem described
in the original posting.  The following suggestion is possibly wrong, since
I don't have a machine with DECshell that I can test it on:

	If I recall correctly, if DECshell is told to execute a procedure,
	and the filename specified has no extension, DECshell will look
	for the file with no extension; DCL, on the other hand will look
	for the file with a .COM extension.  Thus, I suspect your problem
	may be that you've got SYS$SYLOGIN defined to be something like
	SYS$MANAGER:LOGIN.COM, which forces both DCL and DECshell to execute
	the .COM file.  If DECshell behaves the way I think it does, you
	could instead define SYS$SYLOGIN to be, say, SYS$MANAGER:LOGIN
	Then you could put the standard DCL startup commands in the file
	SYS$MANAGER:LOGIN.COM, and the standard DECshell commands in the
	file SYS$MANAGER:LOGIN., and both classes of users would be happy.

Again, the above suggestion is made on the basis of my recollections of
DECshell behavior, and may not work: don't just do as I suggest without
checking to make sure things work the way you want them to.