Farley, Peter x23353
2018-07-02 20:49:54 UTC
The documentation for the z/OS V2.2 Binder API in the manual "z/OS MVS Program Management: Advanced Facilities" in "Appendix D. Binder API buffer formats", page 279 (PDF page count 297) has a footnote #3 for field ESD_ELEM_OFFSET which says:
3. Calculated on the ED and ER records, required input to LD.
That note says to me that if I INCLUDE an existing program (object or load module) into a Binder work space using the Binder API's, then for ED entries in the ESD obtained for that program using FUNC=GETD for TYPE=ESD I should see the element offset for the class of that section.
As it turns out, the Binder API FUNC=GETD for TYPE=ESD always returns a binary zero in that field. No matter what VERSION level of the API macros is used (I have tried all version numbers from 4 up to 7) the field ESD_ELEM_OFFSET is always a zero. This holds true for both program objects loaded form a PDSE and load modules loaded from a PDS.
For load modules loaded from a PDS, the "class" offset is actually zero (B_TEXT is the only class of a load module) so the zero value for a load module loaded form a PDS is actually accurate. However, for a complex program object (COBOL V5+ or C/C++, etc.) it is not accurate.
The other offset field in the ED entry (field ESD_CLASS_OFFSET) accurately contains the offset from the start of the containing Binder class section, but nowhere does the ED entry contain the offset of the CLASS from the start of the loaded program. It was my impression (perhaps wrongly) that the Binder API should tell me that offset in each ED entry for an ESD section.
To get to the actual start of a particular section of code in a loaded program it seems that you also have to use FUNC=GETN for NTYPE=CLASS to get all of the CLASS names and their respective offsets (field name BNL_SEGM_OFF) and add that value to the ESD_CLASS_OFFSET to find the code in storage. Which means you have to search the CLASS names table for each ED section name using the name at ESD_RES_CLASS_PTR to find the containing class name and then extract the offset from that CLASS entry.
Is this expected behavior of the Binder API, or is this a possible error/failure in the API? Should that class offset value from BNL_SEGM_OFF in the CLASS entry also be stored into the ESD_ELEM_OFFSET field automatically by the Binder API when a module is INCLUDEd into a workspace, or not?
If I am just misreading the API documentation, I would appreciate any enlightenment you can provide.
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN