Article 132687 of comp.os.vms:
Path: nntpd.lkg.dec.com!crl.dec.com!crl.dec.com!caen!spool.mu.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!homer.alpha.net!mvb.saic.com!info-vax
From: Jerry Leichter <leichter@lrw.com>
Newsgroups: comp.os.vms
Subject: RE: shareable library questions
Message-ID: <9510270145.AA03751@uu3.psi.com>
Date: Thu, 26 Oct 95 21:42:50 EDT
Organization: Info-Vax<==>Comp.Os.Vms Gateway
X-Gateway-Source-Info: Mailing List
Lines: 107

	After being spoiled by UNIX tools and environments, I once again have
	to develop on VMS as well.

	I created a shareable library. It uses routines in an other shareable
	library that I also created. My aim is to transparently upgrade the
	libraries as needed so that client programs don't have to be relinked.

	questions:

	1) In my options file, why do I have to explicitly define 
	every function that I'm going to use with the universal keyword?

	If I don't, every client program gets undefined symbols when linking.
	Isn't there a way to pick up any undefined symbols just as if  a
	static library was used?

At one time, there was a UNIVERSAL=* option, which made all global symbols
universal; but that was dropped years ago.  As with many restrictions, this
one seems petty until you step back and understand the reasoning:  If you
use an object library, you get only the modules you ask for.  If you use a
shareable image library, you get *all* the symbols.  Hence, it's essential
to keep control over the names dumped into the namespace of any program that
links against the library.

It is *not*, however, necessary to list every symbol in a UNIVERSAL option.
In fact, under normal conditions, you should need few if any UNIVERSAL
options at all, because you should be using transfer vectors - and transfer
vectors automatically produce universal symbols with no further action on
your part.

	2) It seems that to transparently replace a shareable library without
	relinking the clients, I have to create a "transfer vector"?  Using
	VAX/MACRO possibly, with a predefined number of placeholders for
	current and future functions calls? Is this right? Sounds ridiculous
	to me, but the manual confirms (seems to) this.

For VMS VAX, this is true - but what's the big deal?  The MACRO you need to
write is highly stylized.  Here's how I do it:

	.TITLE		TRANSFER - Transfer Vectors
	.IDENT		'V01-000'
	.PSECT		TRANSFER_VECTORS,CON,EXE,GBL,PIC,SHR,RD,REL,NOWRT

START:
	.TRANSFER	LindaID			;Get unique ID
	.MASK	LindaID
	JMP	L^LindaID+2

;...[any number of these]...
	.TRANSFER	LindaLogger		;Get Logger file
	.MASK	LindaLogger
	JMP	L^LindaLogger+2

;...[*always* add new ones here]...
RESERVED:
	.BLKQ	64-<<RESERVED-START>/8>		;64 total vectors available
						; (one page of vectors)

	.END

It's simple to create a macro to generate each entry, but I find it just as
easy to cut and paste.  Just make sure you always add new entries at the end,
and *never* delete an entry:  If a routine becomes obsolete and you want to
"de-support" it, replace it with a routine that reports an error.

If you ever think you'll need more than 64 vectors in all, change the "64" in
the .BLKQ to reserve more space.  Each vector is 8 bytes long, and you'll
always end up allocating an even number of pages, so the number you use should
probably be a multiple of 64.

Assemble with:

	$ MACRO TRANSFER

and add TRANSFER.OBJ to your list of object files.  Also include something
like the following in your options file:

GSMATCH = LEQUAL,1,0			!May change, of course
CLUSTER = TRANSFER_VECTORS
COLLECT = TRANSFER_VECTORS,TRANSFER_VECTORS

The only thing that ever changes is the list of entry points, and that will
typically change only rarely.

By the way, VMS on the Alpha no longer uses this method for specifying
transfer vectors - it's done entirely in the options file.

	Are shared libraries really this hard to use on VMS? Are my
	expectations (create a shareable library, then simply use it to
	compile and run programs, and update it without consequence to image
	entry points and the like) far fetched? 

Considering that VMS has had shareable libraries since the mid-70's, while
they began to appear in Unix only in the last couple of years, you might
expect that the new, imitative implementations would improve things a bit!

On the other hand, I think you'll find that your expectations aren't fulfilled
quite to the degree you think they are.  Every Sun system I've seen has a
couple of versions of each shareable library around, since in general Unix
shareable libraries are *not* upward compatible.  Sun's implementation even
has something like VMS's file version numbers on its shareable images to
support this.  In VMS, on the other hand, upward compatibility is so strongly
assumed to be the common case that it can be quite tricky to support more than
one version of a shareable library.  In fact, until very recently, it was
impossible to have two versions of the same shareable library INSTALL'ed
simultaneously without hackery.
							-- Jerry