IMHO ICEGENER does it right & IEBGENER does it wrong. Most sites have an alternative copy utility by way of the SORT utility and it should provide better performance than IEBGENER... so vote with your feet and avoid IEBGENER whenever you can.
Bill On Tue, 15 Jan 2008 03:12:48 -0600, Zaromil Tisler <[EMAIL PROTECTED]> wrote: >On Mon, 14 Jan 2008 21:17:15 -0600, Walt Farrell <...> wrote: > >---- snip ---- >>>If I have a VB (or even an FB) with a larger LRECL, it shouldn't take >>handstands to copy! >>> >> >>For VB, I agree. >> >>For FB, how would you like the output padded? Blanks? Binary zeros? >> >>One of those will be incorrect for some set of users, so you probably need >>an option. And IEBGENER provides the ability to specify that option when >>you change the LRECL and provide control statements to tell it what to do. >>As I understand it from this thread, it only complains and quits when you >>try to change the LRECL without providing those control statements. >---- snip ---- > >The argumentation above was apparently not used in ICEGENER design, >the ICEGENER (as a replacement for IEBGENER & SYSUT1 DD DUMMY >combination) takes another approach: > >Copying PS V shorter to PS V larger brings RC=0. >Copying PS F shorter to PS FB shorter brings RC=0 and padding with binary >zeros. > >Trying to copy in the other direction: > >Copying PS F larger to PS F shorter brings RC=0 and data truncation. >Copying PS V larger to PS V shorter brings RC=0 if all records fit in the output >dataset, otherwise I get U0217 and ICE217A: > >ICE217A 0 153 BYTE VARIABLE RECORD IS LONGER THAN 133 BYTE >MAXIMUM FOR SYSUT2 > >-- >Zaromil > ---------------------------------------------------------------------- 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
