🚀 go-pugleaf

In article <8DV9VB2w164w@jwt.UUCP>, bbs-comarow@jwt.UUCP (Bob Comarow) writes:
>> Why not just stick the SET COMMAND line in your LOGIN.COM?
>> 
>>        __  Paul J. Olson - VAX Systems Manager & Resident Amiga Addict 
> 
> You should avoid set commands as it consumes memory.
> 
> Bob
> comarow@eisner.decus.org

No.  Putting the SET COMMAND in your LOGIN.COM won't help because your 
LOGIN.COM is not executed for a SPAWN operation. 

As for "avoid SET COMMAND as it consumes memory":

It is true that doing a SET COMMAND causes your process to map to a process-
private command table instead of the normal one.  Apparently new virtual
address space is created for this, which is not altogether surprising; the
surprise is that the v.a.s. used to map DCLTABLES.EXE is apparently not always
released or reused.  

The evidence is that a SET COMMAND usually -- not always -- causes the 'virtual
pages' seen in SHOW PROCESS/CONTINUOUS to increase by about the size of
DCLTABLES.EXE (in the neighborhood of 400 blocks, depending on how many layered
products you have installed which supply their own DCL verbs). 

Possibly the issue is that the new table, which is generally going to have a
few more things in it than the old table, usually won't fit in the "hole" left
in P1 space by the old table. 

In case you're wondering, DCL is clearly unmapping from DCLTABLES.EXE when 
the first SET COMMAND is done.  This can be seen by looking at the Refcnt for
DCLTABLES.EXE in the output of INSTALL> LIST/GLOBAL . 

So the process (usually) maps another few hundred pages of address space.  But
this is no big deal -- this is *virtual* address space.  The v.a.s. used by the
old table, even though it's still mapped, will soon be pushed out of the
working set for good (SET COMMAND may even be smart enough to do a $PURGWS on
it; it looks that way, since the process working set size stays the same across
SET COMMAND invocations even when the virtual page count increases).  The
v.a.s. used by the new table only needs to be resident as long as you're
touching the data, which is to say, when you're asking DCL to interpret
commands for you, which only happens when you're between images. 

It is true that a process mapped to its own command tables won't be sharing the
command tables in memory, as happens with DCLTABLES.EXE.  But again, this is 
only an issue when you're between images.  

Once you start running an image, if your working set isn't big enough to keep
the things needed by the image plus the command tables and all the rest of the
junk needed by DCL (including DCL itself), the latter will get pushed out onto
the modified page list, and eventually to the free page list, and eventually
reused for other things -- maybe the image you're running, but more likely by
some other process. 

Since the additional v.a.s. required for the process-private command tables is
puny compared to the v.a.s. required to run any image of any significance, and
since you don't need both in the working set at the same time, you can forget
about it. 

To put it another way, if your system is so memory-starved that a few users,
or even a majority, doing SET COMMANDs is going to be noticed, you're going
to have LOTS of other performance problems too.  

If it really bothers you, and if a lot of different people need the same
changes to DCLTABLES, you can generate a new command table file, put it in
SYS$LIBRARY, INSTALL it /SHARED/OPEN/HEADER_RESIDENT, and modify the
appropriate users' UAF entries to reference it.  If multiple users happen to
be touching the same regions of the image at the same time, there will be
a small memory saving.  Perhaps more important, not doing a SET COMMAND in 
the users' LOGIN.COM will noticeably speed up logins on slower machines --
SET COMMAND is a rather lengthy thing.  

(This is one of those cases where a myth is based on a true statement.  That
the underlying statement is true says nothing about whether or not it's
significant.  In this case the significance is very small.)

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows-NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh