gtps4m0tSystem Generation

Working Storage

The size of working storage is a function of the amount of main storage required by an average message, the life of the message in the system (ECB life), and the number of messages per second to be processed. The elements allocated are entry control blocks (one per entry), programs required from file storage, data blocks either created in main storage or transferred from file storage, and message blocks.

Working storage is divided into five areas: 4K common blocks, 4K frames, ECBs, SWBs, and IOBs.

Input/output control blocks (IOBs) are blocks created by the control program to schedule, control, and contain the information required to perform I/O operations. IOBs are located in main storage in the control program records and table area. The SIP macro CORREQ contains an IOBLK parameter which is used to specify the number of I/O blocks required.

System work blocks (SWBs) are blocks created by the control programs. MPIF uses SWBs for output message queuing and control program user exit parameter lists. MPIF-IPC uses SWBs to track usage of core blocks for long SIPCC messages. SNA uses SWBs for scheduling postinterrupt routines.

SWBs are located in main storage in the control program records and table area. The SIP macro CORREQ contains an SWB parameter that you use to specify the number of SWBs required. (For more information on SWBs, see Storage Required For Control Blocks and CORREQ.)

For the MDBF user of the HPO feature the allocation of working storage is done by subsystem (SS), that is, there is a CORREQ macro for each SS including the basic subsystem (BSS). The considerations for each SS are the same except for one additional concern for the BSS, which also affects non-MDBF users. When allocating the 4K blocks in the BSS, the internal trace table uses either one or two 4K blocks, and there must be at least seventeen 4K blocks allocated for keypoints. In a non-BSS subsystem, there are a minimum of eight 4K blocks required for each SS's unique keypoints.

The following design criteria may be used as a guide to determine the number of each size block required for a particular application and system message rate. If the total amount of main storage is insufficient to allocate the necessary amount of working storage, the user should redesign his main storage layout by altering the number of programs in the application program area (see Application Program Areas).

Users should be aware that reducing the number of core resident programs increases the number of core blocks required for program storage and file accesses, which increases the message life and, consequently, increases the system working storage requirements.

Another factor that could affect the amount of working storage needed is the program nesting level. One can assume that the more programs are nested, the more working storage will be needed unless programs being entered are already in main storage. Users must determine the best main storage balance for his system.

The amount of main memory required for each message is application dependent and difficult to calculate. It can be observed on an operational system by using system monitors and data collection runs where this data is used to verify the design, tune the system, and make projections. Therefore, for this document, a default value of 4700 bytes per message will be used for mean working storage size. To provide sufficient working storage, a message arrival rate peaking factor of 2.3 can be used; this represents a 99 percentile standard deviation above the mean value. The estimated working storage requirement per message then becomes 4700 × 2.3 = 10 810 bytes per message.

The life of the message in the system is really the life of the ECB and consists of the processing time plus database access time. What this means is that 9200 bytes/message are tied up for the duration of time expressed as the ECB life.

The term messages as it is used in this section refers to the system message rate in messages per second.

The following formulas may be used to estimate the initial number of working storage blocks required for a particular application:

Let: S15   =   Total working storage required (See Figure 9)
     S     =   Maximum memory required for each message
     M     =   Message life
     R     =   Messages per second
     C     =   CPU process time per message
     A3    =   Access plus queue time per DASD device
     F3    =   Number of accesses to DASD per message
     I     =   Number of instructions per message
     p p1  =   CPU model performance = instructions per second

There is also a 4K storage block requirement for interprocessor communications (IPC) in a loosely coupled environment:

Assumptions:

Channel utilization for DASD device is no more than 50% of the rated capacity.

AAA/RCB records must be brought into high-speed memory (VFA).
p p1 = 2 280 000 instructions/sec
I = 14 600 instructions per message (average)
S = 10 810 bytes of memory per message (maximum)
A3 = .09 sec
F3 = 4.5

Then:

C = I/P = (14600/2280000) = .0064 sec.

M = C + F3 × A3 = .0064 + (4.5 × .09) = .4114 sec.

S15= S × M × R = ______ bytes

Working storage may be computed for a design objective of attaining 80 messages per second, for example, as follows:

W80 = S × M × R

= (10 810 × .4114 × 80)

= 355 779 bytes (maximum load)

This estimate provides a general idea of main storage requirements (S15). It can be checked against the default sizes for main storage structures.

Table 2. Main Storage Structure Sizes

Main Storage Structure Default Number Default Storage (bytes)
4KB frames 200 819 200
Common frames 50 204 800
12KB ECBs 100 1 228 800
IOBs 100 25 600
SWBs 100 50 400
24-bit core resident programs 75 76 800
31-bit core resident programs 1000 1 024 000
Note:
The size of an ECB is fixed at 12KB.

The requirements for these values must be considered in the light of site dependent factors, such as anticipated message rate. Users of TPF 3.1 may use the percentage numbers from that system as guidance. As general rules-of-thumb some sites consider an adequate number of 4KB frames to be 10 times the number of ECBs; the number of IOBs is slightly smaller and the number of SWBs is larger than in TPF 3.1 because some functions formerly using IOBs are using SWBs.

The size of the ISO-C stack, ECB heap, and the ECB private area of 1 MB can affect the number of frames and ECBs allocated by the TPF 4.1 system. The size of the area occupied by the frames and the ECBs must be greater than or equal to the maximum size of the ISO-C stack plus the maximum size of the ECB heap plus the size of the ECB private area of 1 MB.

The following equation can be used to evaluate if you have enough storage:

#ECBs × 12K + #Frames × 4K >=  (ESPS + EMPS + 1) × 1M

The TPF 4.1 system will increase the number of ECBs and frames until this condition is satisfied or the system runs out of storage.

The numbers of system structures required are entered into SIP using the parameters of the CORREQ macro.

These numbers are starting points only and will require tuning after the system is in use and data collection/reduction has been executed and analyzed. One strategy for defining main storage requirements is to let the parameters default. The values may be adjusted online using the ZCTKA command.