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