But the one who created the “cms blocked” fornat should terminate with x0000 to drop the padding. If you have padding on each card, you need to unravel differently.
Rob On Sat, 16 Jan 2021 at 18:13, Alain Benvéniste <[email protected]> wrote: > 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 >
