Thanks all for your replies. > I agree with Binyamin - XMIT format (aka NETDATA format, also transportable > to VM systems) is fixed-length,
Being fixed length isn't a selling point to me. zip files aren't fixed length either. It's actually a non-selling point. You can consider that I have a rival format for XMIT (rightly or wrongly, and I acknowledge in advance that most people will probably say "wrongly"). > no RDW's needed, XMIT will indeed have RDWs embedded in the (more complicated in my opinion) format. XMIT/TERSE just go on top of IEBCOPY and will include the RDWs and possibly the BDWs from the IEBCOPY unload RECFM=V(S) dataset. It is the RDWs that I add (or ftp adds) that I consider to be simple. > and handles executables as well as plain text or object data. I use zip for those other things. > And there are public domain tools available at the MVS 3.8 level > to create into and extract from that format. They also exist (for decades) to handle the format that I outlined. What's new is just pdld. > Much easier to process than IEBCOPY unload format. I don't consider it to be easier, but that's one of the "eyes of the beholder" thing. I'm curious as to why you think IEBCOPY unload format is difficult to process. That's the exact problem IMO. And the other things are layered on top of IEBCOPY unload anyway. > If your "pdld" tool The tool is a linker btw. "ld" is from Unix. > 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), Well that's basically my question - "any kind of DASD". I had an idea that maybe I should use a 2314 so that there is only one block per track. Someone told me elsewhere that I can't use VIO regardless - you can't have a VIO PDS - I haven't confirmed that with a test yet. > current z/OS versions on any supported DASD, regardless of the > DASD type it originated from. Yes, that's what I'm after. It's just a question of what my options are. E.g. it is possible that I can't make the original DASD 3390 if I want to restore to an unmodified MVS 3.8J that only supports 3350. But I may be willing to mandate a modified MVS 3.8J that has 3390 support added. That's my question, basically. What options do I have within the parameters specified to achieve my goal (not someone else's goal)? With regards to the other question about DEB - it's not me who wants a DEB - it's the IEBCOPY format that requires it to be there. Well - puts it there, anyway - I don't know if it is actually used in the load process such that I can put junk values there. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
