Basic partitioned access method
| Company type | Software component |
|---|---|
| Industry | Computer software |
| Products | Access method for partitioned datasets (PDS) |
In IBM mainframe operating system environments, the basic partitioned access method (BPAM) functions as an access method tailored for libraries, which IBM identifies as partitioned datasets (PDSes). BPAM finds application across systems such as OS/360, OS/VS2, MVS, z/OS, among others.
A PDS is composed of multiple members, which resemble sequential data sets, all cataloged within a directory. This directory contains member names—each up to 8 characters and right-padded with spaces—and their addresses relative to the dataset's start, facilitating disk relocation.
While partitioned datasets can accommodate any form of data, they are predominantly utilized for storing executable programs or load modules (binary files). Additionally, they serve as repositories for system assembler macro definitions, job control scripts, and source code files.
Application program interface
BPAM offers an application program interface (API) designed for direct interaction with libraries. This API closely mirrors that of the basic sequential access method (BSAM), augmented by capabilities for directory management. Members may also be accessed sequentially by indicating the member name within the job control DD statement.
To employ BPAM, programmers set DSORG=PO in the Data Control Block (DCB). As a basic access method, BPAM performs asynchronous block-level reading and writing of member data, necessitating the use of the CHECK macro to verify operation completion. The method utilizes standard macros including OPEN, CLOSE, READ, WRITE, and CHECK. The NOTE macro retrieves the position of the most recently processed block, while POINT repositions to that location. The BLDL macro generates a list of member addresses for subsequent operations. Using FIND, a member can be identified by name or by an address obtained from BLDL. The STOW macro is responsible for updating the directory when members are added, removed, modified, or replaced.
Load modules
Executable programs must reside within libraries because the directory entry for each member contains critical metadata specific to load modules. This metadata includes details such as the size of the load module and the address of its initial "text record," which differs from the address of the first member data. Executables are placed into libraries by the linkage editor and subsequently loaded into user memory by the Loader application or into system memory by Program Fetch, a component of the OS supervisor.
The Linkage Editor organizes load modules by alternating "text records" with "control/relocation dictionary records," enabling Program Fetch to perform loading and relocation in a single input/output operation. This is accomplished via (EXCP) on pre-MVS systems or (STARTIO) on MVS/370 and later platforms.