I am having difficulty understanding your end point. You want to ship a load module by using IEBCOPY UNLOAD and then transmit the flat file to a remote system where I presume you would like to reload and execute.
Not a clue as to why you need DEB access or what issue is causing you difficulty. Or why you are shipping UNLOAD rather than XMIT or TERSE format which are - FIXED - and pretty well defined and have open tools. On Sat, 15 Jun 2024 06:34:45 -0500 Paul Edwards <[email protected]> wrote: :>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 -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
