IBM System/370 145 Manual page 68

that required for certain tables, real storage is not required for
this partition until a job is actually scheduled. In OS/VS2, an
initiator with a special class can be started that will handle only
high-priority jobs,. This can be done in MVT as well but because of
the possibility of real storage fragmentation, there is no assurance
that the high-priority job can be started.
potential for Performance Improvement
The improved real storage utilization made possible by the use of
dynamic address translation hardware can have a positive effect on the
performance of a system that handles a job mix whose use of real storage
varies considerably while it is being processed. The extent of the
performance improvement depends on the types of applications involved
and the current utilization of system resources. Therefore, the amount
of performance gain, if any, that may be achieved is highly variable by
installation. Environments with the greatest potential for improved
performance are as follows:
58
• Batch-oriented multiprogramming environments with application
programs of widely varying real storage requirements.
Real storage may not be most efficiently used in such an environment
because (1) real storage can become fragmented when regions are
dynamically allocated and freed or (2) i t is difficult to divide
real storage into a set of areas that is optimum for all programs
when real storage is partitioned. (Consider the inefficient use of
real storage in a 54K partition allocated for assemble, link-edit,
and test jobs in which a 54K language translator, a 10K linkage
editor, and problem programs no larger than 40K execute.> In
addition, real storage is not efficiently used when the real storage
requirement of a given program, based on transaction mix or volume,
varies widely and the amount of real storage that is allocated is
designed to handle the peak requirement. (This is typically true of
graphics applications, for example.) Further, real storage assigned
to a program is not productively used during the time the program is
waiting for a human response, such as for the operator to locate
and/or mount a volume or to make a decision and enter a message on
the console, or during the time required to quiesce the system in
order to change partition definitions, start a high-priority job, or
start a long-running job in highest real storage, for example.
In a virtual storage environment, in Which all concurrently
executing job steps share real storage dynamically and use real
storage only when it is actually required for program execution,
real storage is more efficiently used. Hence, if real storage
currently is the restraint, a given real storage size might be
capable of supporting a higher level of multiprogramming than can be
achieved without the use of dynamic storage management (assuming
other required resources, such as CPU time, I/O devices, and
channels are available). For example, installation of a large
storage design point, terminal-based application to handle only a
few terminals might be possible. Alternatively, a higher level of
multiprogramming might be supported by the addition of a smaller
real storage increment than would otherwise be required.
system performance may also be improved if more efficient use of
available real storage enables additional heavily used functions to
be made resident instead of transient or allows the incorporation of
performance-oriented options in the control program. This
improvement can apply to environments with batch and online
operations, as well as to batch-only multiprogramming environments.
• Multiprogramming environments with a mixture of batch-oriented and
terminal-based applications.
A Guide to the IBM Syste~310 Model 145