Conference vaxaxp::vmsnotes

re .0
    
>    what happens when different images of the same name are installed in
>    V6.2 & follow-ons?
    
    It works!
    
>    	$ DEFINE X DISK:[dir.a],DISK:[dir.b], ... (ad infinitum)
    
    That could be dangerous. I have a recollection (not tested) that image
    activation notionally makes two searches through a search list. In the
    first search, it will look to see whether any image located via the
    search list is INSTALLed and if so, that is the image activated. If no
    such image is INSTALLed then a second search is performed. In the second
    search, the first image located is activated.
    
    Assuming that my recollection is correct then what the customer is
    doing will only work sensibly if either all or none of the images are/is
    INSTALLed. My recommendation therefore would be not to use a search
    list (I don't see what purpose it serves) but just to use a logical
    name to select the single appropriate image to activate.

    >That could be dangerous. I have a recollection (not tested) that image
    >activation notionally makes two searches through a search list.
    
    therein lies the rub.  i don't remember how image activation resolves
    references, nor do i know exactly what might happen if multiple (but
    not all) variants of a program are installed.  it would be great if
    someone would be good enough to explain this (in some detail).
    
    i'll have to confirm the search list setup.  it's possible that they
    have several layers of embedded logical names, and ultimate all
    versions end up referencing a single name.
    
    cheers,
    
    +b

    
    
:    i've read HACKERS 1748 and several associated notes in this and the
:    previous conference, but i'm not quite sure what to expect.  reassure
:    me ...

    You will need to determine exactly what the customer is doing,
    and determine if there is actually a problem here.

:    what happens when different images of the same name are installed in
:    V6.2 & follow-ons?  specifically ...

    The images should be activated as expected.

:    different users hit different images based on the rev level of the code
:    they're running.  i'm not sure, but i believe they refer to a given
:    image by a logical name search list - to wit,
:    
:    	$ DEFINE X DISK:[dir.a],DISK:[dir.b], ... (ad infinitum)

   Details needed.

:    what are the chances that someone is going to end up accessing the
:    wrong installed image?

   One can certainly end up accessing the wrong images, but I
   would not immediately assume it was the image activator that
   made the mistake -- this design appears to have the potential
   for activation errors. 

   If I were looking at this design, I would look to replace it
   with the model that multi-version Rdb follows.

:    the customer has very high activation rates (and in many cases,
:    several hundred references to a .EXE) and is looking to improve
:    performance and reduce memory waste.

   Assuming image activation is a proven (and not assumed)
   resource drain, solve this -- find out why they're activating
   zillions of images, and determine what can be done to reduce
   the numbers of activations.

re .2
    
> nor do i know exactly what might happen if multiple (but not all) variants
> of a program are installed.
    
    Well what I am asserting is that if these images are located via a
    search list what would happen is that it won't work! Sorry, I don't
    remember where I read about this. You could look around in this and
    previous incarnations of VMSNOTES. The Altavista notes conference
    searcher would probably help.
    
    As Steve points out, since there seems to be some doubt as to exactly what
    the customer's setup is, one can't be too certain about what will happen.

.4
>    Well what I am asserting is that if these images are located via a
>    search list what would happen is that it won't work! Sorry, I don't
>    remember where I read about this. You could look around in this and
>    previous incarnations of VMSNOTES. The Altavista notes conference
>    searcher would probably help.

I'm *sure* I wrote up something within the last year or two about the image
activator and searchlists - now I cannot find it!

The assertion in .1 is (still) correct: i.e. first RMS looks for a known image
using each element of the searchlist and only then does it look for the image on
disk.

So the customer's setup might work *if* setup properly. I bet it won't be too
long before they tie themselves up in knots though :-)

Take a look in VMSNOTES_V1 note 673.* (esp. 673.1) for some confirmation and why
"it's a feature not a bug".

Antonio
(Long live AltaVista Notes !)

    well, they are rather tied up in knots, which is why they're paying us
    to look at the system.  8-)  (thanks for the pointers, BTW - i'll be
    reading shortly...)
    
    image activations *are* a problem, as is memory depletion.  this system
    runs the standard i-used-to-be-an-IBM-weenie COBOL program ... or
    rather, a very large set of programs. in some cases, a menu-driver
    .EXE. offers jumping-off points to other programs; in other cases,
    progams are invoked from a DCL menu.  in all cases, .EXEs end up doing
    the COB equiv of LIB$RUN_PROGRAM to run others programs at some point
    during the execution path.  some of these programs are small ( <500
    blocks), many are quite large (some in excess of 10K blocks). 
    concurrent access ranges from 10-120 users in a given pgm at a given
    time.
    
    due to political reasons, structure of the application will not change.
    i can't do anything about that.
    
    an example structure: consider program BILLING.  there are 30 different
    internal customer groups who use umpteen different versions of the program. 
    the program is invoked by:
    
    	$ RUN EXE:BILLING
    
    EXE is a search list structured as follows:
    
     	  EXE	= EXE_V702_EXE	= PC0:[RELEASE.702.EXE]
    		= EXE_V700_EXE	= PC0:[RELEASE.700.PATCHED.EXE]
    				= PC0:[RELEASE.700.EXE]        
    		= EXE_V605_EXE	= PC0:[RELEASE.605.PATCHED.EXE]
                                  PC0:[RELEASE.605.EXE]        
    		= EXE_V600_EXE	= PC0:[RELEASE.600.PATCHED.EXE]
                                  PC0:[RELEASE.600.EXE]        
    		= EXE_V588_EXE	= PC0:[RELEASE.588.PATCHED.EXE]
                                  PC0:[RELEASE.588.EXE]        
    
    around 70 users will will run the 700.PATCHED version, 20 or so will
    run the 702 version, and a smattering of folks will use the others.
    
    on a similar track, a "shared image" (call it MYLIB), also in multiple
    variants and structured as above) is called by BILLING.  
    
    i'd like to at least install BILLING version 700.PATCHED and its
    associated programs, but i don't know if it will screw up anyone else. 
    
    what are my options?

    Install DECram and put all of the 'hot' .EXE files there an avoid all
    'standard' disk I/O.  

    "the license is too expensive."  (i am not making this up.)
    
    sigh.

