On Tue, Dec 16, 2014 at 8:44 AM, Paul Gilmartin < [email protected]> wrote:
> On Tue, 16 Dec 2014 07:58:56 -0600, John McKown wrote: > > > >Is a MAX_LRECL really needed? Is a z/OS VB record _ever_ greater than > >32767 bytes? Yes, I can see how somebody could write a program which > >creates a data set containing VBS segments which, combined, would exceed > >that limit. But using "normal" z/OS facilities, it would be difficult. And > >I'd bet that even the venerable DFSORT would cough up hair balls trying to > >process it. I need to read up on LRI, I guess. > > > I'll put on my Black Team suit. Things that aren't really needed to be > handled happen. > > IIRC, Rexx in z/OS 2.1 supports RECFM=VBS (and RECFM=U). I'll > have to try. > > > On Tue, 16 Dec 2014 07:13:32 -0600, John McKown wrote: > > > >> I believe that is even RECFM=VBS. Does FTP RDW > >> do something reasonable with the spanning? > >>> > >Each segment comes in separately, just as it is on the file. FTP does not > >reassemble a spanned record into a single record. So your code must > >reassemble the entire record from the segments. I have C code which does > > > Does STRU R preserve the spanning flags in the SDWs, needed to > reassemble the entire record? My summary of STRU R vs. STRU F with & without SITE RDW, from downloading some SMF data STRU F / SITE NORDW - junk - only the "data" portion, no way to determine where a record ends. STRU F / SITE RDW - usable. Each VBS segment read separately and correctly. The code on the PC must reassemble segmented records. STRU R / SITE NORDW - appears to be junk - Each VBS segment read as a separate "record", but no spanning information is available. STRU R / SITE RDW - appears to be junk. The STRU R appears to disable the SITE RDW because the files downloaded with STRU R files are identical regardless of SITE RDW or NORDW. So, for VBS files, the only useful download appears to be the STRU F / SITE RDW. Which stresses the OPs problem of having something which can be downloaded to a PC, then uploaded back to z/OS. FTP just doesn't appear to be able to do this for VBS files. Very interesting. And I was totally wrong in thinking that STRU R would work. > > >this. If you (or others) would like to look at it, it is available as a > >"gist" on GitHub via the URL: > > https://gist.github.com/JohnArchieMckown/8ae2fb6f457eaf8d6d7b > > > >Despite its being designed to run under z/OS, it will compile using gcc > on > >Linux. I don't do Windows programming. I don't contend that it is the > best > >code in the world. But it worked in my minor testing. > > > Big-endian Linux or little-endian Linux? (Doesn't matter if you avoid > type-punning.) Compile? *And* execute properly? > Either byte order. The FTP transfers the data "as is" from z/OS. Which means that the LLBB field is in big-endian (z) format, which is the same a "network order". The code uses the ntohs() function to convert this from z (network) order to host order. I've only done some very minor testing on Linux. And "it didn't blow up". <grin/> > > -- gil > > -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
