Browse Prior Art Database

Locating Free Pages in a Large Data Page Set

IP.com Disclosure Number: IPCOM000118623D
Original Publication Date: 1997-Apr-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 48K

Publishing Venue

IBM

Related People

Belding, GP: AUTHOR

Abstract

Large data storage systems typically organize data for storage and recovery in modules which can be readily identified for management by the system. For example, in an IBM Multiple Virtual System (MVS) an "MQSeries for MVS/ESA* page set is a VSAM LINEAR disk data set, that consists solely of 4K long data areas called pages". These pages hold the hardened form of user messages.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 58% of the total text.

Locating Free Pages in a Large Data Page Set

      Large data storage systems typically organize data for storage
and recovery in modules which can be readily identified for
management by the system.  For example, in an IBM Multiple Virtual
System (MVS) an  "MQSeries for MVS/ESA* page set is a VSAM LINEAR
disk data set, that consists solely of 4K long data areas called
pages".  These pages hold  the hardened form of user messages.

      The first page (Page zero) of each page set is used for control
purposes.

      The next page, known as a space map, controls and shows the
allocation of the next 16,228 pages, which are available for the
permanent storage of user messages.

      A page set can hold 1,048,575 pages, which are controlled
through the use of 65 space maps.

      In such a system, when a user application originates a message,
it is necessary to find one or more empty pages in the page set in
which to store it using an MQPUT request.

      This requires each space map starting with the first and, if
necessary, ending at the 64th, until the required number of pages
have been found.

      This process can take between 1,200 and 73,000 CPU
instructions, and even when an empty page has been found, the next
application request that provides a message to store will cause
exactly the same (long) scan to take place.

      When a page set is nearly empty, little CPU time is expended in
finding the next empty page.  However, when...