Re .6
I guess the EXE search list is different for different users?
And, that some applications (like BILLING) have both a 702 and a 700.PATCHED
version, but others are missing some set of versions?

It sounds like the best solution is to make sure that, for any given
application, either you install all the versions or none of the versions.
Is that so hard to accomplish?

(I assume you could choose to install the most heavily-used versions /SHARED,
and install the other versions without /SHARED, but you won't really save
much by doing that.)

You may want to develop a .COM file that installs all the versions at once,
to make this a bit more foolproof.

   Assuming V6.2 or later...

:    image activations *are* a problem, as is memory depletion. 

   Configure the maximum amount of physical memory allowed
   for the particular model(s) of system(s) in use.

   And as mentioned, a solid-state disk can also help.
   Personnally, I'd not use DECram for this application,
   I'd use the memory for additional RMS global buffers
   for additional disk caching -- the data files are going
   to be rather hot.

   I'd go ahead and start installing the commonly-used images,
   with the images used in parallel installed /SHARE.

:    due to political reasons, structure of the application will not change.
:    i can't do anything about that.

   Ah, a technical solution to a political problem?   I'd work
   on this -- it would be far easier to start fixing this design
   than to support it.  (You're getting paid -- give these folks
   the option of fixing the problem, or fixing the problem within
   the political boundaries.)
    
:    an example structure: consider program BILLING.  there are 30 different
:    internal customer groups who use umpteen different versions of the program. 
:    the program is invoked by:

   I'd definitely look at the Rdb multi-version model.  It's
   definitely much cleaner...  (Different versions can be
   selected via one or a few logical names...)
    
:    i'd like to at least install BILLING version 700.PATCHED and its
:    associated programs, but i don't know if it will screw up anyone else. 

   Do it.

    It is conceivable that you could use the memory-disk host of
    zrdriver instead of decram; zrdriver has been on freeware cd or
    sigtapes and does run ok on alpha vms. There are several free
    ramdisks for vax vms which are very good performers. The zrdriver
    host uses a process' memory as its memory btw. May or may not really
    gain anything but the code's free and in source.
    

    a memory-disk won't work, since they have no appreciable free memory. 
    we've been going over the options this morning ... the systems guys are
    saying "yes!  we TOLD you it was an application problem!".  the
    applications folks are saying "you CAN'T be serious?!?  we're not
    changing all OUR code."
    
    once again, sigh.  and thanks for the pointers and replies, folks. 
    cheers,
    
    
    +b

re .10
    
>:    i'd like to at least install BILLING version 700.PATCHED and its
>:    associated programs, but i don't know if it will screw up anyone else. 
>
>   Do it.

    I don't understand why you say to do this. As soon as the version in
    700.PATCHED.EXE] is INSTALLed, the version in 702.EXE] will be skipped
    unless it too is INSTALLed.
    
re .0
    
    If you like to live dangerously, a possible minimal design change would
    be to avoid using search lists altogether but to resolve all images
    down to a specific version and define a logical name to point at the
    appropriate version by using a command procedure that manually applies
    the searching. Having done this you could INSTALL any or all images
    with impunity. (You could still have a kind of search list - just don't
    use it for image activation.)

:.13
:re .10
:>:    i'd like to at least install BILLING version 700.PATCHED and its
:>:    associated programs, but i don't know if it will screw up anyone else. 
:>
:>   Do it.
:
:    I don't understand why you say to do this. As soon as the version in
:    700.PATCHED.EXE] is INSTALLed, the version in 702.EXE] will be skipped
:    unless it too is INSTALLed.

   I'm making a large leap of faith, but I am assuming these images can
   coexist, and interoperate.  If so, activating the wrong image will
   have minimal (no?) permanent impact, other than what I am assuming
   involve differences in displays and capabilities.

   And like a previous reply, given the number of users of each version
   of the image, I would expect all versions of the images to be installed,
   or to be installed with /share.

    well, i wrote a couple of junk basic programs and tried umpteen
    variations on a theme.
    
    it is certainly true that KFEs are searched 1st, then RMS.  a note in
    a previous conference used a grid to describe it as follows:
    
    
    	search		KFE	RMS
    	list      -----------+--------+
    	entries              |   Y    |
    	   .      -----------+--------+
    	   .           X     |        |
    	   .      -----------+--------+
                             |        |
                  -----------+--------+
                             |        |
                  -----------+--------+
    
    searches are done vertically; if all images are named FOO and one is
    installed at point X, Y:FOO will never be accessed unless specified as
    Y:FOO.EXE; (; must be there).  if all images are installed, then the
    resolution reverts to "normal".
    
    the end of the story is that i convinced them to make some changes to
    let things be installed.  since their 5 key images account for around
    15000 blocks each (around 60% shareable), they decided it was cheaper
    to change some DCL than to buy memory.
    
    thanks dave & steve for your comments.
    
    +b