Re: Friday Puzzler
AFAIK For a temp dataset, 'DISP=OLD' has always meant 'DISP=(OLD,DELETE)' ... going back to the 80's. If the dset is to be referenced again after the initial 'DISP=(NEW,PASS)', it should then specify 'DISP=(OLD,PASS)' in all subsequent steps that reference it - apart from the last. But IBM might have changed all that. g Mike Schwab wrote: Step2: DISP=(OLD,PASS) to pass to next step. DISP=OLD means DISP=(OLD,PASS) because of the previous DISP=(NEW,PASS) implies delete when done. On Mon, May 26, 2014 at 8:29 PM, Ravi Gaur gaur.ravi2...@gmail.com wrote: There's been no. of posting on it ..so i best tried to go through most of them ..and I thought to explain very basic of JCL AFIK. Step1 : showing DISP=(NEW,PASS,DELETE) So basically the dataset is being created,passed to be processed in subsequent steps ...HOWEVER not being catalog so after processing MVS is suppose to delete it... Step2 : DISP=OLD ...Just telling program to have EXCLUSIVE hold on the dataset while processing so again as per the step1 dataset is suppose to be deleted... This is so simple as it is ... Now coming to STEP3:- where it show jcl error is obvious as -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
W dniu 2014-05-27 14:32, CM Poncelet pisze: AFAIK For a temp dataset, 'DISP=OLD' has always meant 'DISP=(OLD,DELETE)' ... going back to the 80's. If the dset is to be referenced again after the initial 'DISP=(NEW,PASS)', it should then specify 'DISP=(OLD,PASS)' in all subsequent steps that reference it - apart from the last. But IBM might have changed all that. g DISP=OLD have same meaning for temp and permanent datasets. It's OLD,KEEP,KEEP or CATLG in SMS realm. The difference between temp and perm dataset is the temporary dataset will be deleted at the end of the job, despite on DISP coded. However of multi-step job DISP=OLD will not delete dataset when used in non-last step. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
Yes, SMS, is involved here. I think I've learned quite a lot from this discussion and my recommendation to the user is to either catalog the dataset or since their JCL ultimately deletes the dataset, change it to a temporary name, e.g. F00DMY, either of which resolves the failure. Thanks again for the discussion. -- Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.gov It is impossible to make anything foolproof, because fools are so ingenious. ~ Robert Heinlein -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, May 25, 2014 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Puzzler In bf7d786e5c64b2469bf97db41c499fac2625b...@doaisd5231.state.mt.ads, on 05/23/2014 at 04:02 PM, Grinsell, Don dgrins...@mt.gov said: I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. Is FOO.DUMMY SMS managed? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
There's been no. of posting on it ..so i best tried to go through most of them ..and I thought to explain very basic of JCL AFIK. Step1 : showing DISP=(NEW,PASS,DELETE) So basically the dataset is being created,passed to be processed in subsequent steps ...HOWEVER not being catalog so after processing MVS is suppose to delete it... Step2 : DISP=OLD ...Just telling program to have EXCLUSIVE hold on the dataset while processing so again as per the step1 dataset is suppose to be deleted... This is so simple as it is ... Now coming to STEP3:- where it show jcl error is obvious as -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
Step2: DISP=(OLD,PASS) to pass to next step. DISP=OLD means DISP=(OLD,PASS) because of the previous DISP=(NEW,PASS) implies delete when done. On Mon, May 26, 2014 at 8:29 PM, Ravi Gaur gaur.ravi2...@gmail.com wrote: There's been no. of posting on it ..so i best tried to go through most of them ..and I thought to explain very basic of JCL AFIK. Step1 : showing DISP=(NEW,PASS,DELETE) So basically the dataset is being created,passed to be processed in subsequent steps ...HOWEVER not being catalog so after processing MVS is suppose to delete it... Step2 : DISP=OLD ...Just telling program to have EXCLUSIVE hold on the dataset while processing so again as per the step1 dataset is suppose to be deleted... This is so simple as it is ... Now coming to STEP3:- where it show jcl error is obvious as -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
In bf7d786e5c64b2469bf97db41c499fac2625b...@doaisd5231.state.mt.ads, on 05/23/2014 at 04:02 PM, Grinsell, Don dgrins...@mt.gov said: I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. Is FOO.DUMMY SMS managed? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Friday Puzzler
I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.govmailto:dgrins...@mt.gov The difference between a conviction and a prejudice is that you can explain a conviction without getting angry. ~ anonymous -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
On 5/23/2014 10:02 AM, Grinsell, Don wrote: I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? Is it because you have no ddname on the F00.DUMMY DD statement? -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
I suppose because it isn't passed to STEP3 and isn't cataloged so it can't be found in Step3. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
DISP=OLD in STEP2 defaults to KEEP, so dataset is no longer in PASS catalog. Date: Fri, 23 May 2014 16:02:08 + From: dgrins...@mt.gov Subject: Friday Puzzler To: IBM-MAIN@LISTSERV.UA.EDU I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.govmailto:dgrins...@mt.gov The difference between a conviction and a prejudice is that you can explain a conviction without getting angry. ~ anonymous -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
My guess is, if the dataset isn't cataloged, then you must specify a volser and unit to find the dataset, because it isn't a temp dataset. Cliff McNeill I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
Don, Check the JCL reference manual under DD DISP parameter. If you have an OLD permanent dataset that was PASSed to the step, the normal disposition is DELETE if the dataset was originally new. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J R Sent: Friday, May 23, 2014 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Puzzler DISP=OLD in STEP2 defaults to KEEP, so dataset is no longer in PASS catalog. Date: Fri, 23 May 2014 16:02:08 + From: dgrins...@mt.gov Subject: Friday Puzzler To: IBM-MAIN@LISTSERV.UA.EDU I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.govmailto:dgrins...@mt.gov The difference between a conviction and a prejudice is that you can explain a conviction without getting angry. ~ anonymous -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Grinsell, Don :: Sent: Friday, May 23, 2014 9:02 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Friday Puzzler :: :: I have an end user job that is getting a JCL error and I know how to fix :: it but I can't explain exactly why it's failing. I can recreate the :: error with the following JCL: :: :: //STEP1 EXEC PGM=IEFBR14 :: //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), :: // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 :: //STEP2 EXEC PGM=IEFBR14 :: //DD1 DD * :: RECORD1 :: // DD DSN=F00.DUMMY,DISP=OLD :: //STEP3 EXEC PGM=IEFBR14 :: //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) :: :: F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 :: causing STEP3 to get a JCL error. I can correct the situation by :: specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My :: question is why does the dataset get deleted in STEP2? You need to look at the Normal Termination Disposition Subparameter section of the JCL reference. There are different actions depending on SMS vs non-SMS, temporary vs permanent, etc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
What DISP does JESYSMSG show for STEP2's DD1, when STEP2 terminates, if you code instead //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=OLD -- //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) ? Grinsell, Don wrote: I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.govmailto:dgrins...@mt.gov The difference between a conviction and a prejudice is that you can explain a conviction without getting angry. ~ anonymous -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
On Fri, 23 May 2014 16:25:10 +, Pommier, Rex wrote: Check the JCL reference manual under DD DISP parameter. If you have an OLD permanent dataset that was PASSed to the step, the normal disposition is DELETE if the dataset was originally new. FSVO permanent. I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
I think we have a winner. Table 14 in the manual kind of sort of makes that clear. To quote Charlie Brown...Aaaargh! -- Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.gov To understand something does not mean approval of it. ~ Commander Spock -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Friday, May 23, 2014 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Puzzler Don, Check the JCL reference manual under DD DISP parameter. If you have an OLD permanent dataset that was PASSed to the step, the normal disposition is DELETE if the dataset was originally new. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J R Sent: Friday, May 23, 2014 11:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Puzzler DISP=OLD in STEP2 defaults to KEEP, so dataset is no longer in PASS catalog. Date: Fri, 23 May 2014 16:02:08 + From: dgrins...@mt.gov Subject: Friday Puzzler To: IBM-MAIN@LISTSERV.UA.EDU I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.govmailto:dgrins...@mt.gov The difference between a conviction and a prejudice is that you can explain a conviction without getting angry. ~ anonymous -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
Actually according to the JCL reference manual, a permanent dataset is simply one that has a non-temporary DSN assigned to it. So from that aspect, FSVO is actually FAVO = for all values of. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, May 23, 2014 11:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Puzzler On Fri, 23 May 2014 16:25:10 +, Pommier, Rex wrote: Check the JCL reference manual under DD DISP parameter. If you have an OLD permanent dataset that was PASSed to the step, the normal disposition is DELETE if the dataset was originally new. FSVO permanent. I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
On Fri, 23 May 2014 16:02:08 +, Grinsell, Don wrote: I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 The data set is not deleted. It is removed from the passed data queue. (Is that still what it is called?) causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? When a PASSed data set is referenced in a subsequent step, it is removed from the passed data queue. If you had another DD in STEP2 that referenced the same data set, that allocation would fail also. Another way to fix the problem would be to add VOL=REF=*.STEP1.DD1 to the DD in STEP3, proving that the data set was not deleted at the end of STEP2. In fact, you could also resolve the problem by putting the VOL=REF=*.STEP1.DD1 on the DD in STEP2. In that case, the passed data queue is not used, leaving the entry there to be used in step 3. The reference to the default of DELETE for a new data set does not apply here. That default is for the step, not the job. The default for the data set in STEP2 is KEEP, because it was OLD in STEP2. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
Tom, Thanks for the suggestion. I gave it a try and added VOL=REF=*.STEP1.DD1 to the STEP3 DD. My job got a JCL error with the following additional message: IGD17054I DATA SET NOT FOUND FOR DELETE/RENAME ON VOLUME TS741D 997 DATA SET IS F00.DUMMY IGD17054I DATA SET NOT FOUND FOR DELETE/RENAME ON VOLUME TS741D 998 DATA SET IS F00.DUMMY IEF378I xxF STEP3 - JOB FAILED - TIME=13.11.15 999 CATALOG DISPOSITION ERROR Step 2 indicates that the dataset was deleted: IEF236I ALLOC. FOR CZ0055F STEP2 IEF237I JES2 ALLOCATED TO DD1 IGD103I SMS ALLOCATED TO DDNAME IEF142I xxF STEP2 - STEP WAS EXECUTED - COND CODE IEF285I xx.xxF.JOB94242.D101.? SYSIN IGD105I F00.DUMMYDELETED, DDNAME= Step 3 is a little more descriptive: IEF236I ALLOC. FOR xxF STEP3 IGD103I SMS ALLOCATED TO DDNAME DD1 IEF142I xxF STEP3 - STEP WAS EXECUTED - COND CODE IGD17054I DATA SET NOT FOUND FOR DELETE/RENAME ON VOLUME TS741D DATA SET IS F00.DUMMY But then I get this after the step termination blocks for STEP3: IEF373I STEP/STEP3 /START 2014143.1311 IEF032I STEP/STEP3 /STOP 2014143.1311 CPU: 0 HR 00 MIN 00.00 SECSRB: 0 HR 00 MIN 00.00 SEC VIRT: 8K SYS: 228K EXT:8K SYS:11372K IEF379I xxF STEP3 - JOB ENDED BECAUSE OF CATALOG ERROR I then added the VOL=REF to the DD statement in STEP2. The job completed normally, but still produced the IGD17054I messages. STEP2 produced the following: IEF236I ALLOC. FOR xxF STEP2 IEF237I JES2 ALLOCATED TO DD1 IGD103I SMS ALLOCATED TO DDNAME IEF142I xxF STEP2 - STEP WAS EXECUTED - COND CODE IEF285I xx.xxF.JOB94251.D101.? SYSIN IGD104I F00.DUMMYRETAINED, DDNAME= Step3: IEF236I ALLOC. FOR xxF STEP3 IGD103I SMS ALLOCATED TO DDNAME DD1 IEF142I xxF STEP3 - STEP WAS EXECUTED - COND CODE IGD105I F00.DUMMYDELETED, DDNAME=DD1 Post Step3: IGD103I SMS ALLOCATED TO DDNAME SYS1 IGD104I SYS14143.T131544.RA000.xxF.R0148444 RETAINED, DDNAME=SYS1 IGD17054I DATA SET NOT FOUND FOR DELETE/RENAME ON VOLUME 9393A3 DATA SET IS F00.DUMMY Curiouser and Curiouser, as the saying goes. Have a great weekend everybody! -- Donald Grinsell State of Montana 406-444-2983 dgrins...@mt.gov To understand something does not mean approval of it. ~ Commander Spock -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Friday, May 23, 2014 12:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Puzzler On Fri, 23 May 2014 16:02:08 +, Grinsell, Don wrote: I have an end user job that is getting a JCL error and I know how to fix it but I can't explain exactly why it's failing. I can recreate the error with the following JCL: //STEP1 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(NEW,PASS,DELETE), // UNIT=TEMPSTOR,SPACE=(TRK,1),RECFM=FB,LRECL=80 //STEP2 EXEC PGM=IEFBR14 //DD1 DD * RECORD1 // DD DSN=F00.DUMMY,DISP=OLD //STEP3 EXEC PGM=IEFBR14 //DD1 DD DSN=F00.DUMMY,DISP=(OLD,DELETE,KEEP) F00.DUMMY gets allocated in STEP1 and is deleted at the end of STEP2 The data set is not deleted. It is removed from the passed data queue. (Is that still what it is called?) causing STEP3 to get a JCL error. I can correct the situation by specifying DISP=(OLD,PASS) in STEP2 or simply removing STEP3. My question is why does the dataset get deleted in STEP2? When a PASSed data set is referenced in a subsequent step, it is removed from the passed data queue. If you had another DD in STEP2 that referenced the same data set, that allocation would fail also. Another way to fix the problem would be to add VOL=REF=*.STEP1.DD1 to the DD in STEP3
Re: Friday Puzzler
Rex: e had one vender ho created the foo.dummy and insisted it as a temporary dataset (it as permanent. I argue ith them long and hard and they stood their ground so hen it came time to renew their contract I made sure it wasn't and we went with another vendor. \ Ed On May 23, 2014, at 12:33 PM, Pommier, Rex wrote: Actually according to the JCL reference manual, a permanent dataset is simply one that has a non-temporary DSN assigned to it. So from that aspect, FSVO is actually FAVO = for all values of. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Paul Gilmartin Sent: Friday, May 23, 2014 11:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Friday Puzzler On Fri, 23 May 2014 16:25:10 +, Pommier, Rex wrote: Check the JCL reference manual under DD DISP parameter. If you have an OLD permanent dataset that was PASSed to the step, the normal disposition is DELETE if the dataset was originally new. FSVO permanent. I hate JCL! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
On Fri, 23 May 2014 19:31:18 +, Grinsell, Don wrote: Thanks for the suggestion. I gave it a try and added VOL=REF=*.STEP1.DD1 to the STEP3 DD. My job got a JCL error with the following additional message: IGD17054I DATA SET NOT FOUND FOR DELETE/RENAME ON VOLUME TS741D 997 DATA SET IS F00.DUMMY IGD17054I DATA SET NOT FOUND FOR DELETE/RENAME ON VOLUME TS741D 998 DATA SET IS F00.DUMMY IEF378I xxF STEP3 - JOB FAILED - TIME=13.11.15 999 CATALOG DISPOSITION ERROR Strange. I tested with JCL copied/pasted from your original post and got the results as I described. My data set was allocated on an SMS managed volume, just like yours was. If I change the DISP on STEP3 to (OLD,DELETE), I get the IGD17054I message, but only once. STEP3 executes though; there is no JCL error. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Friday Puzzler
Why not just catalog the dataset or use a temp DSN? Is there a real need for an uncataloged dataset? The messages begin with IGD, so you are working with SMS datasets. While you can allocate / use non-cataloged datasets, I thought they would not be permanently retained. I thought part of the concept was to eliminate uncataloged datasets. If not, then look at your SMS related products. I suspect some allow conversion to delete for uncataloged datasets. I vaguely remember a product that allowed you to write scripts to change dataset disposition based on the criteria you set (20 years ago, I think it was called SAMS). Alternatively, you could try putting the dataset to non-SMS volume. Jon Perryman On Friday, May 23, 2014 12:31 PM, Grinsell, Don dgrins...@mt.gov wrote: Step 2 indicates that the dataset was deleted: IGD105I F00.DUMMY DELETED, DDNAME= Step 3 is a little more descriptive: IGD103I SMS ALLOCATED TO DDNAME DD1 IEF142I xxF STEP3 - STEP WAS EXECUTED - COND CODE IGD17054I DATA SET NOT FOUND FOR DELETE/RENAME ON VOLUME TS741D DATA SET IS F00.DUMMY But then I get this after the step termination blocks for STEP3: IEF379I xxF STEP3 - JOB ENDED BECAUSE OF CATALOG ERROR -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
