Paul, I agree with Binyamin - XMIT format (aka NETDATA format, also transportable to VM systems) is fixed-length, no RDW's needed, and handles executables as well as plain text or object data. And there are public domain tools available at the MVS 3.8 level to create into and extract from that format. Much easier to process than IEBCOPY unload format.
If your "pdld" tool can just create the executable format into a one-member, BLKSIZE=6144 PDS on any kind of DASD that supports that block size (i.e., just replace the IEWL part), then the XMIT tool can put that PDS into a transportable format which can be unloaded into a PDS (or even a PDSE) all the way up to current z/OS versions on any supported DASD, regardless of the DASD type it originated from. Peter From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Binyamin Dissen Sent: Saturday, June 15, 2024 6:24 PM To: [email protected] Subject: Re: iewl/iebcopy device options 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://urldefense.com/v3/__https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdld/src/mainframe.c__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N68K3BMSTV9FuRdN2KfapjEZQom6ZmPelGEaLma7GIlox6tNHmLUmwn5HioeZQYHsI8-wBlhtbwPNOZw0zONPRVHy_3i4OZLm5KMV_iW$<https://urldefense.com/v3/__https:/sourceforge.net/p/pdos/gitcode/ci/master/tree/pdld/src/mainframe.c__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N68K3BMSTV9FuRdN2KfapjEZQom6ZmPelGEaLma7GIlox6tNHmLUmwn5HioeZQYHsI8-wBlhtbwPNOZw0zONPRVHy_3i4OZLm5KMV_iW$> :> :>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://urldefense.com/v3/__https://publibz.boulder.ibm.com/epubs/pdf/dgt2u140.pdf__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N68K3BMSTV9FuRdN2KfapjEZQom6ZmPelGEaLma7GIlox6tNHmLUmwn5HioeZQYHsI8-wBlhtbwPNOZw0zONPRVHy_3i4OZLmzDiNtZ2$<https://urldefense.com/v3/__https:/publibz.boulder.ibm.com/epubs/pdf/dgt2u140.pdf__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!N68K3BMSTV9FuRdN2KfapjEZQom6ZmPelGEaLma7GIlox6tNHmLUmwn5HioeZQYHsI8-wBlhtbwPNOZw0zONPRVHy_3i4OZLmzDiNtZ2$> :> :>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. -- 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 [email protected] with the message: INFO IBM-MAIN
