home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / vms / 19454 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  2.9 KB

  1. Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!news!nosc!crash!cmkrnl!jeh
  2. From: jeh@cmkrnl.com
  3. Newsgroups: comp.os.vms
  4. Subject: Re: How to prevent login.com from running.
  5. Message-ID: <1992Dec16.204326.984@cmkrnl.com>
  6. Date: 16 Dec 92 20:43:26 PST
  7. References: <11345@prijat.cs.uofs.edu>
  8. Organization: Kernel Mode Consulting, San Diego, CA
  9. Lines: 51
  10.  
  11. In article <11345@prijat.cs.uofs.edu>, gavinl1@jaguar.uofs.edu (Lori Gavin) writes:
  12. > I was wondering if there is any way to globally not run any users's login.coms.
  13. > We have an command running from rshell and we do not want the user's login.com
  14. > to run for this command.  I realize the users can put in a check for non-
  15. > interactive processes, but that is not the preferred method.  I would like 
  16. > something more automated that I can control.
  17.  
  18. Set everybodies' LGICMD (in the UAF) to LOGIN  .  That's it.  No device, no
  19. directory, no file type. (This is the way the DEFAULT record is set up, so
  20. it's likely that this is already the case.)
  21.  
  22. Now, the way the LGICMD field is handled at login time, is that it is
  23. translated as a logical name.  When translations "run out", the default file
  24. spec of SYS$LOGIN: is applied to the result.  Usually there is no logical called
  25. LOGIN, so it just becomes SYS$LOGIN:LOGIN .  (SYS$LOGIN equates to the user's
  26. default device and directory.)
  27.  
  28. So, if you do the equivalent of 
  29.  
  30.     $ DEFINE LOGIN NLA0:
  31.  
  32. in a context that will be seen by your command that runs from rshell, 
  33. this will inhibit execution of the login.com wherever your logical name
  34. is available.  
  35.  
  36. > Thanks for any help...
  37. >           Lori
  38. > --
  39. >                                               UUUUUU         UUUUUU
  40. >  ----------------------------------            UUUU           UUUU
  41. > |  Lori Gavin                      |           UUUU       SSSSSSSSSSSSSSS
  42. > |  VAX System Manager              |           UUUU      SSSSSSSSSSSSSSSSS
  43. > |  University of Scranton          |           UUUU      SSSS UUUU     SSSS
  44. > |                                  |           UUUU      SSSS UUUU
  45. > |  BITNET: GAVINL1@SCRANTON.BITNET |           UUUU      SSSSSSSSSSSSSSSSS
  46. > |INTERNET: GAVINL1@JAGUAR.UOFS.EDU |           UUUUUUUUUUUSSSSSSSSSSSSSSSSS
  47. > |   Phone: (717)941-6133           |            UUUUUUUUUUUUUUUUU      SSSS
  48. >  ----------------------------------                      SSSS          SSSS
  49. >                                                          SSSSSSSSSSSSSSSSSS
  50. >                                                           SSSSSSSSSSSSSSSS
  51.  
  52.     --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
  53. drivers, internals, networks, applications, and training for VMS and Windows-NT
  54. uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
  55. Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
  56. Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
  57. Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
  58.