Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!lll-lcc!pyramid!voder!blia!forrest
From: forrest@blia.BLI.COM (Jon Forrest)
Newsgroups: comp.os.vms
Subject: Are Transfer Vectors Truly Useful When Creating Shareable Images?
Message-ID: <2961@blia.BLI.COM>
Date: Thu, 16-Jul-87 19:16:38 EDT
Article-I.D.: blia.2961
Posted: Thu Jul 16 19:16:38 1987
Date-Received: Sat, 18-Jul-87 11:00:53 EDT
Organization: Britton Lee, Berkeley, CA
Lines: 65

This is something that's been on my mind for a while. I'd like to
talk this through to see if any of you can find something wrong in what
I'm thinking.

The software product my group produces consists partially of
shareable images. Most system managers and users expect shareable
images they receive to be upward compatable, that is, they
don't expect to have to relink with new shareable images
when a new version of a software product arrives. This is because
most shareable images begin with a series of transfer vectors
which allow new versions of shareable images to replace old
ones without relinking for reasons that are documented in
the LINKER manual.

Transfer vectors work fine as long as the only difference
between shareable images is the size of the code size of the
routines in the shareable image. What concerns me is the effect
of a change in the size of any global data structures represented
by universal symbols. It appears to me that such changes would result
in incorrect addresses being used when data appearing after the enlarged
structure is referenced.

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.

The answer to this problem is probably that the major G.S. match id
should be incremented whenever such a situation occurrs. This, of
course, would require that the application be relinked, which negates
one of the primary benefits of sharable images. Indeed, my company
doesn't even bother with transfer vectors because keeping track of
the sizes of all data structures for which universal symbols exist
is simply too difficult. Unfortunately, users of our software must
relink with each release.

What is actually needed is a "transfer vector" for universal symbols
in addition to entry points. If such a thing were to exist then
universal data could be modified at will. Unfortunately, I can't think
of a way to implement transfer vectors for data without major
modification of the linker.

Have any of you faced this problem? If so, what did you do?
One person I discussed this problem with recommended that
universal symbols never be used directly but instead, a function
would be created whose job it is to return the address of a
universal symbol. This function could be called in a initialization
routine at the beginning of an application so that pointers
to universal symbols could be set before they are used later
in the program.

I'd like to hear anyone's response to this problem.

Jon Forrest

forrest@blia.BLI.COM
ucbvax!mtxinu!blia!forrest
{pyramid|voder}!blia!forrest