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.