On Mon, 13 May 2019 10:35:47 -0500, John McKown wrote: >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. > +1 Will OS ever liberate users from interacting with low-level attributes of devices which nowadays exist only virtually.
The access methods do this for UNIX files, reformatting as needed and adding RDWs and even BDWs. > ... 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), > That error can be a rude astonishment. See the "Lousy error from HLASM" thread last month, where some users asserted that an error detected by the access method should be diagnosed by the utility. >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. > The access methods do this for UNIX files, reformatting as needed and adding RDWs and even BDWs. The FILL is unconditionally 0x40. I've seen no complaints about that. For 40 years I've wondered why OS access methods weren't simlarly user-friendly. >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. > Access methods don't truncate for UNIX files. And it would lead to a dispute over whether the supported minimum length should be 0, 1, 0r 9 bytes. I've seen each in various iterations of ISPF Edit. CMS has been smarter forever. It supplies the data and the count in separate fields in a control block. The problem program can be unaware of whether the underlying file is F or V -- the interface is the same. How would mixed-format copybooks work with nested COPYs in HLASM? On exiting the second-level COPY, the program simply issues a POINT to where it was. VTOF would need to switch formats back. Marrying FLOWASM to the I/O exits in HLASM would be impeded by mixed-format copybooks. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
