Browse Prior Art Database

Shadow Copies for unit Control Blocks

IP.com Disclosure Number: IPCOM000104891D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 110K

Publishing Venue

IBM

Related People

Merritt, AS: AUTHOR [+4]

Abstract

In a data processing system comprising of operating system and data structures, the technique of creating shadow control blocks to satisfy compatibility constraints is disclosed. Shadow control blocks (virtual copies) are created and surfaced to applications via the old data structures and interfaces. The real data structures are free to be changed (i.e., moved into 31-bit addressable storage).

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

Shadow Copies for unit Control Blocks

      In a data processing system comprising of operating system and
data structures, the technique of creating shadow control blocks to
satisfy compatibility constraints is disclosed.  Shadow control
blocks (virtual copies) are created and surfaced to applications via
the old data structures and interfaces.  The real data structures are
free to be changed (i.e., moved into 31-bit addressable storage).

      Users of MVS/ESA* need the ability to define increasingly more
I/O devices on the system.  Even if the 4096 device number limit is
removed, users will still not be able to define many more devices
because each device, defind currently, requires common area virtual
storage for a Unit Control block(UCB) with an address which can be
represented in 24 bits (less than 16 MB), wich is very limited.

      The UCBs can not be moved compatibly above the 16 MB line
without changig all programs that access the UCBs to be able to
access them there.  The number of software programs which access UCBs
is extremely large and affects IBM, vendors, as well as user
software.  To modify these programs or even to identify all programs
which have such a dependency on the residency of the UCBs is
impractical.

      Other problems exist even for programs which can handle 31-bit
addresses, but which extract the UCB address from the existing
interfaces (i.e., the Daa Extent Block, (DEB)).  These programs
expect a 3-byte UCB address and maclear the high order byte.  If the
DEB is changed to contain a 31-bit UCB address, these old programs
must be changed, as well as the programs that use the high- order
byte.  If the DEB UCB address is moved to another field, again these
programs will still have to change as well as the programs that build
the DEB.

      So, the basic problem is to allow a user to define up to 64K
devices without introducing incompatibilities which would make it
prohibitive, if not impossible, to migrate to the new release.

      The  solution  calls  for  the  system  to  provide "Shadow
UCBs", which will provide virtual storage constraint relief (VSCR)
for UCBs  by  allowing  real UCBs  to  be  kept  in  31-bit
addressable  storage  while  surfacing copies (Shadows) to
applications in 24-bit private storage (or...