Conference vaxaxp::vmsnotes

: Is this LINK operation possible?

   If I understand what is requested, yes, this is entirely possible,
   though it requires dynamic (run-time) linking or reorganization of
   the code into seperate modules.  The problem you are seeing now is
   due to "circular" (some would say incestuous :-) references among
   the images -- this is not a technique I would recommend.

   Options include the use of the lib$find_image_symbol and an indirect
   (by address) function call, or the ability to pass in the routine
   address into the called routine, and a by address function call.

   In languages with full pointer support, this technique is quite easy.
   Other languages may end up calling lib$callg or similar techniques.

   The alternative is to relocate the routines called from this module
   into a third, seperate shareable image, and link both the main image
   and this "stub" shareable against this third image.

   And in either case, you _will_ want to use signal handlers in the
   target routines to capture and report calling errors and other
   internal problems within the target routine(s) -- otherwise, there
   can be some difficulty determining the source of a particular
   problem, due to the "interwoven" nature of this application design,
   and the involvement of two (or more) programming organizations.

:This is on AXP VMS 7.1.

   I suspect you meant "OpenVMS Alpha"...

  I can't see any circularity in what .0 says, except that choice of
  name of the "missing" routine might be construed as meaning the routine
  which calls SHARE1. Assuming that's NOT the case:

  It's quite straightforward to change a routine at run time, that's
  what shareable images are all about. Here's a small example (including
  the MAIN program)

MAIN.FOR
	PROGRAM MAIN
	CALL share1
	END
SHARE1.FOR
      subroutine share1
      external main1
      print *, 'I am share1...now calling a routine in main...'
      call main1
      end
DYNSHARE.FOR
	SUBROUTINE MAIN1
C		This is a dummy routine
	END

  Compile with your qualifiers of your choice. Linking is as follows:

$ LINK/SHARE DYNSHARE + SYS$INPUT/OPTIONS
GSMATCH=LEQUAL,17,1	! choose a major ID
SYMBOL_VECTOR=(MAIN1=PROCEDURE)
$
$ LINK/SHARE SHARE1 + SYS$INPUT/OPTIONS
GSMATCH=LEQUAL,18,1
SYMBOL_VECTOR=(SHARE1=PROCEDURE)
DYNSHARE/SHARE
$
$ LINK MAIN + SYS$INPUT/OPTIONS
SHARE1/SHARE
$

  Now, all that's necessary to provide another routing is to create a
  shareable image that looks exactly like DYNSHARE - ie: compatible GSMATCH
  and same size symbol vector. Note that the routines need not have the same
  names, but any argument lists must match exactly.

ALTSHARE.FOR
	SUBROUTINE ALTSHARE
	PRINT*,'This is routine ALTSHARE'
	END

$ LINK/SHARE ALTSHARE + SYS$INPUT/OPTIONS
GSMATCH=LEQUAL,17,1	! Use same major ID
SYMBOL_VECTOR=(ALTSHARE=PROCEDURE)
$

  Next, define the logical name DYNSHARE to point to the alternate image

$ DEFINE DYNSHARE SYS$DISK:[]ALTSHARE
$ RUN MAIN
I am share1...now calling a routine in main...
This is routine ALTSHARE


  If you really want to (but I DON'T recommend it), you can use this mechanism 
  to introduce circularities in dependencies. For example, routine ALTSHARE
  could call routines in SHARE1, but since SHARE1 was linked against
  DYNSHARE (which doesn't depend on SHARE1) the LINKer can't see the
  circularity, it only happens at runtime.

  You can also use this method to provide a whole suite of alternate shareable
  images, selectable at run time by defining the appropriate logical name.

						John Gillings, Sydney CSC

It would appear, once more, that the creative genius of the Digital 
employee is still alive and well (just not with me.)
That's brilliant. Your precognition courses are paying off: that's 
just what I was looking for.
I had something almost there and was along the right lines, but it's 
going that last step to get to the end when you can't see where the
end is that's the trick, isn't it.

I hadn't thought about the find image symbol thing, the pointer thing
was the one which I have used in the past from Ada through binary 
trees and a gui builder thing (Not VUIT), which worked quite nicely, 
but they specifically requested not to do that. I don't know their 
reasons. 

Thanks for the pointer about the signal handling, it's an important
point which needs to be made if they are to understand where their 
problems are.

Are there any useful cookbooks out there for wizardry and tricks, a 
sort of Peter and Jane learn complicated VMS linking. I have spent 
many hours reading backwards and forwards through the linker manual 
and I have found it a difficult text.

Again, many, many thanks for the replies, I will now, with fresh hope
in my heart go about the rest of my work.

Neil.

re .1

>   I suspect you meant "OpenVMS Alpha"...

I probably did. But AXP VMS is quicker :-)

.3:Are there any useful cookbooks out there for wizardry and tricks, a 
.3:sort of Peter and Jane learn complicated VMS linking. I have spent 
.3:many hours reading backwards and forwards through the linker manual 
.3:and I have found it a difficult text.

    http://www.partner.digital.com/www-swdev/pages/Home
	/TECH/faqs/ovms/ovms-shexe-cook.html

.2:  I can't see any circularity in what .0 says, except that choice of
.2:  name of the "missing" routine might be construed as meaning the routine
.2:  which calls SHARE1. Assuming that's NOT the case:

   I was thinking specifically of a shareable image routine that was
   calling (directly) back to a routine in the parent via a "static"
   link -- these "loops" in the calling sequence tend to cause the
   LINKER to (rightfully) have fits, since all static references are
   not resolvable in a series of links, and since entry points in the
   parent image are likely to move around, potentially without the
   relinking of the shareable image itself.  (And without this relink,
   run-time mayhem would ensue...)