Migration to version 2 buffers

Support for multiple text classes and a logical module structure in which sections are subdivided into classes requires some fundamental changes in the ESD. (See Understanding binder programming concepts for a better understanding of module structure and content). At the highest level in the ESD hierarchy is the Section Definition (SD entry), which assigns some attributes to the section. At the next level is the Element Definition (ED entry), one for each class requested in the section. ED records are new and need not be present for binder-defined, nontext classes, such as ESD and IDR. Elements can contain either labels (LD entries) or parts (PR entries), depending upon the binding method for the class. Beginning with PM2, LD entries are required for all entry points: An SD entry is no longer an implied entry into offset zero of that section.

Two PM1 data classes have been extended in PM2 in order to properly reflect the multipart program object. Class B_ESD has been extensively modified, with some data moving from the SD record to lower level records, such as the ED and LD. In addition, new data fields have been added to support future expansion. Class B_RLD has also been modified for multipart modules, although not as extensively as the ESD. These changes must be considered when converting your program from version 1 buffers and API calls to version 2.

If your program was designed for version 1 buffers, you may not need to migrate to version 2 (or a later version) if you are processing data only from traditional (load module compatible) modules. However if a PM2 (or later level) program object exploits new function, it might contain data that cannot be converted to version 1 buffer format. In this case, you will receive an error message. In addition, the binder fast data API supports only PM1 format program objects with version 1 buffers.

If you want to convert your program to use the version 2 buffer formats and API calls, you must consider the following:
  1. The SD ESD records no longer contain the length and offset of a section (since the section may now have more than one piece of text, in different text classes). The lengths and offsets are now in the ED ESD records.
  2. The number of ESD record types has been reduced to six by combining all section-related records (for example, PC, CM, DS, ST, ET) into a single SD record type. The type qualifier can be used to distinguish between the various types of SD entries.
  3. The ED record is new and is required for all text and compiler-defined classes, including ADATA.
  4. An LD record is required for each entry point into the section. External references are not bound to SD entries in PM2.
  5. PR and PD formats are identical. PRs, which represent a reference to a part or pseudoregister in a merge class, are created by the language translator and remain with the referencing section in the module. PD entries are always created during binding and are stored in a special summary section. The generated PD entries are the true definers of these parts, and contain the correct class offset, length and alignment.
  6. Offsets relative to the start of the module or section in version 1 buffers have been replaced by class and element offsets, respectively, in Version 2.
  7. Extended attributes information can be identified in certain ESD and RLD record types. Those data items are stored in the program object, but not processed in any way by the binder.
  8. Name space has been added to both ESD and RLD records, since program symbols can be defined and referenced in multiple name spaces.
  9. A new RLD type is defined for address constants that are to be set to the virtual address of a class.
The following tables show the correspondence between data elements in the two versions of the ESD and RLD buffers. Format codes shown have the following meaning:
Bnn
Bit string, width in bits
Cnn
Character data, width in bytes
Fnn
Fixed point (integer) data, width in bits.
N06
Name, consisting of halfword name length followed by pointer to string. The IEWBUFF macro generates separate DS entries for the name length and pointer.
PTR
4-byte pointer

New data elements are normally set to zero when processing a PM1 module. This is not true if the new value is determined from other data present in the record.