One pipeline that writes two times to a given file is asking for trouble. At least, that was always my experience.
2010/5/15 Paul Gilmartin <[email protected]> > On May 15, 2010, at 01:06, Glenn Knickerbocker wrote: > > > On Fri, 14 May 2010 16:54:42 -0600, gil wrote: > >> That gives no report of a corrupted file; it quietly pretends it's OK. > > > > You could hook something up to the alternate output of LOCATE to report > > the extra short record. > > > Too complicated; I don't want anything the client can't enter on one > terminal line (or that I can't understand). I'm pretty much settled > on the instructions: > > PIPE < fn PLCDP I | FBLOCK 1024 | > fn PLCD I FIXED 1024 > > A message such as: > > FPLDSK134E Record is ??? bytes, but format F file record length is 1024 > > ... indicates that the file was not uploaded properly. > > COPYFILE fn PLCD I ( UNPACK > > Which give considerable error detection with a reasonable amount of > typing. Additionally, COPYFILE ( UNPACK reports an error if the file > is not in packed format; PIPE UNPACK does not. I value error detection. > > I toyed with the idea of: > > PIPE < fn PLCDP I | FBLOCK 1024 | > fn PLCD I FIXED 1024 | UNPACK | > fn > PLCD I > > ... letting the final implied rename clean up the FIXED 1024 file which > is created only for error checking. But: > > o Is there any guarantee of the order in which the renames occur? > > Thanks, > gil > -- Kris Buelens, IBM Belgium, VM customer support
