How could it? GENER did the truncation, AMATERSE was not involved, so the last bytes are whatever the last bytes were. The file just ended with one track filled and B37 for the GENER. But I did look and there are no 00 bytes in the last 20 or so bytes of the last 1024 byte record that had been created by AMATERSE.
Then AMATERSE just decompressed the bytes that were there in that one track. Barry -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Wednesday, August 21, 2013 7:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TRSMAIN On 21 August 2013 20:39, Barry Merrill <ba...@mxg.com> wrote: > It's an easy JCL exercise to conduct an experiment to confirm what happens: > > TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was > truncated. > > I copied a 105472 byte valid tersed file into a > DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). > The original untersed to 360,480 bytes, while the truncated file > untersed to only 48152, and there was no message nor warning that the input > file was short. Can you look at the last record in the truncated tersed dataset and see if it's zero-padded? Strictly one should look for a 12-bit zero, but a run of three of the 8-bit kind we're more used to would more than do the trick. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
