Zaromil Tisler wrote on 01/15/2008 01:12:48 AM: > 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 Yes, that's the way DFSORT's ICEGENER works when it uses DFSORT copy and the shipped installation defaults of GNPAD=RC0, GNTRUNC=RC0 and VLLONG=NO. However, you can modify ICEGENER's behavior with different values for those options. GNPAD=IEB and GNTRUNC=IEB will force DFSORT to use IEBGENER when the LRECLs are different; IEBGENER will give RC=12 for all of those situations. GNPAD=RC4 and GNTRUNC=RC4 will use DFSORT copy, but will give RC=4 for all of those situations except the last one (VB records longer than LRECL). Note that for the last situation you can use DFSORT's VLLONG=YES option to tell DFSORT to truncate the long records to the LRECL length. >as a replacement for IEBGENER & SYSUT1 DD DUMMY combination That's SYSIN DD DUMMY, not SYSUT1 DD DUMMY. Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED] Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ ---------------------------------------------------------------------- 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
