>> That is not even close to the RDW format that IBM >> provides. I have based PDPCLIB around IBM's RDW >> format. > And you're not flexible about this?
That's correct. When I open a VB file in binary mode, there's only one single choice for the data stream to be in, so I had to pick one single option. > And you designed your implementation > without doing a PoC? I did do a proof of concept. Someone told me that there was an RDW option on ftp and I asked for a sample PC file, and I wrote folks.c (posted in original message) to process it, and I was totally happy with this format that IBM had provided. It is perfectly logical and clean. Of course there are lots of other things that could have been done, e.g. a 2-byte length field instead of a 4-byte RDW. But IBM's decision to base it on what is actually on the mainframe instead of e.g. a little-endian 2-byte length, is perfectly OK with me. >> That STRU R format also doesn't allow data with x'ff' >> in it. Note that it appears I was wrong about that. If data has x'ff' in it, then it apparently appears as two x'ff'. Regardless, this is a complicated and non-natural data format. I may as well be reading and parsing a TRANSMIT file. >> The RDW format does. > That sucks. How about, then, my earlier suggestion of: > BINARY > QUOTE SITE TYPE E > QUOTE SITE MODE B That produces this: 000000 80000BC8 85939396 40A38885 99854000 ...Hello there . 000010 05C69693 92A2 .Folks Yes, it is possible to parse that and process on the PC, but once again I don't think it is as clean as ftp rdw. The fact that IBM has only made rdw one-way is not a reason for me to abandon this excellent file format. It merely makes me write a non-standard utility to reverse it. And ask in IBMMAIN for someone to ask IBM for an improvement. :-) >> But I would like to be able to distribute a V file the >> same way I can distribute an F file or a U file, ie >> just as a simple file, no wrapper (like XMIT/TERSE). > In a sense, FTP RDW is a wrapper. But I grant that it is unwrapped > by the FTP command itself, with no need to run a separate unwrapping > command on the Z. I don't consider RDW bytes to be a "wrapper". That is the exact format of the data in a VB file. It is true that VB files also have a BDW which is stripped (stripped, not wrapped), but that is fine. I do not expect my C program to be exposed to the concept of "BDW". For starters, I consider BDW to be a design fault. If FB and U data has no BDW, and simply an innate block length, I see no reason for VB to need a BDW. In addition, I consider that blocksize is something arbitrary and that all files should be able to be reblocked at will to suit the device characteristics. On the PC there are no block sizes, so I expect that when I transfer a file from mainframe to PC and back again, that the file will potentially have been reblocked. I am perfectly happy with this. And this also applies to the IBM ftp rdw format. >>> It produces a V-format file that can be >>> processed by a C program. >> As an example, I want to be able to transmit an >> SMF file (which I believe contains binary data) to >> the PC, and then have a PC program to process >> the SMF file. The PC program must handle the >> RDW itself, but that's all. > I believe that is even RECFM=VBS. Does FTP RDW > do something reasonable with the spanning? From what other people have posted, it doesn't, so I would like IBM to change that too. In the meantime I will run a utility on the mainframe to convert VBS to VB. Again, I don't think a C program should be exposed to the complications of VBS. It should just have to deal with V. PDPCLIB has logic in it to convert a VBS into a V (and vice-versa), but I'm not sure if it works or not. If it doesn't work, that's fine, it can be fixed. >> IBM's ftp rdw is an excellent file format. >> Note that the PC program that handles the SMF >> records can also be uploaded to the mainframe >> and it continues to work, at least if you are using >> PDPCLIB as your C library. > And it handles the spanned records reasonably? I was told that it does, but I had never tested it myself. I tried it out today and it didn't give me what I was expecting, but I'm not sure if I'm doing something wrong, so I have asked Gerhard for advice. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
