HP 3000 Manuals HP 3000 Manuals
ALTERNATIVE FOR STORING SHARED CODE
Different languages differ both in the amount of control they give the
programmer (SPL provides relatively more, with, for example, all external
procedure calls made explicitly) and in their conventions for what code
may be placed in libraries. However, given any language, various
alternatives are available for you to use when you want to store code
that will be shared among programmers. Although there are arguments for
and against each method, there are few technical constraints. The method
you choose is more a function of your account structure, control
procedures, and personal preference than a technical issue.
Table 3-1 presents the advantages and disadvantages of five methods for
storing shared code.
RLs vs. SLs
If you have eliminated the other alternatives for storing shared code and
are trying to decide whether to use a Relocatable Library (RL) or a
Segmented Library (SL), consider the following:
* Does the routine require access to global storage? If so, it cannot
be stored in an SL.
* Is the procedure likely to be changed or enhanced? If so, what would
be the impact of having to re-prepare all the programs that use the
procedure?
* If you put the procedure in an SL (other than the system SL), will
you need it in other groups and accounts? If you do, will it be a
problem for you to maintain several copies of the procedure?
Table 3-2 summarizes for you some of the differences between RLs and SLs.
Table 3-1. Alternatives for Storing Shared Code
METHOD ADVANTAGE DISADVANTAGE
---------------------------------------------------------------------------------------
COMMON SOURCE CODE Easy to use. Requires no Changes to a common routine
use of the Segmenter may require recompiling
(Use the JOIN command of subsystem. many programs.
the EDITOR or the
equivalent facility of your Allows non-dynamic Compiler time is increased
programming language (such subroutines. since the common routine is
as COPYLIB in COBOL) to recompiled.
include the common source
procedures as part of the Possible conflicts with
source code for your main data or paragraph names in
program.) main program.
Does not allow mixing of
source languages.
---------------------------------------------------------------------------------------
AUXILIARY USL FILE Allows complete flexibility Requires extra commands in
in segmentation. JCL jobstream.
(Compile the procedure and
keep the USL file. Using Allows mixing of source Requires more Segmenter
the Segmenter, reference languages for main and expertise on part of
the procedure's USL file as subroutines. programmers.
the AUXUSL and copy the
required RBMs into another Allows non-dynamic Requires more control, good
USL that contains the RBMs subprograms. documentation of shop
for the main program.) standards and how to use
them.
No easy way to determine if
a program calls the
routine, since all
references are internal to
the object code.
---------------------------------------------------------------------------------------
USE AN RL Easy to use. (:PREP All referenced procedures
uslfilename; are brought into the
(Place the procedure in an RL=rlfilename.) program file as one
RL. All other programs that segment. For some
need the procedure are then Allows storage of programs, this segment may
simply prepared with the non-dynamic procedures. approach or exceed the
;RL=filename parameter.) configured maximum segment
Flexible: the RL can size.
contain all the common
procedures for your shop; A change to the RL
only the referenced procedure requires
procedures are linked to Segmenter manipulation and
the object code at PREP may require that all
time. programs which use the
procedure be re-PREPed. If
the program USL is not
available, you will also
have to recompile.
---------------------------------------------------------------------------------------
Table 3-1. Alternatives for Storing Shared Code(cont.)
METHOD ADVANTAGE DISADVANTAGE
---------------------------------------------------------------------------------------
USE AN RL (Continued) There is no way to clean or
expand an RL file. If you
run out of space you must
rebuild the RL from the USL
or from the source code,
which implies
recompilation.
---------------------------------------------------------------------------------------
USE SL.group.account or Allows for sharing of code Uses CST entries. (System
SL.PUB.account segments, i.e., every limit is 2048.)
program does not have its
(Place the procedure in an own copy of the procedure. Requires ;LIB= parameter
SL in the group where the If an SL procedure is each time an SL procedure
program file will reside or changed, no recompilation is used, although the
in the PUB group of that is necessary. various ;LIB= parameters
account. Programs that could be placed in UDC
need the procedure must be Program files are smaller. files.
run with the ;LIB=G (or P)
parameter on the :RUN Depending upon your account
statement, unless the structure, may require you
parameter is part of a to generate many SLs
UDC.) containing identical
procedures.
---------------------------------------------------------------------------------------
USE SL.PUB.SYS Same advantages as Difficult to make changes
SL.group.account but no to the system SL. It should
(Place the procedure in ;LIB parameter required. be done only via the
SL.PUB.SYS. The program SYSDUMP procedure and may
will not require the ;LIB= Allows for sharing of code require you to shut down
parameter.) on a system-wide rather your system to install any
than just an account-wide new procedures or changes.
level, minimizing duplicate
code modules.
You should make a new cold
Somewhat easier to control load tape after any change.
than many SL files.
More sharing of common code You will have to re-apply
could result in less your changes every time
swapping for some there is an update to MPE.
environments.
The entry point names of
your procedures may
conflict with those of MPE.
Even if you have no problem
currently, there is no
guarantee that the next
version of MPE will not
have a name which conflicts
with your procedure(s).
---------------------------------------------------------------------------------------
Table 3-2. RLs vs. SLs
RL SL
--------------------------------------------------------------------------------------
ALLOWS NON-GLOBAL PROCEDURES YES YES
--------------------------------------------------------------------------------------
ALLOWS GLOBAL PROCEDURES YES NO
--------------------------------------------------------------------------------------
RESOLVED AT PREP TIME YES NO
--------------------------------------------------------------------------------------
RESOLVED AT RUN TIME NO YES
--------------------------------------------------------------------------------------
CAN CONTAIN MORE THAN 1 NO YES
SEGMENT
--------------------------------------------------------------------------------------
FILE CAN HAVE ANY NAME YES NO*
--------------------------------------------------------------------------------------
CAN REFERENCE COMMON DATA YES NO
--------------------------------------------------------------------------------------
PERMANENT PART OF PROGRAM YES NO
FILE
--------------------------------------------------------------------------------------
*An SL file can be built and maintained with any name, but it cannot be
referenced at RUN time with the ;LIB= parameter unless the name of the
file has been changed to "SL".
Using SLs: Special Concerns
A good alternative for storing shared code is one that makes efficient
use of system resources as well as making it easy for programmers to
access and manage the code. Among the most critical system resources are
the Code Segment Table entries. The CST contains descriptive information
(whether the segment is in main memory or out on disc; whether running it
requires privileged mode capabilities) for each active SL segment. The
CST has space for 2048 entries, many of which are reserved for MPE
itself. (Other program code segments are kept track of in the CST
extension, or CSTX, a less valuable resource since it has more space
available.)
Entries in the CST are dynamically allocated by the operating system as
programs are loaded and overwritten. Execution of a program cannot
proceed if no room is available in the CST for the entry of the program's
SL code segments. Excessive usage of SLs could therefore exhaust the
currently available CST entries and cause serious disruption of all
executing processes.
You will probably not have problems with CST entries until your
installation is fairly large. But the groundwork for future difficulties
is laid when you and other programmers first begin to put code into SLs,
and a CST entry problem can be very difficult and time-consuming to
resolve by the time it becomes evident. The following preventive
measures are well worth the extra time and effort it takes to set them up
and train yourself and other programmers to use them consistently.
* Decide on installation-wide standards for what procedures are to be
kept in SLs. Consider both the type and the frequency of use.
* When several programmers are writing code, there is a tendency for
similar routines to proliferate, each in a different SL. Periodically
examine your SLs to see if they contain very similar procedures.
Decide on one procedure that serves everyone's purposes and purge the
others.
* Consolidate your procedures, placing those that reference each other
in one segment in the same SL.
* Make a habit of using the ;LMAP option on the :RUN command to see
where your SL references are being resolved from. If they are
scattered, coming from many different SLs, you need to make better
use of your SLs, and, in turn, of the CST entries available for
executing programs.
* If a procedure is common to several applications, consider putting it
in SL.PUB.SYS, instead of repeating it in many group and account SLs.
* Remember that the Segmenter (as well as the Loader) protects the
integrity of SLs by locking them while they are being accessed,
preventing their use by other users until the first user is finished.
Since SL.PUB.SYS is critical to the functioning of the entire system,
it is particularly important that you minimize the amount of time
this library is locked. The time involved for a reference to the
library is minimal compared to the time involved for the entry and
management of code. You can reduce this overhead and protect this
critically important library by designating one person to manage it
and scheduling entry and maintenance for off-hours.
* If you use multiple SLs, check each of them periodically and purge
any procedures duplicated elsewhere.