On Mon, 14 Jan 2008 17:28:28 -0500, Robert A. Rosenberg wrote: >At 15:31 -0600 on 01/14/2008, Chase, John wrote about Re: IEBGENER is BROKEN: > >> > -----Original Message----- >>> From: IBM Mainframe Discussion List On Behalf Of Anthony Fletcher >>> >>> If you use IEBGENER in straight copy mode, it does check and >>> enforce that the LRECLs match. >> >>All well and good -- for FIXED-length records. Irrelevant for >>VARIABLE-length records. > >It can be relevant if the new LRECL is less than the old one as >opposed to being larger. While increasing the LRECL will allow all >the records in the input file to copy to the output one, decreasing >the LRECL can run into problems if any of the input records are >larger than the smaller output LRECL (unless you switch from VB to >VBS). This "sanity check" when decreasing the LRECL is only a safety >check if the new LRECL is still equal to or larger than the actual >largest record in the input file (IOW: If the largest record is 100 >bytes long, you can safely reduce the LRECL to 100 and BLKSIZE to no >less than 104). >
Another oddity: We had an issue with a PDS where a PDS was reblocked. A subsequent batch JOB came along and reblocked it back to it's original smaller block size. I believe it was an IEBCOPY compress with DD DSN=??,DISP=OLD,DCB=BLKSIZE=8000 (or similar) on both input and output. The interesting part is any member added that had a line count that made its size larger than the latest BLKSIZE was corrupted. We got all the members back by IEBCOPYing them back out specifying the larger BLKSIZE. Maybe IEBGENER's approach of only allowing matching parameters is safest ??? Corruptions are very bad. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
