I wish to create "executables" by running iewl, doing an iebcopy unload, and then doing the equivalent of ftp with option rdw to create a simple flat/sequential file that is self-contained.
(rightly or wrongly, this is my design goal) And I want to use the MVS 3.8J version of the tools and then have upward compatibility from MVS 3.8J to z/OS. That much is already working for any testing I have done to date. I now wish to replace all of the 2-3 IBM tools nominally used in the above process with a third party tool. Specifically this one (pdld): https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdld/src/mainframe.c and noting that it is already working to an extent. However, page 333 of Appendix B of DFSMSdfp Utilities, SC26-7414-05 available here: https://publibz.boulder.ibm.com/epubs/pdf/dgt2u140.pdf says: 8 16 Structure Last 16 bytes of basic section of the Data Extent Block (DEB) for the original data set. 1 24 256 Structure First 16 extent descriptions from the original DEB. 1 1. These fields are highly device dependent and are required to translate absolute DASD addresses (MBBCCHHR) in the member data records to relative addresses (TTR). The DEB control block is documented in z/OS DFSMSdfp Advanced Services. DEVTAB information is documented inDFP System Data Administration. And that's the problem - device-dependent. I wish to use blocksize 6144 as a "universal blocksize for load modules" (I would like it to work on 3350 and 3390 at least, but ideally everything). So I would like to try to abstract this. I don't care if it is inefficient loading because I lose the 3390-optimized CCHHR values. But I do need it to work on 3390. I was wondering whether I could/should use "VIO" as an abstract device type to make coding more straightforward. It's also possible that I'm misunderstanding something. Any direction please? Note that the current code is C90-compliant and will run on either ASCII or EBCDIC environments to produce a (nominally) valid IEBCOPY unload on an EBCDIC environment. Also note that it currently takes in only object decks, but I am thinking of getting it to accept IEBCOPY unloaded object code PDSes and/or unloaded NCAL libraries with aliases for external references and/or S390 ELF object code and/or S/390 ELF libraries (EBCDIC versions using a custom binutils) and/or CMS libraries (so far I haven't been able to read CMS libraries as a simple sequential file though - it stops reading at the first member so I may have to do a TYPE (HEX and create something conceptually similar to an IEBCOPY unload). Thanks. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
