On Wed, 21 Aug 2013 19:39:31 -0500, Barry Merrill 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.
>
Checksum is your friend. Here's how to generate one using standard z/OS
utilities:
user@MVS:130$ cp "//'sys1.maclib(splevel)'" /dev/fd/1 | cksum
317904754 29808
"cksum" is a POSIX utility, so the checksum can be verified on any
other UNIXy system; perhaps even on Windows with Cygwin,
available at a very attractive price.
>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.
>
I am dismayed to find among IBM VM download instructions at:
http://www.vm.ibm.com/download/
the suggestion:
PIPE < fn VMARC A | fblock 80 00 | > fn VMARC A F 80
where the "00" means "pad any short record with nulls". I
have repeatedly railed against this: the null padding is less
likely to repair a transmission error than to conceal it, to be
encountered later in the proces, at greater expense.
I'm routinely outvoted with the specious argument that in
those cases where the truncated characters were nulls or
irrelevant the process will (seem to) work and the programer
is spared the effort of diagnosing and repairing the process
flaw and re-transmitting. I'm unsympathetic.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
