Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!BLUTO.SCC.COM!briggs%gburg.DECnet
From: briggs%gburg.DECnet@BLUTO.SCC.COM ("GBURG::BRIGGS")
Newsgroups: comp.os.vms
Subject: transfer vectors
Message-ID: <8707230304.AA14642@ucbvax.Berkeley.EDU>
Date: Wed, 22-Jul-87 09:26:00 EDT
Article-I.D.: ucbvax.8707230304.AA14642
Posted: Wed Jul 22 09:26:00 1987
Date-Received: Sat, 25-Jul-87 02:49:25 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: "GBURG::BRIGGS" 
Distribution: world
Organization: The ARPA Internet
Lines: 43

In article <2961@blia.BLI.COM> forrest@blia.BLI.COM (Jon Forrest) writes:
>For example, let's say that a sharable image contains variable A which
>is 10 bytes long and begins at location 100 and variable B which is
>20 bytes long and begins at location 110. We can assume both are
>universal symbols. The user links an application program that references
>both variables with this sharable image. Everything works fine.
>Meanwhile, the software developer who sold the user the shareable
>image modifies variable A so that it now is 20 bytes long. This
>means that variable A begins at 100, as before, but now variable
>B now begins at location 120. Then, the user receives this new
>shareable image and, much to his consternation, finds that his
>program bombs every time he references location B.

Randy Buckland answers:
>The solution is really simple. Have a section of code that will
>always be at a fixed address and will contain pointers to the data structures.
>The pointers will always be 4 bytes and the addresses won't change. You
>can change the size of the structure and you could even change it
>at run time and the program won't care since it always accesses it through
>the pointer that is in a known location.

Good point, Randy, but not applicable in this case.  If somebody is changing
variable lengths on you, all the indirection in the world won't solve the
problem.  You not only have to relink, you have to modify source code and
recompile!

Juergen Renz flames:

>Your [sic] wrong Randy !
>One transfer vector takes up to 8 bytes (entry routine):
>...
Again, good point, but not applicable here.  The problem is access to variables,
not access to entry points.  If Mr. Forest had been trying to CALL or JSB into
the shareable image, a 6 or 8 byte transfer vector would be required.  Since
he only needs to access variables in the image, 4 byte longword pointers are
quite adequate.

	John Briggs		Arpa:	BRIGGS@BLUTO.SCC.COM
				MA:	(301)840-4932
				Snail:	Vitro Corporation
					14000 Georgia Ave.
					Silver Spring, MD  20906
+----83