Conference vaxaxp::alphanotes

    The easiest way is an application shareable image -- a loadable
    personality module -- compiled and linked on a particular release,
    and merge the appropriate shareable image into the application at
    run-time via LIB$FIND_IMAGE_SYMBOL.  This is also fully supported.

    There are some extensions to LIB$FIND_IMAGE_SYMBOL either in place
    or in progress to allow it to resolve system service vectors.  (This
    would require a prerequisite retrofit RTL kit for earlier versions.)

    One could do a run-time fix-up via scanning symbol tables and such,
    but this starts getting into a portion of OpenVMS that's both twisted
    and undocumented.

    Yah - I was afraid of that.  A personality module is something that I
    was trying to avoid since we've got plenty of images already :-).

    Norm,
    
    are you using a real language or is this still Macro32? If the later,
    then you can use the .WEAK stuff � la
    
    [......]
	.WEAK	SYS$FAOL_64
	MOVAL	SYS$FAOL_64,R0
	BEQL	100$
	BRB	50$
    [......]
    
    /cmos

    Of course it is a real language.  We use BLISS.  Unfortunately, a weak
    external doesn't help us because it is resolved at link time.  But if I
    link with a v7.0 sys$public_vectors, then I'm unable to run on 6.0.  If
    I link with a 6.0 sys$publiv_vectors, then the symbol is unresolved.

:    There are some extensions to LIB$FIND_IMAGE_SYMBOL either in place
:    or in progress to allow it to resolve system service vectors.  (This
:    would require a prerequisite retrofit RTL kit for earlier versions.)

   This fix is in V7.1, and this fix was apparently back-ported to V7.0.
   (I do not yet know if the fix was -- or could be -- back-ported further.)

   (Effectively, one can now do a LIB$FIS against the public vector image.)

    How about linking with a v6.0 sys$public_vectors and use
    lib$find_image_symbol to locate the new entry points that 
    were not in the v6.0 image.
    
    Support for finding symbols in sys$public_vectors was added
    in OpenVMS V7.1 and an ECO produced for OpenVMS V7.0.  In my
    software, it did matter how the lib$find_image_symbol call
    failed on versions prior to V7.0, because the symbols in 
    question were not there anyway.
    
    QAR EVMS-GRYPHON 1266 was filed to get this work done.
    
    I also use ENABLE LIB$SIG_TO_RET in order to not have the 
    LIB$FIND_IMAGE_SYMBOL routine signal when the entry point
    is not found.

    re: .5, .6
    
    	perfect.  that's what I'll try (one of my development systems is
    running alpha 7.1).  

re .7
    
>    	perfect.  that's what I'll try (one of my development systems is
>    running alpha 7.1).  
    
    Would you then have to bundle the ECO for use when installing on V7.0
    (but no other version)? Or would you ignore the *_64 services for V7.0?

    What we did for PATHWORKS for OpenVMS (Macintosh) was to compile and
    link the system for the oldest version of OpenVMS which we supported,
    however, we included a copy of the most recent sys$public_vectors to
    resolve the references to stuff we needed in newer versions of OpenVMS.
    Or I think it was sys$public_vectors.  Maybe it was some other file?
    
    In the code we checked the version of OpenVMS and called the new
    routines if and only if we were on a version of OpenVMS new enough to
    include them, otherwise we either didn't provide the new service or
    used old algorthims.  The version checks were a bit trickie to live
    with all the variations in version naming and field test naming, but it
    can be done.
    
    We first used this approach when the $HASH_PASSWORD was introduced
    along with the purdy 3 hashing algorithm, back in the V5.x days.  On
    old versions of OpenVMS we used the hacked code that generated purdy 2,
    on newer versions of OpenVMS we used $HASH_PASSWORD and purdy 3.
    
    This worked for us up until I left the group (back in the v6.2 days). 
    I don't know if any problems with this approach have turned up since
    them.
    
    					Bob Harris

    re: .8
    	what I had in mind was to try and call LIB$FIS looking for the
    new services.  If it worked, fine, call the services.  If it doesn't
    work (for whatever reason), that's OK, I won't use the new services. 
    We'd likely include some sort of verbage that if you want to use this
    new feature, then you'll have to install some patch kit or another.
    
    	There isn't massive new functionality in the feature, but it'll
    help out some sites by allowing more/bigger Rdb global sections.  Most
    sites won't care, but any workaround is reasonable.  Alternately, just
    require VMS 7.1 if you want the feature enabled.

    re .10
    
    I would be a bit worried about calling LIB$FIS on the public vectors on
    versions of VMS where this is known not to work. You are relying on the
    fact that it will fail reliably and harmlessly. I would probably not
    make the call at all if VMS version is V7.0 or earlier (or for V7.0
    provide some semi-documented logical name that can enable the call
    anyway). I assume that we are talking about supported software (RDB?)
    but I guess since you now support it, it's up to you. (-:

    re: .-1
    	fair enough.  I was gonna let testing and common sense lead me to
    the 'best' solution (call or not on 7.0 or earlier).  I'm in an
    exploritory phase right now, but thanks for the warning.