Jump to content

Basic partitioned access method

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Peter Flass (talk | contribs) at 00:48, 20 August 2016 (add API section head and move paragraph). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In IBM mainframe operating systems, basic partitioned access method (BPAM)[1] is an access method for libraries, called partitioned datasets (PDSes) in IBM terminology. BPAM is used in OS/360, OS/VS2, MVS, z/OS, and others.

A PDS consists of members (internally identical to sequential data sets), registered in a list called the directory. The combination of members and directory is a single dataset on disk. The directory contains a list of member's names (8 characters, padded on the right with blanks, as required) and member's addresses. Addresses are relative to the start of the dataset in order to allow the PDS to be moved to a different disk location.

Partitioned datasets can store any type of data, but they are often used to store executable programs, or load modules, sometimes called binaries in other systems. Other uses include system assembler macro definitions, job control procedures, and program source code.

Application program interface

BPAM provides an application program interface (API) to allow programmers to access libraries directly. The BPAM API is similar to basic sequential access method (BSAM), but it adds functionality to process directories. Individual members of a PDS can also be processed using sequential access methods by specifying the member name on the job control DD statement.

As a basic access method BPAM reads and writes member data in blocks and the I/O operation procedes asynchronously and must be tested for completion using the CHECK macro.[2] BPAM uses the standard system macros OPEN, CLOSE, READ, WRITE,and CHECK. BLDL builds a list of the addresses of members specified by the programmer for later use. FIND will position to a single member, specified by name, which requires a directory lookup on disk, or by address previously retrieved by BLDL. The STOW macro is used to update the directory when a member is added, deleted, changed (including renamed), or replaced.[3]

Load modules

The operating system requires all executable programs to be stored in libraries because the member's directory entry contains additional attribute information specific to load modules. When used for storing load modules, directories also contain, among other data, the size of the load module and the address of the first "text record", which is different from the address of the first member data. Executable programs are written to libraries by the linkage editor and loaded into user-acquired storage by the Loader (an application program) or into system-acquired storage by Program Fetch (a specialized component of the OS supervisor).

The Linkage Editor organizes a load module in a specialized format consisting of alternating "text records" and "control/relocation dictionary records". This organization allows a load module to be completely loaded and relocated with one input/output operation by Program Fetch (EXCP on pre-MVS systems, or STARTIO on MVS/370 and later systems).

Similar facilities

The closest parallel to partitioned datasets in other operating systems such as Unix or Windows is the static library, such as produced by the ar utility. In fact, the nomenclature for libraries in make, lib(member), is directly derived from OS/360. A PDS may be compared to a directory, that can contain only files, no subdirectories, and at the same time is physically stored in a single file. The need for libraries relates to the fact that mainframe operating systems (until very recently) did not have a hierarchical file system.

References

  1. ^ IBM System/360 Operating System Sequential Access Methods Program Logic Manual (PDF). IBM. January 1967. Y28-6604-1.
  2. ^ IBM Corporation (June 1973). OS Data Management Macro Instructions (PDF). p. 157. Retrieved August 19, 2016.
  3. ^ IBM Corporation (July 1973). OS Data Management Services Guide (PDF). pp. 75โ€“85. Retrieved August 19, 2016.