| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 2583.1 | A Little Light! | AIMTEC::BUTLER_T |  | Fri Apr 16 1993 18:21 | 10 | 
|  |     A1$DEFER lets the stubs for shareable images to be linked with the
    main image rather than linking the shareable images.
    
    Now, according to what I have read, this is supposed to result in
    a performance improvement since the shareable images are only
    activated when needed.
    
    HTH,
    
    Tim
 | 
| 2583.2 | Where has Andrew been all week? | AIMTEC::WICKS_A | on the Streets of San Francisco | Fri Apr 16 1993 19:13 | 11 | 
|  |     Tim,
    
    I presume that the base note means setting A1$DEFER to 0 i.e off
    which is an SRA requirement.
                                           
    P.S I'm off the net for at least another week for anyone expecting me
        to answer any other notes.
    
    Regards,
    
    Andrew.D.Wicks 
 | 
| 2583.3 | Deferred images 101 | IOSG::TALLETT | Gimmee an Alpha colour notebook... | Fri Apr 16 1993 19:51 | 24 | 
|  |     
    	Indeed. Deferred image activation is a technique whereby the
    	shareable images that ALL-IN-1 wants to link against are
    	analysed at link time (thats what that subprocess is during
    	A1LINK) and a "stub" built which has all the same entry
    	points as the shareable image but none of the code. When
    	ALL-IN-1 is activated, only the stub gets activated so none
    	of the shareable image code is loaded or mapped. Only when
    	ALL-IN-1 actually tries to CALL the routine (eg if you use
    	the DTR features then it tries to call the DTR shareable) then the
    	stub gets called and a small piece of code in the stub maps
    	the real shareable image into memory and revectors all the entry
    	points into it.
    
    	The result is you get faster image activation and only take the hit
    	on a shareable image activation if you actually call it (which a
    	lot of the time you don't).
    
    	Its a pity this isn't a standard VMS feature as it is on other
    	operating systems (eg Windows). ALL-IN-1 links to so many images
    	that ALL-IN-1 engineering had to come up with a private scheme.
    
    Regards,
    Paul
 | 
| 2583.4 | more... | IOSG::MARCHANT | I'd sink therefore I swam | Sun Apr 18 1993 22:28 | 21 | 
|  |     So why does SRA want to turn this feature off?  Well, that's because SRA
    wants to include the SQL services shareable image into ALL-IN-1.  If
    deferred image activation is enabled (which it is by default,) you cannot
    link in any other shareable images, otherwise the VMS linker dies with a
    lot of multiple symbol definition errors.  To get round this, SRA requires
    that the link is performed with deferred image activation disabled.
    Ideally, SRA should add the SQL services shareable image to the list of
    images ALL-IN-1 produces stubs for.  However, there is no way to do this
    other than by editing A1LINK.COM - which of course is unsupported.
    Another reason why SRA doesn't use the deferred image activation might
    be (I don't know enough about SRA to say for sure) that it falls foul
    of a restriction of the deferred image activation.  Some shareable images
    (e.g. VAXCRTL) contain data as well as code.  However, these data sections
    are not supported by the deferred image code, so any program wanting to
    access these data sections can't (they can try, but the data will have
    rubbish values.)
    Cheers,
        Paul.
 | 
| 2583.5 | Something(s) not installed /SHARE perhaps? | IOSG::SHOVE | Dave Shove -- REO2-G/M6 | Tue Apr 27 1993 11:05 | 19 | 
|  |     To answer the original question (about performance):
    
    Normally, the main effect of not having deferred image activation
    should be a large increase in image activation time (because the poor
    old VMS image activator has far more work to do.) Typically, ALL-IN-1
    start-up time can double.
    
    However, once you've gone through this pain, the only effect during
    running will be more image sections and pages in your virtual address
    space. Since these should all be shared, there shouldn't be much
    effect on performance.
    
    I would check that everything is installed (as in $INSTALL) /SHARE
    (check the output from $INSTALL /LIST). Maybe some SYSGEN parameter is
    too low and you're getting errors from the $INSTALLs during system
    startup. Also check that all the .EXEs which are $INSTALLed /SHARE have
    world:read (or probably :execute) protection.
    
    Dave.
 |