This has made me wonder. One thing I like about UNIX (or Windows) files is that they don't impose any structure on the data. Of course, OTOH, this could be viewed as a negative. Anyway, I wonder if it would be nice to have a "subsystem", similar to GPSAM (file #290 on CBT), which could "bridge the gap". Assume you have a program with a DCB which says LRECL=127,RECFM=FB, but the data was given to you with LRECL=131,RECFM=VB (the equivalent, but variable). The first thing that comes to mind is DFSORT and its VTOF function to copy the VB file to an FB file (perhaps to a temp DSN), and process it. Not a good idea if the input data is about 200 million records, each of which is 20_000 bytes long. But wouldn't it be interesting to be able to do something like:
//INPUT DD DSN=vb.input,DISP=SHR,SUBSYS(VTOF,'LRECL=127,FILL=0X00') The above would use the VTOF subsystem to read the data. It would present 127 byte records to the application (and an I/O error if 127 is too small), filling out the end of the record with 0x00 (x'00') bytes. I used the 0X00 because trying for X'00' is more difficult. I guess the 0X prefix is unneeded and it could just be FILL=00. And, of course, you could use any hexadecimal byte value for the filler. Oh, yes, if the LRECL= is not specified, then the default will be the LRECL of the DSN, minus 4. There could also be a corresponding FTOV which similar options, perhaps specifying a TRUNC=??, which would truncate the any trailing ?? bytes in the input data. -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
