Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Control Block Pool Expansion Contraction

IP.com Disclosure Number: IPCOM000052949D
Original Publication Date: 1981-Aug-01
Included in the Prior Art Database: 2005-Feb-12
Document File: 4 page(s) / 34K

Publishing Venue

IBM

Related People

Hitch, LC: AUTHOR [+2]

Abstract

The allocation and deallocation of some control blocks in MVS (Multiple Virtual Storage) cannot tolerate the overhead of GETMAINs and FREEMAINs for the storage used by the control blocks. Thus, control block pools are maintained to allow fast allocation and deallocation of these control blocks. The purpose of these control block pools is to minimize the number of GETMAINs and FREEMAINs during system equilibrium but not necessarily during extremely high periods of control block use. Note that they cut down the number of GETMAINs and FREEMAINs but do not eliminate them altogether. It is not significant for a few GETMAINs/ FREEMAINs to be done over a period of time, but it is significant if hundreds or thousands are done in the same time period.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 32% of the total text.

Page 1 of 4

Control Block Pool Expansion Contraction

The allocation and deallocation of some control blocks in MVS (Multiple Virtual Storage) cannot tolerate the overhead of GETMAINs and FREEMAINs for the storage used by the control blocks. Thus, control block pools are maintained to allow fast allocation and deallocation of these control blocks. The purpose of these control block pools is to minimize the number of GETMAINs and FREEMAINs during system equilibrium but not necessarily during extremely high periods of control block use. Note that they cut down the number of GETMAINs and FREEMAINs but do not eliminate them altogether. It is not significant for a few GETMAINs/ FREEMAINs to be done over a period of time, but it is significant if hundreds or thousands are done in the same time period.

Some control block pools may be allowed to expand but not be allowed to contract. To expand/contract a control block pool means to increase/decrease the number of control blocks contained in the pool. This may be a problem in some cases. During some functions (e.g., subsystem startup) many control blocks may be needed. This may cause the pool to expand to the maximum size or near the maximum size. In the ``equilibrium state'' of system operation (i.e., after the initial startup functions are completed), very few control blocks may be needed. Thus, a lot of storage may be unnecessarily ``wasted.'' If the pools could be contracted as well as expanded, this storage could be reclaimed and returned to the system. Therefore, a method of expanding and contracting control block pools is proposed. In the following discussion the control block pool will be referred to as ``the Pool'', and the control block(s) in the Pool will be referred to as ``CB(s)''.

The Control Blocks are chained together forming a linked list. The last CB in the list contains a zero or null value for the forward chain, indicating the end of the list. The first CB (the head) in the list is pointed to from a Pool Header. The CBs are removed from the head of the stack and returned to the head. Thus, the structure of the CB Pool is a LIFO (last in, first out) stack. CBs may be taken off the Pool Chain, used by the user for whatever need he has, and placed back on the Pool Chain for someone else to use later. Note that the CBs do not necessarily return to the Pool in the same order that they are removed from the Pool. This means that the ``order'' of the CBs in storage does not indicate anything about their order in the CB Pool.

The Pool of control blocks is constructed by obtaining a block of storage via GETMAIN. This block of storage is then subdivided into the control blocks of the needed size. These control blocks are then chained together and added to the already existing Pool.

The following control information is needed about each of these blocks of storage: (1) An outstanding (in use) count of CBs from the block of storage which is in use, i.e., not in the Pool. (2) An indicator that con...