Browse Prior Art Database

Dynamic Quickcell

IP.com Disclosure Number: IPCOM000081585D
Original Publication Date: 1974-Jul-01
Included in the Prior Art Database: 2005-Feb-28
Document File: 4 page(s) / 120K

Publishing Venue

IBM

Related People

Abshire, GM: AUTHOR

Abstract

Dynamic Quickcell is described in the November, 1973, issue of the IBM Technical Disclosure Bulletin Vol. 15, No. 6, pages 1999-2004. Described herein is an improvement on Dynamic Quickcell including a look-ahead feature to assure that an adequate reserve of storage space in a Mass Storage Facility (MSF) is available, and a continuous automatic retry feature when Mass Storage System (MSS) temporarily runs out of storage.

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 53% of the total text.

Page 1 of 4

Dynamic Quickcell

Dynamic Quickcell is described in the November, 1973, issue of the IBM Technical Disclosure Bulletin Vol. 15, No. 6, pages 1999-2004. Described herein is an improvement on Dynamic Quickcell including a look-ahead feature to assure that an adequate reserve of storage space in a Mass Storage Facility (MSF) is available, and a continuous automatic retry feature when Mass Storage System (MSS) temporarily runs out of storage.

The heart of the Quickcell mechanism in Mass Storage Control (MSC) are collections of information called pool controllers, one for each pool of cells. Each controller contains several fields among which are the pointers to a primary queue of cells and to a secondary queue of cells.

During initialization, the original storage for each pool is obtained and divided into cells, all of the same size within a pool. The cells are chained together and a pointer to the first cell is placed in the secondary queue pointer field of the pool controller. The rest of the pool controller is then initialized.

Newly formed cells are entered into the secondary queue. Whenever a cell is requested, the primary queue is first checked for available cells; if there are none, the secondary queue is checked in turn. If a cell is found in the secondary queue and removed, the secondary queue is checked to see whether it contains a sufficient reserve of cells. If nut, an extension to the secondary queue is requested. When a cell is returned to its pool, it is placed in the primary queue.

The QCELL macro generates PLS statements to obtain a cell, and when the need arises, to call for an extension to a pool. It also generates statements to return the cell to its pool after use.

When a pool needs to be extended, the QCELL macro generates instructions that call the SCHESRB module. That module takes control and, after initial housekeeping, attempts to get a cell for a Service Request Block (SRB). If...