Browse Prior Art Database

Dynamic Linking in the System/370 and System/390 Architectures Disclosure Number: IPCOM000122562D
Original Publication Date: 1991-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 5 page(s) / 199K

Publishing Venue


Related People

Ewart, GW: AUTHOR [+1]


This article describes an improved alternative to the client-server model.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 34% of the total text.

Dynamic Linking in the System/370 and System/390 Architectures

      This article describes an improved alternative to the
client-server model.

      Application programs are "clients" requesting program services
from a PI server.  A request is issued by invoking a function, or
verb, by name.  Initially, the client calls an initialize verb to
initiate a server session to which the server returns a token.  The
token identifies a unique client and is passed to the server on
subsequent calls. When the client no longer needs service, it
requests the server to terminate.

      A Programming Interface (PI), developed using a High Level
Language (HLL) for 370/390 environments, must possess certain unique
characteristics.  A single copy of the PI code must be shareable at
runtime by all programs (in whatever programming language and
addressing mode) invoking it in the multiuser and multiaddress space
system.  That is, each user program cannot afford to link in one
individual copy of the PI code into itself as they become
prohibitively large.  The PI code must also be sufficiently detached
from its client programs such that enhancements or fixes to it do not
require its user to relink their programs.  This article addresses
all these requirements for PIs written in any 370/390 HLL.

      In this alternative, the server possesses its own runtime
environment precluding any conflict with and dependence on the
client's environment.  In addition, the server or client may operate
in any addressing mode (AMODE). The client statically links into
itself small stubs when it is built.  These stubs then access the
much larger server code at runtime.  That is, the client dynamically
links to the server.  A single copy of the server code is installed
globally on the system for sharing by all clients.  Fig. 1
illustrates this concept.

      The server can be implemented as a runtime load library
installable into a Discontiguous Shared Segment (DCSS) on VM or the
Link Pack Area (LPA) on MVS.  This makes the server available to any
user on the system.  The server can also be installed for use locally
within a userid.  This is done by loading it into the user's nucleus
extension or global loadlib list on VM or the STEPLIB DD
concatenation on MVS.

      In this instance, the server was written in C. However, this
solution is applicable for servers written in any 370/390 HLL.  There
are six components to this invention.
           Stubs:  For each PI verb there will be an Assembler csect
bearing the verb entry point name that is statically linked with the
application and operates in the same AMODE as the caller.  Each stub
will store the client's environment (registers) and then set up the
server's environment, look for the server and branch to it, switching
AMODE, if necessary.  The stubs are written in Assembler to make them
readily and directly callable from almost any language client.