On 2014-09-08, at 08:27, John Gilmore wrote: > Werner Kuehnel wrote: > > <begin extract> > When I ftp this file binary with "quote site lrecl=582 recfm=fb" all > records are written contigously in chunks of 582 bytes. A second ftp > (within z/OS) then splits up the records at x'0D25', but additionally > at byte 582, which is wrong when a record flows over into the next > record. All attempts to get the right format failed up to now. > </end extract> > > This language is less than pellucid, but the words ". . . wrong when a > record flows over into the next record." do strongly suggest that a > RECFM value of VBS---Variable [length], Blocked, Spanned---be > specified instead of VB. Here VBS means in effect that a [logical] > record can span one or more [physical] blocks. > I doubt that RECFM=VBS is involved (does FTP even support VBS?) Rather, that in a BINARY transfer to a RECFM=FB data set FTP is oblivious to record boundaries and stores each 582 bytes of the data stream as one RECFM=FB record, treating the x'0D25' simply as ordinary data.
> Rube Goldberg schemes that resort to UNIX processing to cope with the > putative deficiencies of some IBM access method do sometimes 'work', > just as it is possible to travel from London to Paris via Okahoma > City; but they are ugly resource hogs. Worse, they perpetuate > ignorance of these AMs. > I don't recall that the OP imputed any deficiencies to IBM access methods (although I may have done so). "It is what it is." (Must I apologize for the cliche?) Merely incompatibilities. "Rube Goldberg" is appropriate. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
