Using an Internet search of the APARs provided I found This problem was introduced by the following ptfs. UA62377, uA62378 and UA62379
CHANGE THE CODE THAT DETERMINES IF THE EDITED INPUT RECORD WILL FIT INTO THE OUTPUT BLOCK. IT IS POSSIBLE THAT THIS MAY RESULT IN RECORDS THAT WOULD HAVE BEEN COPIED CORRECTLY BEING REJECTED WITH THIS APAR APPLIED. THIS APAR ALSO MADE CHANGES TO ENSURE THAT MESSAGE IEB309I AND NON-ZERO RETURN CODE WILL BE GENERATED Does that answer your question? Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf > Of Clark Morris > Sent: Wednesday, October 24, 2012 6:43 AM > To: [email protected] > Subject: Re: Propably I'm crazy not the IEBGENER > > On 23 Oct 2012 23:02:59 -0700, in bit.listserv.ibm-main you wrote: > > > Hi > > > >OA39769 and UA65724 PTF fixed the problem . > >In this exceptional case ,the IEBGENER was crazy. > > > >On 23.10.2012 21:42, Jim Mulder wrote: > >>>>> We got the SYSMDUMPs from customers often via SPOOL, so we had a > >>>>> job > >> to > >>>>> cut out the first character. > >>>>> The job has worked for several year, now I got a dataset full with > >> x'00' > >>>>> //STEP1 EXEC PGM=IEBGENER > >>>>> //SYSPRINT DD SYSOUT=A > >>>>> //SYSUT1 DD DISP=SHR,DSN=ESA.HP.SYSMDUMP > >>>>> //SYSUT2 DD DSNAME=ESA.QFSS.SYSMDUMP,DISP=SHR > >>>>> //SYSIN DD * > >>>>> GENERATE MAXFLDS=1 > >>>>> RECORD FIELD=(4160,2,,1) > >>>>> > >>>>> The input has LRECL=4161 output 4160, > >> OA38949 IEBGENER ADDS LINE OF NULLS IN OUTPUT DATASET > >> > >> OA39769 AFTER APPLYING PTF FOR APAR OA37216 IEBGENER > >> INSERTING NULL LINEWHEN USING VBS dataset > >> > >> Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > >> > Just out of curiosity, what was the upgrade to IEBGENER that caused this? > > Clark Morris > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
