home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / vmsnet / sysmgt / 421 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  4.8 KB
  1. Xref: sparky vmsnet.sysmgt:421 comp.os.vms:19833
  2. Path: sparky!uunet!wupost!uwm.edu!biosci!ucselx!crash!cmkrnl!jeh
  3. From: jeh@cmkrnl.com
  4. Newsgroups: vmsnet.sysmgt,comp.os.vms
  5. Subject: Re: SET COMMAND (memory "consumption")
  6. Message-ID: <1992Dec23.224406.1006@cmkrnl.com>
  7. Date: 24 Dec 92 06:44:06 GMT
  8. References: <22DEC199220180231@dstl86.gsfc.nasa.gov> <8DV9VB2w164w@jwt.UUCP>
  9. Organization: Kernel Mode Consulting, San Diego, CA
  10. Lines: 83
  11.  
  12. In article <8DV9VB2w164w@jwt.UUCP>, bbs-comarow@jwt.UUCP (Bob Comarow) writes:
  13. >> Why not just stick the SET COMMAND line in your LOGIN.COM?
  14. >> 
  15. >>        __  Paul J. Olson - VAX Systems Manager & Resident Amiga Addict 
  16. > 
  17. > You should avoid set commands as it consumes memory.
  18. > 
  19. > Bob
  20. > comarow@eisner.decus.org
  21.  
  22. No.  Putting the SET COMMAND in your LOGIN.COM won't help because your 
  23. LOGIN.COM is not executed for a SPAWN operation. 
  24.  
  25. As for "avoid SET COMMAND as it consumes memory":
  26.  
  27. It is true that doing a SET COMMAND causes your process to map to a process-
  28. private command table instead of the normal one.  Apparently new virtual
  29. address space is created for this, which is not altogether surprising; the
  30. surprise is that the v.a.s. used to map DCLTABLES.EXE is apparently not always
  31. released or reused.  
  32.  
  33. The evidence is that a SET COMMAND usually -- not always -- causes the 'virtual
  34. pages' seen in SHOW PROCESS/CONTINUOUS to increase by about the size of
  35. DCLTABLES.EXE (in the neighborhood of 400 blocks, depending on how many layered
  36. products you have installed which supply their own DCL verbs). 
  37.  
  38. Possibly the issue is that the new table, which is generally going to have a
  39. few more things in it than the old table, usually won't fit in the "hole" left
  40. in P1 space by the old table. 
  41.  
  42. In case you're wondering, DCL is clearly unmapping from DCLTABLES.EXE when 
  43. the first SET COMMAND is done.  This can be seen by looking at the Refcnt for
  44. DCLTABLES.EXE in the output of INSTALL> LIST/GLOBAL . 
  45.  
  46. So the process (usually) maps another few hundred pages of address space.  But
  47. this is no big deal -- this is *virtual* address space.  The v.a.s. used by the
  48. old table, even though it's still mapped, will soon be pushed out of the
  49. working set for good (SET COMMAND may even be smart enough to do a $PURGWS on
  50. it; it looks that way, since the process working set size stays the same across
  51. SET COMMAND invocations even when the virtual page count increases).  The
  52. v.a.s. used by the new table only needs to be resident as long as you're
  53. touching the data, which is to say, when you're asking DCL to interpret
  54. commands for you, which only happens when you're between images. 
  55.  
  56. It is true that a process mapped to its own command tables won't be sharing the
  57. command tables in memory, as happens with DCLTABLES.EXE.  But again, this is 
  58. only an issue when you're between images.  
  59.  
  60. Once you start running an image, if your working set isn't big enough to keep
  61. the things needed by the image plus the command tables and all the rest of the
  62. junk needed by DCL (including DCL itself), the latter will get pushed out onto
  63. the modified page list, and eventually to the free page list, and eventually
  64. reused for other things -- maybe the image you're running, but more likely by
  65. some other process. 
  66.  
  67. Since the additional v.a.s. required for the process-private command tables is
  68. puny compared to the v.a.s. required to run any image of any significance, and
  69. since you don't need both in the working set at the same time, you can forget
  70. about it. 
  71.  
  72. To put it another way, if your system is so memory-starved that a few users,
  73. or even a majority, doing SET COMMANDs is going to be noticed, you're going
  74. to have LOTS of other performance problems too.  
  75.  
  76. If it really bothers you, and if a lot of different people need the same
  77. changes to DCLTABLES, you can generate a new command table file, put it in
  78. SYS$LIBRARY, INSTALL it /SHARED/OPEN/HEADER_RESIDENT, and modify the
  79. appropriate users' UAF entries to reference it.  If multiple users happen to
  80. be touching the same regions of the image at the same time, there will be
  81. a small memory saving.  Perhaps more important, not doing a SET COMMAND in 
  82. the users' LOGIN.COM will noticeably speed up logins on slower machines --
  83. SET COMMAND is a rather lengthy thing.  
  84.  
  85. (This is one of those cases where a myth is based on a true statement.  That
  86. the underlying statement is true says nothing about whether or not it's
  87. significant.  In this case the significance is very small.)
  88.  
  89.     --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
  90. drivers, internals, networks, applications, and training for VMS and Windows-NT
  91. uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
  92. Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
  93. Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
  94. Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
  95.