[Prycroft Six][Software][MVS S/w][Offload]

PDS Offload and Reload

Since OS/360, one of IBM's data set utility programs has been IEBUPDTE. ("IEB" is the "component prefix" for data set utilities.) IEBUPDTE control statements are indicated by a ./ (period-slash) in the first two bytes of an input record. IEBUPDTE is quite powerful in its way, but its function and applicability are limited. For example, IEBUPDTE can only process fixed-length records. The SYSIN file which can contain both control statements and data must have 80-byte records. The "master files" which can be updated by IEBUPDTE must not have a logical record length exceeding 80 bytes.

Other utilities, including some in the public domain, have evolved to perform IEBUPDTE-like functions but with fewer restrictions. The usefulness of extending the functionality to handle longer record lengths, and/or variable-length records is greatly enhanced by the creation of a counterpart utility which performs the reverse operation. Two famous utility pairs are UPDTE and UNUPDTE, and PDSLOAD and OFFLOAD, both being available from the CBT "tape" file 93.

UPDTE and PDSLOAD can both process an IEBUPDTE-like input file (well, the ./ ADD control statement, anyway) and reconstruct PDS members, while UNUPDTE and OFFLOAD can create a sequential IEBUPDTE-like input stream from a PDS.

Another extension performed by programs such as these is the preservation of "SPF stats". IBM's SPF and ISPF have created a convention followed by Fujistsu's PFD (pretty much) and Rob Prin's RPF where details of PDS members (such as creation and current record count, creation and last update timestamps, and the userid which last updated the member) are kept in the user data of the directory entry.

SPF statistics consume space, not in the member, but in the PDS directory. A PDS directory block can contain 21 directory entries for members with no user data, but can only contain 6 directory entries with SPF statistics.

User data is always an even number of bytes because its length is indicated as a number of halfwords anywhere from 0 (ie. no user data) to 31 (which is 62 bytes of user data). "SPF statistics" uses 15 halfwords of user data. PFD also used this format, but then reduced it to 14 halfwords thereby discarding 2 trailing blanks required by SPF and ISPF. This did not save enough space to fit an extra entry into a directory block, but it did mean that ISPF could not recognise newer stats from Fujitsu systems. REVIEW can recognise both SPF and PFD statistics.

(Back in the early 1980s, when something was equally applicable to IBM's SPF and Fujitsu's PFD, the software products were sometimes collectively referred to as "SPFD". For example, "The members can just be renamed in SPFD.")

IBM often ships PDS members with System Status Information (SSI) which is 4 bytes (or 2 halfwords) of user data. A single directory block can contain 15 entries with SSI user data.

SPF statistics can be preserved across an offload/reload cycle by formatting them into the comment area of a ./ ADD control statement. This means that a program like PDSLOAD can process the file and restore SPF stats, while IEBUPDTE can still be used if necessary to restore the PDS member data (but the SPF stats will not be restored).

When loading CBT tape libraries from an actual CBT tape often ISPF statistics can be preserved by employing the PDSLOAD program in the reload procedure instead of IEBUPDTE.

One point to note is that apart from the control statements, each logical record in the sequential file is a copy of a logical record to be added to or copied from a PDS member.

Because an undefined record format (RECFM=U) is not a convenient format for a transportable sequential file, not least because RECFM=U data sets cannot be edited by ISPF, a different approach from the record-for-record correspondance is required when offloading load module members.

One approach could be to delink the programs into a linkage editor (or program binder) input stream, complete with object "decks" and accompanying control statements. The record format would be fixed-length 80-bytes records which could easily be placed into a job stream for program reconstruction. However, at least for the linkage editor, some program attributes are specified in the program parameter of the link edit job step rather than in a control statement, so this immediately introduces some limitations.

(Unfortunately, my delinker of choice - David Noon's delinker written in PL/I, and available from CBT tape file 90 - will not run on MVS 3.8 because of the lack of a "modern" PL/I compiler, or because of the lack of a suitable run-time library if the load module is installed.)

The REVLMOD method also uses fixed-length 80-byte records, but has ./ control statements to control processing. This makes it easy to extract specific members from the sequential file with an editor, if required. Although ./ ADD is still used, the other control statements are not recognised by IEBUPDTE or other reload utilities, but contain data required for program reconstruction.

Load modules reconstructed by REVLMOD are bit for bit, byte for byte identical to the original load module. They are not reblocked or reordered as they might be from a delink/relink cycle. This means that REVLMOD will fail if a load module block is longer than the block size of the output library.

The maximum block size output by the pre-DFP linkage editor (such as is found on IBM's free OSs) is 18,432 (= 18 times 1,024) bytes.

As a result, all downloadable software from this site intended to run on MVS/370 can be installed on to a 3350 (or a 3380 or a 3390).

Not all software from this site can be installed on to a 3330 (regardless of model) because some block lengths may exceed 13,030 bytes.

REVLMOD does not contain logic to update overlay segment addresses upon reload, so REVLMOD cannot restore overlay programs.

[Back][Up][Next]