consequently can always be amalgamated with the major free area. This is not always
further allocations of non-LIFO storage are made. stack and the necessary housekeeping fields will be placed at its head.
To keep track of the storage allocated and freed, a number of pointers are used.
These are:
• The beginning-of-segment pointer (BOS).
• The end-of-segment pointer (EOS).
• The next-available-byte pointer (NAB).
• The free-area chain pointer TFLE.
• A pointer to the byte beyond the end of the :rSA (TISA).
!he~1!!ning-of=~~gment Rointer l!2Q§}_ is initially set during program initialization to poin"t to the start of the ISA. It is
initially set during program initialization to point to the end of the ISA. However,
!h~_~~t-aY£!i!~Qle-Qyte~nter (NA!!L is held in every DSA and points to the first 8-byte boundary contiguous with unused storage. This address is the start of the acquired. Previous NABs are automatically restored when register 13 is pointed to a
"Acquiring a New segment."
rh~_frg~_~!g~_£hain.J22~!!ter TLFE. The free-area chain includes those eleroents of non-LIFO dynamic storage that have been
ALLOCATING AND FREEING LIFO STORAGE Allocating and freeing LIFO storage is handled by compiled code or by the
particular library module that requires the space. The allocation is done in the new allocation. For reasons explained later under the heading "Acquiring a New
To dummy DSA
~ I R13
I I
I _ _ _ _ Backchain (stored at fixed offset from R 13)
Main procedure DSA
NAB (stored at fixed offset from R 13)
I I
R13----~---~~~
(=old NAB)
Backchain (= old R 13)
Subroutine DSA
NAB
EOS--....
Allocating a new DSA
1. Test if major free area large enough for new DSA. If not call IBMBPGRC.
2. Store R 13 at fixed offset from old NAB to act as backchain.
3. Load R 13 with address of old NAB.
4. Store new NAB at fixed offset from register R 13.
Freeing a DSA
1. Load register 13 with current backchain address. Since the NAB and backchain fields are always addressed from register 13, the previous values are automatically restored.
Figure 6.2. principles involved in allocating and freeing LIFO storage
Chapter 6: storage Management 77
NAB
EOS
2nd allocation
1st allocation
Initial situation Two contiguous allocations of non-ll F 0 storage
NAB
EOS
3rd allocation
2nd allocation
1 st allocation
New allocation 1. Free-area chain?
No. (TlFE in TCA=O) 2. Allocate by altering
EOS pointer.
NAB
EOS
3rd allocation
2nd allocation
TlFE
Free 1st area 1. Is area next to
major free area? No.
2. Is area next to an area already on free-area chain? No.
3. PI ace area on free-area chain.
Figure 6.3. Principles involved in allocating and freeing non-LIFO storage
NAB
EOS
TlFE
3rd allocation
2nd allocation
4th 3tlocation
Further allocation 1. Free-area chain? Yes.
2. Find smallest area that will hold new allOCation.
Allocate at high-address end, leaving remaining area on free-area chain.
3. Alter length field at head of remaining area.
used depends on whether a VDA or a DSA is being acquired. The allocation of LIFO storage involves accessing the current value of NAB. This gives the address of the principles involved. Before allocating the storage, a test is made to see if there is enough space for the allocation. When there is insufficient space for a LIFO storage allocation, a new segment is acquired. (see below.)
ALLOCATING AND FREEING NON-LIFO STORAGE Any section of non-LIFO storage can be freed at any time; therefore a simple stacking mechanism cannot be used, because i t would waste storage by leaving freed the principles involved. Whenever an allocation within the major free area is segment, starting at hexadecimal "FF" and decreasing by 1 for each new segment. The addresses in later segments are apparently less than those in the earlier segments, regardless of their actual position. This simplifies segment handling. For instance, when a DSA in the second segment is freed,
IBMBPGR - STORAGE MANAGEMENT ROUTINE
The allocation and freeing of LIFO storage within a given segment is handled by
compiled code or by the library module requiring the storage. All other dynamic storage allocation is carried out by the resident library routine IBMBPGR; this module has four entry points:
IBMBPGRA IBMBPGRB IBMBPGRC IBMBPGRD
Allocate non-LIFO storage.
Free non-LIFO storage.
Obtain and free additional storage segments (for DSAs).
Obtaining and freeing additional storage segments (for VDAs).
Chapter 6: Storage Management 79
These four entry points are described below. In all cases storage is allocated in multiples of 8 bytes.
When entered by entry point IBMBPGRA, the module first searches the free-area chain,
(if one exists) and allocates the storage in the smallest possible area on the chain.
If there is no chain, or no area on the chain that is large enough, IBMBPGR attempts to allocate the storage in the area immediately preceding the EOS pointer.
If there is not enough space between the EOS pointer and the current NAB pointer, a GETMAIN macro is issued for the required storage. If the GETMAIN cannot be
satisfied, the system ends the job with an ABEND-code 80A. This ABEND is intercepted by the ABEND analyzer IBMBPES. IBMBPES puts out a message indicating which
statement was being executed and when the demand for storage was made. It then returns to the system to complete the ABEND.
Provided that storage can be allocated, control is passed back, with register 1 pointing to the address of the storage allocated.
Freeing Non-LIFO Stor~~_l!~MBPGR~l
When freeing non-LIFO storage or segments of LIFO storage IBMBPGR first tests to discover whether the element being freed is within the ISA. This is done by seeing if the address is between the value held in register 12, the address of the TCA, and the value held in the TISA field of the ISA which points to the end of the ISA. If the element is outside the ISA i t must have been acquired with a GETMAIN macro
instruction. It is therefore freed with a FREEMAIN macro instruction.
If the eleroent to be freed is within the
ISA~ the module scans the free-area chain (if one exists) to see whether the storage
being freed can be amalgamated with areas already on the chain. This is done if possible. The module then checks to see whether the storage being freed is adjacent to the major free area. If so, EOS is altered to point to the end of the area being freed or to the end of the
amalgamated area, if this adjoins the major free area. If the element cannot be
amalgamated with any other, the area is added to the free-area chain, which is arranged in descending order of addresses.
The format of a free area chain eleroent is shown in figure 6.4.
Or---,
Length of element in bytes 4 Pointer to area with lower address,zero if last element
Unused storage
L---J
Figure 6.4. Format of element on free area chain
When compiled code discovers that the address contained in the pointer NAB plus the length of the new DSA or VDA to be allocated is greater than the value of the pointer EOS, IBMBPGR is called either at entry point C or entry point D depending on whether the storage is required for a DSA or for a VDA. Entry point C is used if a DSA is required, entry point D, if a VDA is required. The difference is the method used to store the caller's registers~
IBMBPGRC stores the caller's registers in a special save area in the TCA, because no DSA has yet been acquired; IBMBPGRD stores the registers in the caller's DSA, in the usual manner.
BaS
NAB
EOS
TLFE
Initial situation 1. Free·area chain exists.
BOS, NAB, and EOS have X'FF' in first byte, i.e., segment number 1.
BOS ---'~---,
EOS
BaS R13
NAB
EOS
TLFE
Acquiring new segment 1. Compiles code or library
routine finds major free area too small. Calls IBMBPGR.
2. IBMBPGR finds an area on free·area chain large enough for allocation.
3. Stores old BOS and EOS.
Sets new BaS and EOS, and returns to caller.
4. Caller gets new DSA.
BOS, EOS, and NAB have X'FE' in first byte, i.e., segment number 2.
new se!JTIent
BaS .---~>~---~
NAB
EOS
BaS
EOS
TLFE
Freeing DSA in segment 1. Register 13 is restored in
the normal way. BOS and EOS are not restored. The segment will not be freed unti I there is a further demand for storage, that can be accommodated in the previous segment.
2. NAB now has X'FF' in first byte, BOS and EOS still have X'FE'.
BaS
R13 NAB EOS
TLFE
Figure 6.5. Principles involved in allocatin~ and freeing segments of PL/I dynamic storage
Freeing segment
1. When storage is ag'lIik. required, NAB + storage required is compared with EOS using logical arithmetic.
2. NAB + storage is found to be greater (because of different segment numbers). so IBMBPGR is called.
3. IBM BPG R finds segment numbers are different. Tests to see if new storage will fit in old segment. If not, allocates in current. segment.
4. Storage will fit, so restores old BOS and EOS, places segment on free·area chain, and returns to caller.
5. Caller allocates storage starting at current NAB.
The entry points are called in two
described for IBMBPGRB above.
When only one empty segment remains, a
comparing the difference between the
current BaS and EOS with the length of the free-area chain can immediately follow EOS.
However, the possibility is remote, and no
6. The number of FREEMAIN macro loaded during program initialization, instead of the normal storage management and stack overflow requests.
The storage report is issued during program termination. The termination
routine~ IBMBPIT, calls the report writing module, IBMBPMR. The report is transmitted to the dump file.
During program initialization, if REPORT has been included in the parameters passed
Consequently~ the stack overflow routine (IBMBPGD, entry point C or D) is called.
On termination, the termination routine, IBMBPIT. calls the storage report writing module, IBMBPMR, which transmits the storage report onto the dump file.
The amount of PL/I storagre required is calculated by adding the figure described in (1) above to the ISA Size used. The generated. This smaller size should be used. This discrepancy is caused by the differences in acquiring
Chapter 6: Storage Management 83
stol:age inside and outside the ISA. different storage requirements.
The modules IBMBPGD, IBMBPMR, and the initialization and termination modules are fully described in PL/I transient library program logic manual.
Storage ~~Q~fQf-~ultitasking
frograms
storage reports for multitasking programs are generated in the same way as those for non-multitasking programs. A special storage management module is loaded at execution time, and this retains statistics of the amount of storage used. To ensure this module handles all requests for storage, the value in EOS is set to zero, and the true EOS value is retained in the report table. The report is issued during program termination by the module IBMBPMR.
For a multitasking storage report the following information is given:
For the major task: non-multitasking counterpart. These are:
IBMTPGDE - called when a task is increasing the maximum number if necessary.
IBMBPGDF is called when a task is terminated. If the terminated task is a subtask, IBMBPGDF completes the relevant field in the subtask storage report table, from information in the report table of the terminating task.
During initialization, space is required by the control task for a combined subtask report table which will hold the
information from which the merged subtask report will be generated. During the