On Tue, 9 Oct 2012 15:07:37 -0400, Gerhard Postpischil wrote: >On 10/7/2012 6:14 PM, Paul Gilmartin wrote: >> Does BFTEK=A apply to output, or only to input? > >Input only; otherwise life would be too easy <g> > I suppose that when doing a gather-write, FORTRAN (which seems to be a primary motivator for VBS) knows where the segments are coming from and can build SDWs; no such rationale applies to a scatter-read.
>> If an empty segment is allowed as an interior segment, a programmer >> could inflate a logical record with an arbitrary number of empty >> segments. Ugh! > >I ran some more test, and the results were interesting: > >1) PUT VBS with 00040100, 00040300, and 00040200 produced three >records of 00040000 - flags got turned off. GET with and without >the logical record interface sees three null records. > >I zapped the data set to restore the segment bits I really wanted: > >2) GET VBS sees three records. > >3) GET VBS with BFTEK=A sees none of them. > >I'd much rather see 002 abends for 1) and 3) > Yup. And data errors on the PUTs that created them. >So a minimal documentation change should read that a short SDW, >with QSAM, will give funny results, and should not be used. > I think that's pretty much subsumed by the statement that the minimum count allowed is 5. But it's a pity they didn't do it reasonably so that a VBS data stream would be a compatible superset of a VB data stream. Thanks for doing the research. And I went back and did my own for FILEDATA=RECORD,RECFM=VB. Using Rexx/EXECIO (which I suspect uses QSAM), empty record(s) were handled fine (on a sample of 1). So the doc is unrealistically constraining. Now, Conway's law intrudes. FTP supports a "SITE RDW" command that allows RDWs to be treated as data and retained in a binary stream. This is also (almost) identical to the convention that SMP/E uses to represent unloaded relative files in a GIMZIP archive (except GIMZIP necessarily retains the BDWs also). Why couldn't the UNIX (USS) filesystem facility be made compatible with FTP? (And FTP compatible with GIMZIP?) Of course, the FTP SITE RDW convention is broken. If I transmit my stream file back to a z/OS RECFM=VB data set with the same QUOTE SITE RDW option, FTP mindlessly (understatement) obeys its own specification; treats the RDWs in the _incoming_ stream as data, and creates a VB data set with _double_ RDWs. There seems to be no way to reverse the conversion. What were the developers thinking!? (Clearly, they weren't.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
