On Fri, 8 Jun 2007 07:59:40 -0500, McKown, John wrote: > >The method is documented and is simple. The downloaded file is >especially encoded as it is downloaded. With a very simple encoding >method. Each data byte in the range 0x00-0xFE comes down unchanged. A >0xFF data byte is encoded as two bytes: 0xFFFF. A logical end of record >is encoded as 0xFF01. End of file is encoded as 0xFF02. 0xFF03 is >end-of-record combined with end-of-file. That's it. It works regardless >of anybody else's opinion. It is not often implemented in ASCII based >systems such as Windows or Linux or UNIX because they don't have RECORD >oriented architectures. But it does work for the z/OS ftp server. I >never said anywhere that it worked for any other server. > This doesn't seem to come from RFC 959. I'll look in IBM docuentation.
Now, I'm confused. How are block boundaries represented? I agree with Shmuel that these are essential for IEBCOPY unloaded data sets. I did the "od -x" on the intermediate file. The format seems to use 0x15 as an end-of-record. I thought this should break with data containing intrinsic 0x15 characters. I made such a test case. In fact, it breaks badly. I get variously SD37 abends, apparent loops (I cancelled after 2 minutes CPU), and reported TTR errors, nondeterministically, variously on the same input data. (It seems that IEBCOPY's input validity checking isn't what it should be.) I'll send you my test JCL privately. I had greater success with MODE B. This appears to prefix a 3-byte idiosyncratic BDW and restore the data better. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
