The confusing issue was begun a very long time ago. If there is apparent input data with no specific DD statement to match it up with, there was a SYSIN dd statement generated above it. Until recently, that extraneous SYSIN dd statement had no effect on the JCL except to prevent either a JCL error or an "invalid jcl" error as this SYSIN was ignored since it was out of sequence (in most cases) with the specification of SYSIN (if there was one) in the procedure.
Now with OA12842, (and I have seen other similar changes) the JCL specified outside of the procedure (mostly for override purposes) does not have to be in the same sequence as the JCL in the procedure. The overriding JCL statements will now be matched up irregardless of the sequence. APAR OA12842 is fixing the problem where the input data is not moved along with the matching overriding JCL statement, especially in the case of multiple sets of input data. This is where the original poster encountered the problem. The internally generated SYSIN dd statement has now been matched up with the SYSIN dd statement in the procedure, and the input data following this generated statement was moved along with it. This is where the original poster encountered the problem. WAD/BAD? Depends on whether the end results are what makes you happy. To me you were doing something that was puzzling at the least. Now you are being forced to follow what was an assumed correct way of doing JCL coding. On Thu, 17 Jul 2008 13:44:52 -0600, Roger Bolan <[EMAIL PROTECTED]> wrote: >I'm confused. Are you saying that APAR OA12842 broke it? or that it fixed >it? It looks to me like they fixed a problem. >It says >The solution for this APAR has been shipped in the base code of >z/OS 1.8 (HBB7730), JES2 1.8 (HJE7730) and JES3 1.8 (HJS7730). > >If I understood the original poster, he has >//AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN >//UNVTEST PROC >//PS001 EXEC PGM=IEFBR14 >//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE >//SYSIN DD DISP=SHR,DSN=QALC.UNVLIB >//MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB >//SYSPRINT DD SYSOUT=* >// PEND --------------------- >//* >//JS001 EXEC PROC=UNVTEST >//MYSCRIPT DD * > WHATEVER >/* > WHEREEVER >/* > >and the WHEREEVER causes a system generated //SYSIN which overrides his >original >//SYSIN DD DISP=SHR,DSN=QALC.UNVLIB > >I also like to leave junk at the bottom of my JCL members as notes. But I >always have a // hard end of job card before the junk at the bottom so I >never see this problem. > >Roger Bolan >infoprint.com > >Boulder, Colorado, USA > > >P Think before you print > >IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 07/17/2008 >08:37:50 AM: > >> How on earth can IBM make a change as significant as this and not >> even document the change in behavior? I can imagine this affecting >> many job streams with negative consequences. >> >> >>> Mark Zelden <[EMAIL PROTECTED]> 7/17/2008 8:54 AM >>> >> APAR Identifier ...... OA12842 Last Changed ........ 08/06/10 >> PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES >> SWAPPED ( OA05951 ) >> >> Symptom ...... IN INCORROUT Status ........... CLOSED UR3 >> Severity ................... 2 Date Closed ......... 06/04/13 >> Component .......... 5752SC1B9 Duplicate of ........ >> Reported Release ......... 709 Fixed Release ............ 708 >> Component Name 5752 CNVRTR/INT Special Notice >> Current Target Date ..06/04/15 Flags >> SCP ................... >> Platform ............ >> >> Status Detail: APARCLOSURE - APAR is being closed. >> >> PE PTF List: >> >> PTF List: >> Release 708 : No PTF planned >> Release 709 : No PTF planned >> Release 720 : No PTF planned >> Release 730 : No PTF planned >> >> Parent APAR: >> Child APAR list: >> >> >> ERROR DESCRIPTION: >> When DD statements within a procedure are overridden with >> instream data (DD * or DD DATA), the data within the data sets >> represented by those input stream DD statements may be swapped >> (exchanged) if the overriding DDs are not in the correct order; >> that is, in the order in which the overridden stmts appear in >> the procedure. >> This can happen because the MVS Converter may reverse the >> sequence of two or more instream DD stmts with respect to each >> other, but the data within the files referenced by those DD >> stmts does not move along with the DD stmts themselves. >> Running the same JCL in R707, the out of sequence instream >> DD statements were simply ignored. >> >> This issue was previously reported in OA05951, which was >> closed SUG. >> >> Additional Symptoms: >> IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT >> SPECIFIED (msgIEF655I) >> May occur if a SYSIN DD * statement is GENERATED and now >> properly finds and overrides a SYSIN DD DSN= statement. >> >> Additional Keywords: >> SYSIN reversed reversal, asterisk, instream >> >> >> >> >> -- >> Mark Zelden >> Sr. Software and Systems Architect - z/OS Team Lead >> Zurich North America / Farmers Insurance Group - ZFUS G-ITO >> mailto:[EMAIL PROTECTED] >> z/OS Systems Programming expert at >http://expertanswercenter.techtarget.com/ >> Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html >> ---------------------------------------------------------------------- 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
