Conference vaxaxp::vmsnotes

    Please point the customer at the platform-specific Internals and
    Data Structures Manual (IDSM), available from Digital Press, as the
    processing performed bty LOGINOUT is documented there.  In the
    unlikely event that detail beyond the IDSM is needed, sell them
    the OpenVMS source listings CD-ROMs.

    While the customer may be focusing on LOGINOUT, we need additional
    background as to why there are a large number of process creations
    occuring (and if this can be lowered), what sort of disk and locking
    activity is present, what sort of shape the authorization file format
    is in, etc.  And, of course, we need to know what the problem the
    customer is seeing is -- is there an actual customer-perceived system
    performance problem, or is the customer responding to some data...

    (Given the "nanoseconds" comment, it looks like the goal is a fast
    login to DCL.  If so, one of the simplest fixes often involves having
    sufficent memory and sufficiently available CPU cycles... Or both.)

    There have been previous discussions of speeding LOGINOUT.

>                                       <<< Note 554.0 by CHEFS::WILLIAMSA "I wanna be Luke" >>>

>     faulty , or anything.....I suppose the question is... What does it
>     do...Obviously looks at the UAF...what else... the I/O is not LOW so we
>     were looking at what can be done to improve this if anything. The

"Looking at the UAF" could be very slow if the UAF is very large and has
never been optimized.  The UAF is an ordinary indexed file, susceptible
to ANALYZE/RMS and other techniques during off hours.  Using such methods
during production is a bad idea since utility programs typically will not
leave the UAF open for access by logins during the period.

    Re .1 & .2
    
    Thanks both for your comments. I have made comment to the customer
    about the size of the UAF file, it IS quite large, 4000 odd users most
    of which have long been dead. Unfortunately this particular customer
    (part of an FM deal) would like me to do his research for him, hence
    his comment about 'no we know it isn't a fault, but...'. Sending him
    off to the manual should provide him with the detail, although I
    suspect it'll strangely be dropped now I've told him to go look
    himself!!! Thanks anyway.
    
    Alen.

>                                       <<< Note 554.3 by CHEFS::WILLIAMSA "I wanna be Luke" >>>

>     Thanks both for your comments. I have made comment to the customer
>     about the size of the UAF file, it IS quite large, 4000 odd users most
>     of which have long been dead.

There is nothing wrong with a large file full of dead records (if that is
how the customer wants to manage the file) and it should be highly susceptible
to RMS optimization since the great bulk of the records will stay put, thus
preserving the optimization effort.

Here are a couple suggestions:

move SYSUAF, RIGHTSLIST, etc. to a RAMdisk.  This requires
creating the RAMdisk and copying all the relevant files
across at boot, prior to letting people log in or getting
batch jobs started.  There are other files that will benefit
from being on a RAMdisk -- and I know this has been discussed
before in earlier editions of this conference.

Write a program that uses LIB$SET_SYMBOL and LIB$SET_LOGICAL
to define process-specific symbols and logical names.  It's
fastest if you embed the symbol values directly in the
program source, but, obviously, you trade off a fair amount
of flexibility for speed using this approach.

Pull unused characters out of SYLOGIN.COM:  extra spaces and
tabs, for example.  To see what I mean, take a look at
SYS$UPDATE:AUTOGEN.COM -- it's compressed by removing all
unnecessary spaces and comments.  This speeds things up some,
and if your customer is really worried about nanoseconds,
this'll help.

Finally, reduce the complexity of SYLOGIN.COM.  There is a
great temptation to stuff all sorts of things into
SYLOGIN.COM -- it's a great catch-all place for virtually all
kinds of user process set up stuff.  But, unless every user
needs every bit of setup, there are opportunities to remove
things from SYLOGIN that aren't global, and force individual
users to put this stuff in their local LOGIN.COM, not burden
everybody with it.

(Do I do any of this stuff on the (small!) system I manage?
Nope.  But then, I only log in about once a month or so, so
saving a couple of microseconds (it's only a VAX, after all)
doesn't matter that much.....)

John

    and make sure there are no 'SET COMMAND' commands in SYLOGIN.
    Update DCLTABLES instead. Not only does this takes time, but it
    means that each process has a private copy of the tables.
    
    - Richard.

   Having over 4000 users in a SYSUAF is not unusually large -- several
   sites I have dealt with will load and unload that many users several
   times a year.

   Before moving to a RAM disk or other (good) suggestions, I'd run a
   profile on the SYSUAF, seeing if the indexed file structure should
   be tweaked -- make a copy, then see what ANALYZE/RMS_FILE[/FDL] and
   EDIT/FDL/ANALYSIS have to say about the SYSUAF file structure.
   (I'd consider moving to RMS global buffers before I considered a RAM
   (in-memory) disk or a RAM (solid-state) disk, due to the volatility
   of the data and due to the cost, respectively.  And I'd consider
   adding more memory -- the "buy more memory" comment is not a joke.)

   But as you say, offer some documentation pointers and also offer some
   consulting services...

   And -- if retained -- I'd spend some time characterising just what
   performance attributes needed improvement.  (One potentially apocryphal
   tale tells of a customer site that successfully optimized the null loop.)

    
.5> move SYSUAF, RIGHTSLIST, etc. to a RAMdisk.  This requires
.5> creating the RAMdisk and copying all the relevant files
    
    IMHO this is very bad advise. Outragously bad. Irresponsible.
    You open the system up to terrible vulnerabilty for data loss
    and it can never ever be made to work reliably in a cluster.
    All this while there is a more efficient, less memory intensive,
    well documents and and completely reliable technique available:
    Used RMS GLOBAL BUFFERS for all those files!
    
    That way multiple processes can use the sam copy of the data
    instead of them all copying from the in-memory file to the
    private rms buffers, and updates will be immediatly written
    through to disk. Only buckets that are touched will end up in
    memory and normally you can select a smaller portion of the
    file whilest still achieving 95% or better hit rates.
    
    hth,
    	Hein.