On Sun, 16 Jun 2024 08:34:14 -0500, Paul Gilmartin <[email protected]> wrote:
>>> I agree with Binyamin - XMIT format (aka NETDATA format, also transportable >>> to VM systems) is fixed-length, >> >What's important is not fixed-length, but that the data may >be regarded as a featureless binary stream. Yes. Or at least - that should be the case. But it seems that some people have difficulty getting a RECFM=U file (that does - or can) represent such a stream - transported intact. And I would (and do) address that problem right there, not try to work around with FB80. Although admittedly I don't have a good solution for RECFM=U for CMS other than tape. But that's why I normally don't use CMS - I use MVS. >>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"). >> >What's important is that utilities in the base system, not >additional FOSS, support the data format. At 3.8: I certainly agree with the sentiment. However, IBM noticed the lack of ability to capture a RECFM=V dataset intact and created the RDW option on ftp. But there is no similar tool without needing to FTP, nor was there even FTP on MVS 3.8, and nor is FTP even bidirectional. I submitted this to change that but it has been dormant for years: https://ideas.ibm.com/ideas/ZOS-I-247 So yes - I have some FOSS (copyfile in pdpclib) that does the equivalent of binary ftp rdw in both directions. And I consider that providing that in assembler format to be a fundamental requirement on any system I interact with (which is basically no-one). So again - I understand the goal of others, and I'm not saying they are wrong to use XMIT - I'm just saying that I have a different goal. I can explain my reasons but I'm guessing most people will disagree with them - and that's fine. >o NETDATA? > -Load modules As far as I know, XMIT isn't available on MVS 3.8J either, except as a FOSS add-on. Or perhaps it wasn't standard. >>It is the RDWs that I add (or ftp adds) that I consider to be simple. >> >Use FTP BINARY. Otherwise x'0D0A' appearing by hapenstance >in binary data will generate spurious RDWs. Sure. https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/folks.c /* Here is an example of transferring a VB file with "Hello there" "Folks" in it to the PC, preserving the RDW (Record Descriptor Word) */ /* binary EZA1701I >>>TYPE i 200 Type is Image (Binary) EZA1460I Command: locsite rdw EZA1460I Command: put folks EZA1701I >>>SITE VARrecfm Lrecl=256 Recfm=VB BLKSIZE=27998 500 Syntax error, Command not recognized. >>> PC ignores SITE command. Use sendsite to suppress <<< EZA1701I >>>STOR folks 150 Ready to receive "/C/folks". Mode STREAM Type BINARY. 226 Transfer finished successfully. Closing data connection. EZA1617I 24 bytes transferred in 0.076 seconds. Transfer rate 0.32 Kbytes/sec. EZA1460I Command: quit */ /* Here is an EBCDIC hexdump of the transferred file on arrival at the PC */ /* 000000 000F0000 C8859393 9640A388 85998500 ....Hello there. 000010 090000C6 969392A2 ...Folks */ Note that a couple of things have happened elsewhere: 1. I was told that VIO doesn't allow me to bypass geometry - I simply get the geometry of the page disks. 2. I was provided analysis that showed the difference in the two files I posted before was a UCB address - which sounds like something that should be zeroed in a "generic transport format" - unless zero values cause an issue somewhere. I still don't have a handle on the situation regardless and need an algorithm for creating a valid IEBCOPY unload, so the investigation continues. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
