If you can't change it, I'd then perform a STRIP TRAILING only on the last
record when receiving the punched file.
Kris Buelens,
--- VM/VSE consultant, Belgium ---
-----------------------------------------------------------------------
Op za 16 jan. 2021 om 18:13 schreef Alain Benvéniste <[email protected]>:
> Yes. The fact is that i am in the situation where i don’t have the hand on
> the last record : it is a one by one punch record. Records are cumulated,
> then the close punch happens.
>
> Envoyé de mon iPhone
>
> > Le 16 janv. 2021 à 16:41, Glenn Knickerbocker <[email protected]> a
> écrit :
> >
> > On Sat, 16 Jan 2021 11:31:19 +0100, Alain Benvéniste wrote:
> >> Yes of course, and you put me on the way to test with a strip trailing
> >> and it works !
> >
> > As long as your original file doesn't happen to contain any blanks that
> > happen to fall on the last byte of a blocked record!
> >
> > I'm still mystified by the difference you see after sending the file over
> > RSCS. Is the last record short on the original system, and padded with
> > blanks when it's copied by RSCS? x4040 would be taken as the length of
> > the next file record, explaining why it can't find the end.
> >
> > The notes for BLOCK CMS include this instruction: "use pad to pad the
> > last block with zeros as it is in the file system." So this should give
> > you a valid file:
> >
> > "pipe strliteral /abc/ ! block 80 cms ! pad 80 00 ! punch"
> >
> > ¬R
>
