Browse Prior Art Database

Disk Label Area on Native Data Space

IP.com Disclosure Number: IPCOM000112913D
Original Publication Date: 1994-Jun-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 104K

Publishing Venue

IBM

Related People

Schroeder, W: AUTHOR

Abstract

In the current version of the VSE/ESA operating system, the customer has the opportunity to place the label area onto a virtual FBA disk. While this helps in saving Input/Output (I/O) time when labels are written or read from this area, it is still not the optimal solution as any access to the label area must be triggered via an SVC 0. This blocks other I/O requests and the entire virtual I/O is simulated via software. This article describes a system in which the label area is placed within the data space directly. This has the advantage that it removes all I/O handling from the current label handling module and replaces it by data moves to and from the data space. This not only increases the performance but also reduces the size of the module by one third. and avoids all I/O simulation.

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

Disk Label Area on Native Data Space

      In the current version of the VSE/ESA operating system, the
customer has the opportunity to place the label area onto a virtual
FBA disk.  While this helps in saving Input/Output (I/O) time when
labels are written or read from this area, it is still not the
optimal solution as any access to the label area must be triggered
via an SVC 0.  This blocks other I/O requests and the entire virtual
I/O is simulated via software.  This article describes a system in
which the label area is placed within the data space directly.  This
has the advantage that it removes all I/O handling from the current
label handling module and replaces it by data moves to and from the
data space.  This not only increases the performance but also reduces
the size of the module by one third.  and avoids all I/O simulation.

      For all sequential processing of labels (e.g., add labels, get
next label of same group etc.) the concept of the 'I/O area' can be
kept.  This means that labels are collected in a 2K buffer and after
the buffer is full the AR mode is switched on and the buffer is moved
into the data space.  Also if the entire contents of the buffer are
needed, the buffer is moved from the data space into the current
address space and then processed.  Only the search for an individual
label is done in the data space directly.  This guarantees good
performance and clear code.

      Using this idea, the capacity of the label area can also be
increased.  Currently, the space of the label area is controlled in
units of 2K blocks, i.e., whenever space is needed, the label
handling routine looks for a free 2K block and assigns it to the
label subarea that needs the space.  To control the 2K blocks a
master bit table exists where each available 2K block is represented
by one individual bit.

      For each static permanent label subarea (e.g., BG perm) there
exists a work area in storage containing a pointer for the first
block and a copy of the master bit table with all bits off.
Assigning a block to a subarea means switching off the appropriate
bit in the master table (making it unavailable for other requests)
and turning on that bit in the table of the subarea.  Also the
pointer must point to that block if it is the first one in a chain.
If more than one block is needed, the blocks are chained together.

      For the temporary label areas there exists a pool of 200 work
areas from which one is occupied when needed and is then used in the
same way as described above.

      Thus there is a mixture of direct addressing and table search
to find the work area for the appropriate label subarea.

Such a solution has the following problems:

o   There are not enough work areas for the maximum number of
    partitions.

o   The length of the bit table is 33 bytes which is only enough to
    handle about 3000 labels if there are not too many label
    subareas.

o   Inconsistent addre...