Re: JCL PROBLEM - REVISITED
After the PROC001 statement, code //TAPE DD VOL=(,RETAIN,,35) to override just the volume operand on that DD statement. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On :: Behalf Of John Dawes :: Sent: Tuesday, June 05, 2012 3:50 PM :: To: IBM-MAIN@bama.ua.edu :: Subject: Re: JCL PROBLEM - REVISITED :: :: Since there is a VOL parm already coded how can I code the number of :: volumes e.g. VOL=(,,,35) ? The system default is only 5. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
Just a point which may not be obvious (at least it wasn't to me). The default of 5 tape volumes is hard coded only for non-SMS managed tapes. Truly! If you are using SMS managed tapes (in an automated or even manual library), then you can assign a default DATACLAS. In this DATACLAS, you can set the volume count to something else. We started having problems with some backups of files which had ballooned suddenly, which was causing a lot of abends due to exceeding tape volumes. There were simply too many JCL streams to update in a timely manner (change control). Since all our application tapes are in a VTS library, and so SMS managed, I simply changed our default DATACLAS which is assigned to virtual tapes to have a volume count of 110. Saved a ton of work. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 5:22 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL PROBLEM Thanks for the tip. If I need to code the vol parm e.g. VOL=(,,,35) if the output exceedes 5 vols (system default) how would I go about it since I already have a vol parm in the jcl. From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:30 PM Subject: Re: JCL PROBLEM Might I suggest a RETAIN on the FIRST step and omit on the LAST step? On Tue, Jun 5, 2012 at 4:20 PM, John Dawes jhn_da...@yahoo.com.au wrote: John, You were spot on. Your suggestion worked. Thanks a million. Thanks to all who responded for my plea for help. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
John, May I ask where you work? My friends in Australia may know some of the management folks at your site. Is there anything I can send to you to help your cause? What types of JCL issues do you typically have? May I ask what batch scheduler you use? Change management tool? .anything else you can tell me. Cheers, Mitch McCluhan -Original Message- From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN IBM-MAIN@bama.ua.edu Sent: Wed, Jun 6, 2012 5:15 am Subject: Re: JCL PROBLEM Just a point which may not be obvious (at least it wasn't to me). The default of 5 tape volumes is hard coded only for non-SMS managed tapes. Truly! If you are using SMS managed tapes (in an automated or even manual library), then you can assign a default DATACLAS. In this DATACLAS, you can set the volume count to something else. We started having problems with some backups of files which had ballooned suddenly, which was causing a lot of abends due to exceeding tape volumes. There were simply too many JCL streams to update in a timely manner (change control). Since all our application tapes are in a VTS library, and so SMS managed, I simply changed our default DATACLAS which is assigned to virtual tapes to have a volume count of 110. Saved a ton of work. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 5:22 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL PROBLEM Thanks for the tip. If I need to code the vol parm e.g. VOL=(,,,35) if the output exceedes 5 vols (system default) how would I go about it since I already have a vol parm in the jcl. From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:30 PM Subject: Re: JCL PROBLEM Might I suggest a RETAIN on the FIRST step and omit on the LAST step? On Tue, Jun 5, 2012 at 4:20 PM, John Dawes jhn_da...@yahoo.com.au wrote: John, You were spot on. Your suggestion worked. Thanks a million. Thanks to all who responded for my plea for help. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
Where I work is in all my sig lines. Doesn't matter, if you're thinking of anything that costs money. We aren't spending any more than we currently do. And we may actually get more budget cuts in 2013. Our main OEM vendor is CA. We don't normally have JCL problems, the one I mentioned was endemic due to converting from BMC's Data Accelerator compression to SMS compression and its effect on CA-Faver backups. The z/OS system is generally moribund. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Mitch Sent: Wednesday, June 06, 2012 9:46 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL PROBLEM John, May I ask where you work? My friends in Australia may know some of the management folks at your site. Is there anything I can send to you to help your cause? What types of JCL issues do you typically have? May I ask what batch scheduler you use? Change management tool? .anything else you can tell me. Cheers, Mitch McCluhan -Original Message- From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN IBM-MAIN@bama.ua.edu Sent: Wed, Jun 6, 2012 5:15 am Subject: Re: JCL PROBLEM Just a point which may not be obvious (at least it wasn't to me). The default of 5 tape volumes is hard coded only for non-SMS managed tapes. Truly! If you are using SMS managed tapes (in an automated or even manual library), then you can assign a default DATACLAS. In this DATACLAS, you can set the volume count to something else. We started having problems with some backups of files which had ballooned suddenly, which was causing a lot of abends due to exceeding tape volumes. There were simply too many JCL streams to update in a timely manner (change control). Since all our application tapes are in a VTS library, and so SMS managed, I simply changed our default DATACLAS which is assigned to virtual tapes to have a volume count of 110. Saved a ton of work. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 5:22 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL PROBLEM Thanks for the tip. If I need to code the vol parm e.g. VOL=(,,,35) if the output exceedes 5 vols (system default) how would I go about it since I already have a vol parm in the jcl. From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:30 PM Subject: Re: JCL PROBLEM Might I suggest a RETAIN on the FIRST step and omit on the LAST step? On Tue, Jun 5, 2012 at 4:20 PM, John Dawes jhn_da...@yahoo.com.au wrote: John, You were spot on. Your suggestion worked. Thanks a million. Thanks to all who responded for my plea for help. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access
JCL PROBLEM
G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
At what step do you get this error? PROC001, PROC003, etc... Lizette -Original Message- From: John Dawes jhn_da...@yahoo.com.au Sent: Jun 5, 2012 2:01 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
At PROC002 //STEP01.TAPE From: Lizette Koehler stars...@mindspring.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:06 PM Subject: Re: JCL PROBLEM At what step do you get this error? PROC001, PROC003, etc... Lizette -Original Message- From: John Dawes jhn_da...@yahoo.com.au Sent: Jun 5, 2012 2:01 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
I'll try out your suggestion. Thanks. From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:05 PM Subject: Re: JCL PROBLEM I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
I agree. Your names are confusing. PROC001 is the step name. STEP01 is the proc step name. (The name of the step in the proc.) Thank you and have a Terrific day! Jonathan Goossen, DTM ACT Mainframe Storage Group Personal: 651-361-4541 Department Support Line: 651-361- For help with communication and leadership skills checkout Woodwinds Toastmasters. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 06/05/2012 04:05:05 PM: From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu Date: 06/05/2012 04:05 PM Subject: Re: JCL PROBLEM Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid- West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPEDD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, //DSORG=PS,TRTCH=COMP,UNIT=MAN3590, //VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), //LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSINDD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have
Re: JCL PROBLEM
That's why we use JSnnn for JobStep and PSnnn for ProcStep in our shop. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jonathan Goossen Sent: Tuesday, June 05, 2012 4:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL PROBLEM I agree. Your names are confusing. PROC001 is the step name. STEP01 is the proc step name. (The name of the step in the proc.) Thank you and have a Terrific day! Jonathan Goossen, DTM ACT Mainframe Storage Group Personal: 651-361-4541 Department Support Line: 651-361- For help with communication and leadership skills checkout Woodwinds Toastmasters. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 06/05/2012 04:05:05 PM: From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu Date: 06/05/2012 04:05 PM Subject: Re: JCL PROBLEM Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid- West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPEDD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, //DSORG=PS,TRTCH=COMP,UNIT=MAN3590, //VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), //LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSINDD
Re: JCL PROBLEM
John, You were spot on. Your suggestion worked. Thanks a million. Thanks to all who responded for my plea for help. From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:05 PM Subject: Re: JCL PROBLEM I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
Might I suggest a RETAIN on the FIRST step and omit on the LAST step? On Tue, Jun 5, 2012 at 4:20 PM, John Dawes jhn_da...@yahoo.com.au wrote: John, You were spot on. Your suggestion worked. Thanks a million. Thanks to all who responded for my plea for help. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
Besides that issue, the refback should ALWAYS be to the previous step, not the first step.If it ever goes to a 2nd volume you will get an abend. Gee... it's been so long that I've dealt with anyone doing that I can't remember, but I think it's an A13 abend. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Tue, 5 Jun 2012 16:05:05 -0500, McKown, John john.mck...@healthmarkets.com wrote: I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
Thanks for the tip. If I need to code the vol parm e.g. VOL=(,,,35) if the output exceedes 5 vols (system default) how would I go about it since I already have a vol parm in the jcl. From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:30 PM Subject: Re: JCL PROBLEM Might I suggest a RETAIN on the FIRST step and omit on the LAST step? On Tue, Jun 5, 2012 at 4:20 PM, John Dawes jhn_da...@yahoo.com.au wrote: John, You were spot on. Your suggestion worked. Thanks a million. Thanks to all who responded for my plea for help. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM - REVISITED
Since there is a VOL parm already coded how can I code the number of volumes e.g. VOL=(,,,35) ? The system default is only 5. From: John Dawes jhn_da...@yahoo.com.au To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 6:21 PM Subject: Re: JCL PROBLEM Thanks for the tip. If I need to code the vol parm e.g. VOL=(,,,35) if the output exceedes 5 vols (system default) how would I go about it since I already have a vol parm in the jcl. From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, 5 June 2012 5:30 PM Subject: Re: JCL PROBLEM Might I suggest a RETAIN on the FIRST step and omit on the LAST step? On Tue, Jun 5, 2012 at 4:20 PM, John Dawes jhn_da...@yahoo.com.au wrote: John, You were spot on. Your suggestion worked. Thanks a million. Thanks to all who responded for my plea for help. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
Oh, and catalog all the datasets. During a DR test, only the first dataset was cataloged and it was on just the first volume, and only the first tape was sent for the exercise. Since there was no cataloged datasets on the second tape, it was not sent. The application people had to Fedex the second tape to complete their test. On Tue, Jun 5, 2012 at 4:51 PM, Mark Zelden m...@mzelden.com wrote: Besides that issue, the refback should ALWAYS be to the previous step, not the first step. If it ever goes to a 2nd volume you will get an abend. Gee... it's been so long that I've dealt with anyone doing that I can't remember, but I think it's an A13 abend. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Tue, 5 Jun 2012 16:05:05 -0500, McKown, John john.mck...@healthmarkets.com wrote: I'm fairly sure you need the REF=*.STEP01.PROC001.TAPE to be REF=*.PROC001.STEP01.TAPE -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, June 05, 2012 4:02 PM To: IBM-MAIN@bama.ua.edu Subject: JCL PROBLEM G'Day, I am having a problem (jcl error) trying to run this job. The object is to have all the backups written out to a 3592 tape. //*** //PROC001 EXEC FCBPRDXX,TARGET='FQ8A00',SOURCE='PAGE01',LB='1' //PROC002 EXEC FCBPRDXX,TARGET='FQ8A01',SOURCE='CSYS01',LB='2' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC003 EXEC FCBPRDXX,TARGET='FQ8A02',SOURCE='CSYS02',LB='3' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC004 EXEC FCBPRDXX,TARGET='FQ8A03',SOURCE='CSYS03',LB='4' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC005 EXEC FCBPRDXX,TARGET='FQ8A04',SOURCE='CSYS04',LB='5' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC006 EXEC FCBPRDXX,TARGET='FQ8A05',SOURCE='CSYS05',LB='6' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC007 EXEC FCBPRDXX,TARGET='FQ8A06',SOURCE='CSYS06',LB='7' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC008 EXEC FCBPRDXX,TARGET='FQ8A07',SOURCE='CSYS07',LB='8' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC009 EXEC FCBPRDXX,TARGET='FQ8A08',SOURCE='PAGE02',LB='9' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) //PROC010 EXEC FCBPRDXX,TARGET='FQ8A09',SOURCE='HFSC01',LB='10' //STEP01.TAPE DD VOL=(,RETAIN,,REF=*.STEP01.PROC001.TAPE) This is the proc: //FCBPRDXX PROC //* //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' //DISK DD VOL=SER=TARGET,DISP=SHR,UNIT=3390 //*TAPE DD DSN=BKUP..XX.VSOURCE.XX, //TAPE DD DSN=BKUP.DISTR.PRDDLY.VSOURCE..D050612.TEST, // DSORG=PS,TRTCH=COMP,UNIT=MAN3590, // VOL=(,RETAIN),DISP=(NEW,CATLG,DELETE), // LABEL=(LB,SL) //SYSPRINT DD SYSOUT=* //SYSIN DD DISP=SHR,DSN=SYS3.FLASHCPY.PROCLIB(#FCCOPY) //* The message I get is : IEF645I INVALID REFERBACK IN THE REF SUBPARAMETER OF THE VOLUME FIELD I cannot spot my error. Can someone help me out? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL PROBLEM
The keywords go after the positional parameters. On Tue, Jun 5, 2012 at 5:21 PM, John Dawes jhn_da...@yahoo.com.au wrote: Thanks for the tip. If I need to code the vol parm e.g. VOL=(,,,35) if the output exceedes 5 vols (system default) how would I go about it since I already have a vol parm in the jcl. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
JCL help (yes, with COND)
I have the following job (cut down to include only the relevant parts): //VAPPROC4 JOB //BACKUP1 EXEC PROC=SORTBKUP,COND=(4,LT) //EP4IN EXEC PROC=EP4IN,COND=(4,LT) //E4INPRT EXEC PROC=E4INPRT // The EP4IN PROC is a vendor supplied proc as follows: //EP4IN PROC //STEP01 EXEC PGM=IEFBR14,COND=(20,LT) //STEP01A EXEC PGM=IEFBR14,COND=(20,LT) //STEP02 EXEC PGM=EPZOS,COND=(20,LT) //STEP03 EXEC PGM=IDCAMS,COND=(7,LT) //STEP04 EXEC PGM=EPTBLUPD // IF ( STEP04.RC = 3 ) THEN //STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04)) // ENDIF // IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN //STEPLAST EXEC EPLINK99 // ENDIF //EP4IN PEND //STEP06 EXEC PGM=IEBGENER,COND=(24,LT) //STEP07 EXEC PGM=EPX99,COND=(20,LT) //EP4IN PROC I've already solved my issue (which I will detail below), but I'm still unclear as to why what I had was wrong, and why my fix actually fixes it. The issue is that EP4IN.STEP06 and EP4IN.STEP07 were not being executed: IEF202I VAPPROC4 STEP06 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES IEF272I VAPPROC4 STEP06 EP4IN - STEP WAS NOT EXECUTED. IEF202I VAPPROC4 STEP07 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES IEF272I VAPPROC4 STEP07 EP4IN - STEP WAS NOT EXECUTED. STEPNAME PROCSTEP RC BACKUP1 BACKUP 00 EP4IN STEP01 00 EP4IN STEP01A 00 EP4IN STEP02 00 EP4IN STEP03 05 EP4IN STEP04 FLUSH EP4IN STEP05 FLUSH STEPLAST STEP16 FLUSH STEPLAST STEP17 FLUSH EP4IN STEP06 FLUSH EP4IN STEP07 FLUSH (It's expected that EP4IN.STEP04, EP4IN.STEP05, STEPLAST.STEP16 and STEPLAST.STEP17 do not execute under these conditions, becasue EP4IN.STEP03 resulted in RC=05; they execute only when RC=03 for this step.) Anyway, the solution is to remove the COND parameter from the EXEC PROC=EP4IN. My new result follows: BACKUP1 BACKUP 00 EP4IN STEP01 00 EP4IN STEP01A 00 EP4IN STEP02 00 EP4IN STEP03 05 EP4IN STEP04 FLUSH EP4IN STEP05 FLUSH STEPLAST STEP16 FLUSH STEPLAST STEP17 FLUSH EP4IN STEP06 00 EP4IN STEP07 00 E4INPRT REPORT 00 What really was the issue and why did my solution resolve it? My reason for including this parameter is so that EP4IN should be bypassed if BACKUP1 fails. Once again I ponder the sanity of the inventor of COND. Thanks, Frank -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL help (yes, with COND)
On 04/18/2012 12:43 PM, Frank Swarbrick wrote: I have the following job (cut down to include only the relevant parts): //VAPPROC4 JOB //BACKUP1 EXEC PROC=SORTBKUP,COND=(4,LT) //EP4INEXEC PROC=EP4IN,COND=(4,LT) //E4INPRT EXEC PROC=E4INPRT // The EP4IN PROC is a vendor supplied proc as follows: //EP4IN PROC //STEP01 EXEC PGM=IEFBR14,COND=(20,LT) //STEP01A EXEC PGM=IEFBR14,COND=(20,LT) //STEP02 EXEC PGM=EPZOS,COND=(20,LT) //STEP03 EXEC PGM=IDCAMS,COND=(7,LT) //STEP04 EXEC PGM=EPTBLUPD // IF ( STEP04.RC = 3 ) THEN //STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04)) // ENDIF // IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN //STEPLAST EXEC EPLINK99 // ENDIF //EP4IN PEND //STEP06 EXEC PGM=IEBGENER,COND=(24,LT) //STEP07 EXEC PGM=EPX99,COND=(20,LT) //EP4IN PROC I've already solved my issue (which I will detail below), but I'm still unclear as to why what I had was wrong, and why my fix actually fixes it. The issue is that EP4IN.STEP06 and EP4IN.STEP07 were not being executed: IEF202I VAPPROC4 STEP06 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES IEF272I VAPPROC4 STEP06 EP4IN - STEP WAS NOT EXECUTED. IEF202I VAPPROC4 STEP07 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES IEF272I VAPPROC4 STEP07 EP4IN - STEP WAS NOT EXECUTED. STEPNAME PROCSTEPRC BACKUP1 BACKUP 00 EP4INSTEP01 00 EP4INSTEP01A 00 EP4INSTEP02 00 EP4INSTEP03 05 EP4INSTEP04 FLUSH EP4INSTEP05 FLUSH STEPLAST STEP16 FLUSH STEPLAST STEP17 FLUSH EP4INSTEP06 FLUSH EP4INSTEP07 FLUSH (It's expected that EP4IN.STEP04, EP4IN.STEP05, STEPLAST.STEP16 and STEPLAST.STEP17 do not execute under these conditions, becasue EP4IN.STEP03 resulted in RC=05; they execute only when RC=03 for this step.) Anyway, the solution is to remove the COND parameter from the EXEC PROC=EP4IN. My new result follows: BACKUP1 BACKUP 00 EP4INSTEP01 00 EP4INSTEP01A 00 EP4INSTEP02 00 EP4INSTEP03 05 EP4INSTEP04 FLUSH EP4INSTEP05 FLUSH STEPLAST STEP16 FLUSH STEPLAST STEP17 FLUSH EP4INSTEP06 00 EP4INSTEP07 00 E4INPRT REPORT 00 What really was the issue and why did my solution resolve it? My reason for including this parameter is so that EP4IN should be bypassed if BACKUP1 fails. Once again I ponder the sanity of the inventor of COND. Thanks, Frank The EP4IN PROC seems to have an embedded PEND and then a spurious PROC statement at the end (where the PEND should be ?). I suspect the problem is that combining COND on an EXEC PROC with embedded use of COND inside a PROC does not interact well and seldom does what one might expect/want. The COND on the EXEC PROC statement does not determine whether that EXEC is performed -- it instead overrides the COND parameter on every EXEC within the PROC and determines when steps within the PROC will be executed, completely ignoring any original carefully thought out conditional logic using COND on EXECs within the PROC definition itself. As a side issue, mixing IF/THEN/ELSE conditional execution with use of COND is so highly confusing, we always recommended not introducing the new forms without converting old EXEC COND usage to IF/THEN/ELSE statements at the same time (except possibly for COND on the JOB statement). Also one can use IF/THEN/ELSE in the main JCL stream without the bizarre override issues you get with COND on the EXEC PROC. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL help (yes, with COND)
Sorry, my cut and paste went awry. Should be this: //EP4IN PROC //STEP01 EXEC PGM=IEFBR14,COND=(20,LT) //STEP01A EXEC PGM=IEFBR14,COND=(20,LT) //STEP02 EXEC PGM=EPZOS,COND=(20,LT) //STEP03 EXEC PGM=IDCAMS,COND=(7,LT) //STEP04 EXEC PGM=EPTBLUPD // IF ( STEP04.RC = 3 ) THEN //STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04)) // ENDIF // IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN //STEPLAST EXEC EPLINK99 // ENDIF //STEP06 EXEC PGM=IEBGENER,COND=(24,LT) //STEP07 EXEC PGM=EPX99,COND=(20,LT) //EP4IN PEND Anyway, I did totally misunderstand how COND works when executing a PROC rather than a PGM. Thanks! As for mixing IF/THEN/ELSE with COND, as I said, its a vendor supplied PROC. Definitely don't want to mess with it. But it looks like you're saying I can use IF/THEN logic to skip the EP4IN step if the BACKUP1 step fails. So I will do that. As much as I hate COND, at least it fits within how JCL otherwise looks, which is more than I can say for IF/THEN/ELSE! Oh well! Thanks again, Frank From: Joel C. Ewing jcew...@acm.org To: IBM-MAIN@bama.ua.edu Sent: Wednesday, April 18, 2012 1:14 PM Subject: Re: JCL help (yes, with COND) On 04/18/2012 12:43 PM, Frank Swarbrick wrote: I have the following job (cut down to include only the relevant parts): //VAPPROC4 JOB //BACKUP1 EXEC PROC=SORTBKUP,COND=(4,LT) //EP4IN EXEC PROC=EP4IN,COND=(4,LT) //E4INPRT EXEC PROC=E4INPRT // The EP4IN PROC is a vendor supplied proc as follows: //EP4IN PROC //STEP01 EXEC PGM=IEFBR14,COND=(20,LT) //STEP01A EXEC PGM=IEFBR14,COND=(20,LT) //STEP02 EXEC PGM=EPZOS,COND=(20,LT) //STEP03 EXEC PGM=IDCAMS,COND=(7,LT) //STEP04 EXEC PGM=EPTBLUPD // IF ( STEP04.RC = 3 ) THEN //STEP05 EXEC PGM=IEBGENER,COND=((7,LT),(4,LT,STEP03),(4,LT,STEP04)) // ENDIF // IF ( STEP04.RC = 0 | STEP04.RC = 4 ) THEN //STEPLAST EXEC EPLINK99 // ENDIF //EP4IN PEND //STEP06 EXEC PGM=IEBGENER,COND=(24,LT) //STEP07 EXEC PGM=EPX99,COND=(20,LT) //EP4IN PROC I've already solved my issue (which I will detail below), but I'm still unclear as to why what I had was wrong, and why my fix actually fixes it. The issue is that EP4IN.STEP06 and EP4IN.STEP07 were not being executed: IEF202I VAPPROC4 STEP06 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES IEF272I VAPPROC4 STEP06 EP4IN - STEP WAS NOT EXECUTED. IEF202I VAPPROC4 STEP07 EP4IN - STEP WAS NOT RUN BECAUSE OF CONDITION CODES IEF272I VAPPROC4 STEP07 EP4IN - STEP WAS NOT EXECUTED. STEPNAME PROCSTEP RC BACKUP1 BACKUP 00 EP4IN STEP01 00 EP4IN STEP01A 00 EP4IN STEP02 00 EP4IN STEP03 05 EP4IN STEP04 FLUSH EP4IN STEP05 FLUSH STEPLAST STEP16 FLUSH STEPLAST STEP17 FLUSH EP4IN STEP06 FLUSH EP4IN STEP07 FLUSH (It's expected that EP4IN.STEP04, EP4IN.STEP05, STEPLAST.STEP16 and STEPLAST.STEP17 do not execute under these conditions, becasue EP4IN.STEP03 resulted in RC=05; they execute only when RC=03 for this step.) Anyway, the solution is to remove the COND parameter from the EXEC PROC=EP4IN. My new result follows: BACKUP1 BACKUP 00 EP4IN STEP01 00 EP4IN STEP01A 00 EP4IN STEP02 00 EP4IN STEP03 05 EP4IN STEP04 FLUSH EP4IN STEP05 FLUSH STEPLAST STEP16 FLUSH STEPLAST STEP17 FLUSH EP4IN STEP06 00 EP4IN STEP07 00 E4INPRT REPORT 00 What really was the issue and why did my solution resolve it? My reason for including this parameter is so that EP4IN should be bypassed if BACKUP1 fails. Once again I ponder the sanity of the inventor of COND. Thanks, Frank The EP4IN PROC seems to have an embedded PEND and then a spurious PROC statement at the end (where the PEND should be ?). I suspect the problem is that combining COND on an EXEC PROC with embedded use of COND inside a PROC does not interact well and seldom does what one might expect/want. The COND on the EXEC PROC statement does not determine whether that EXEC is performed -- it instead overrides the COND parameter on every EXEC within the PROC and determines when steps within the PROC will be executed, completely ignoring any original carefully thought out conditional logic using COND on EXECs within the PROC definition itself. As a side issue, mixing IF/THEN/ELSE conditional execution with use of COND is so highly confusing, we always recommended not introducing the new forms without converting old EXEC COND usage to IF/THEN/ELSE statements at the same time (except possibly for COND on the JOB statement). Also one can use IF/THEN/ELSE in the main JCL stream without the bizarre override issues you get with COND on the EXEC PROC. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu
Re: Another JCL wish.
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 03/22/2012 at 04:17 PM, McKown, John john.mck...@healthmarkets.com said: This may be another weird desire on my part. But I'm wondering why IBM does not enhance the QSAM and BSAM access methods to support the OPTCD=Q and CCSID= parameters on the DD statememt to work with datasets on media other than tape. This is a case where asking for too little is worse than not asking at all. I'd like to see support for translating among arbitrary code pages, including UTF-8, using better translate tables than those used by the old OPTCD=Q support. Have you submitted a requirement, with a business case? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Another JCL wish.
This may be another weird desire on my part. But I'm wondering why IBM does not enhance the QSAM and BSAM access methods to support the OPTCD=Q and CCSID= parameters on the DD statememt to work with datasets on media other than tape. Especially z/OS UNIX files. There are times when I would really like to keep some data in z/OS UNIX files using the ISO8859-1 code page. This works fairly well with z/OS UNIX commands when I use the chtag and extattr commands to properly tag the files. It would be really helpful to me if I could then read those files into standard legacy applications using PATH=...,FILEDATA=TEXT,RECFM=..,LRECL=..,CCSID=819 on the DD. There must be some sort of code in QSAM and BSAM already since you can read ASCII tapes using DCB=OPTCD=Q. Of course, I don't know how creaky that code is. I think that IBM avoids touching some old parts of z/OS just out of fear. Perhaps it is time to download GPSAM from the CBT and write my own code to do something like this. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Another JCL wish.
On Thu, 22 Mar 2012 16:17:30 -0500, McKown, John wrote: This may be another weird desire on my part. But I'm wondering why IBM does not enhance the QSAM and BSAM access methods to support the OPTCD=Q and CCSID= parameters on the DD statememt to work with datasets on media other than tape. Especially z/OS UNIX files. There are times when I would really like to keep some data in z/OS UNIX files using the ISO8859-1 code page. This works fairly well with z/OS UNIX commands when I use the chtag and extattr commands to properly tag the files. It would be really helpful to me if I could then read those files into standard legacy applications using PATH=...,FILEDATA=TEXT,RECFM=..,LRECL=..,CCSID=819 on the DD. There must be some sort of code in QSAM and BSAM already since you can read ASCII tapes using DCB=OPTCD=Q. Of course, I don't know how creaky that code is. I think that IBM avoids touching some old parts of z/OS just out of fear. OPTCD=Q uses the dreadful IGC0010C 7-bit translation table. Now, if you wanted (as you suggest) something like FTP's sbdataconn=(IBM-1047,ISO8859-1) facility, that might be meaningful. And, IIRC, FTP requires that one of the CPs be EBCDIC and the other ASCII (-like). Why not translate between two EBCDIC pages, such as 037-1047, or even ISO8859-1-UTF-8? (All things that iconv() (already supplied by IBM) does). (I almost forgot -- I hate EBCDIC!) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Another JCL wish.
Guys, We use it all the from ASCII to ebcdic using one of the supplied tcpip library modules works great..also from ebcdic to ASCII Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 22, 2012, at 5:27 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 22 Mar 2012 16:17:30 -0500, McKown, John wrote: This may be another weird desire on my part. But I'm wondering why IBM does not enhance the QSAM and BSAM access methods to support the OPTCD=Q and CCSID= parameters on the DD statememt to work with datasets on media other than tape. Especially z/OS UNIX files. There are times when I would really like to keep some data in z/OS UNIX files using the ISO8859-1 code page. This works fairly well with z/OS UNIX commands when I use the chtag and extattr commands to properly tag the files. It would be really helpful to me if I could then read those files into standard legacy applications using PATH=...,FILEDATA=TEXT,RECFM=..,LRECL=..,CCSID=819 on the DD. There must be some sort of code in QSAM and BSAM already since you can read ASCII tapes using DCB=OPTCD=Q. Of course, I don't know how creaky that code is. I think that IBM avoids touching some old parts of z/OS just out of fear. OPTCD=Q uses the dreadful IGC0010C 7-bit translation table. Now, if you wanted (as you suggest) something like FTP's sbdataconn=(IBM-1047,ISO8859-1) facility, that might be meaningful. And, IIRC, FTP requires that one of the CPs be EBCDIC and the other ASCII (-like). Why not translate between two EBCDIC pages, such as 037-1047, or even ISO8859-1-UTF-8? (All things that iconv() (already supplied by IBM) does). (I almost forgot -- I hate EBCDIC!) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
In 829975020fe05747b35aa575a61a6ac106d...@021-sn2mpn1-001.021d.mgd.msft.net, on 03/08/2012 at 04:57 PM, Tim Zielke tim.zie...@aonhewitt.com said: Some of these existing COBOL modules that will be relinked with the new BA4C1426 CSECT were compiled/linked under COBOL-II. We now use Enterprise COBOL 3.4 and the new BA4C1426 will be generated with Enterprise COBOL 3.4. Is mixing COBOL II and Enterprise COBOL supported? Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. Do they have a reason to believe that that would work? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
In an earlier post that apparently went astray I noted that the scheme of copying the same non-trivial COBOL program into around 11,000 other COBOL source programs is not---Let me be polite---a desirable one. This single program should be compiled just once; and the object module thus produced should then be linked, specifying NCAL, into a library that is made available for the other compile-and-link operations. This done the binder will resolve the external reference to it in these around 11,000 source programs by including it in the executable load modules produced by compiling and linking them. When this scheme is used the single program they all call will of course be a separate replaceable CSECT in these load modules. The question whether these operations will need to be done again any time soon also needs to be examined. If so, making this common routine a dynamically loaded one should be given very serious consideration (as an earlier poster pointed out in somewhat different terms).Dynamic loading is often used gratuitously; but in this situation, where many other routines invoke the same apparently volatile subroutine, it could very well be useful. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
Tim, In one of your replies over on the CICS-L list you gave this reasoning for the design decision to use static inclusion of this common module: Just some background on why the static call to BA4C1426 was done in the first place. This COBOL application is proprietary object-oriented programming (or as I like to call it obfuscation-oriented programming). So the BA4C1426 is the main data structure class that is a doubly linked list. So almost every class uses it, and to improve on performance they statically linked it into almost all of the classes. I would first question the application designers' original decision to statically include this module for performance reasons. Did they actually measure the difference between static inclusion and dynamic calls to an external version of that data structure subroutine? My (admittedly limited) understanding of the LE dynamic CALL mechanism is that reentrant dynamically CALLed modules are loaded only once and thereafter branched to directly (which obviously does include some LE overhead, but my unproved suspicion is that this LE overhead is quite small). Considering that an OO COBOL module is almost certainly eligible to be compiled RENT and linked RENT,REUS,REFR, that means only one copy of the module resident for all callers, no matter how many there are. The current application design ensures that in fact there are 11,000+ copies of this module, one in each other program that includes it. As you have discovered, this is a maintenance nightmare when the common module needs to change for any reason. If someone were to write a driver routine for this data structure subroutine to test all of its functions in a parameterized loop, then one could run two versions of that driver module, one statically linked and one using dynamic CALL and have the driver module exercise all the functions of the common module several hundreds of thousands or even millions of times to actually measure the performance difference. Then you would have actual data on which to base a decision. Just my USD$0.02 worth from the applications design and maintenance point of view. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tim Zielke Sent: Thursday, March 08, 2012 12:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL example to relink a CSECT into an existing load module This would require a recompile of pretty much the entire application which is around 11,000 load modules. This COBOL application is written in proprietary object oriented COBOL and each load module represents an object oriented class (for the most part). So a recompile of the entire application would require a testing/migration effort that is too arduous for the application team. However, if we can just change the statically compiled BA4C1426 program and relink it into the existing 11,000 load modules, it significantly reduces the scope of the change to something that is more manageable from a testing and migration effort. Thanks, Tim Zielke CICS/MQ Systems Programmer Aon Hewitt -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
On Fri, Mar 9, 2012 at 6:46 AM, Farley, Peter x23353 peter.far...@broadridge.com wrote: Tim, In one of your replies over on the CICS-L list you gave this reasoning for the design decision to use static inclusion of this common module: Just some background on why the static call to BA4C1426 was done in the first place. This COBOL application is proprietary object-oriented programming (or as I like to call it obfuscation-oriented programming). So the BA4C1426 is the main data structure class that is a doubly linked list. So almost every class uses it, and to improve on performance they statically linked it into almost all of the classes. I would first question the application designers' original decision to statically include this module for performance reasons. Did they actually measure the difference between static inclusion and dynamic calls to an external version of that data structure subroutine? My (admittedly limited) understanding of the LE dynamic CALL mechanism is that reentrant dynamically CALLed modules are loaded only once and thereafter branched to directly (which obviously does include some LE overhead, but my unproved suspicion is that this LE overhead is quite small). I'm guessing they measured again the COBOL dynamic call facility. Based on current experience their is significant overhead associated with the COBOL dynamic call facility as well as the C runtime program fetch facility. In both cases significant performance advantages can be gained by creating a small assembler program to LOAD/DELETE the desired module. In COBOL, the address of the LOADed module can be saved a variable defined as USAGE FUNCTION-POINTER. This allows a normal COBOL CALL statement to be used. In C just save the address of the loaded module in a variable defined as a function pointer. If the shop does not want to write their own load routine, LE provides several facilities (ceeplod, ceeplod2 and ceeplodt) depending on the requirements. Considering that an OO COBOL module is almost certainly eligible to be compiled RENT and linked RENT,REUS,REFR, that means only one copy of the module resident for all callers, no matter how many there are. The current application design ensures that in fact there are 11,000+ copies of this module, one in each other program that includes it. As you have discovered, this is a maintenance nightmare when the common module needs to change for any reason. If someone were to write a driver routine for this data structure subroutine to test all of its functions in a parameterized loop, then one could run two versions of that driver module, one statically linked and one using dynamic CALL and have the driver module exercise all the functions of the common module several hundreds of thousands or even millions of times to actually measure the performance difference. Then you would have actual data on which to base a decision. Just my USD$0.02 worth from the applications design and maintenance point of view. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tim Zielke Sent: Thursday, March 08, 2012 12:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL example to relink a CSECT into an existing load module This would require a recompile of pretty much the entire application which is around 11,000 load modules. This COBOL application is written in proprietary object oriented COBOL and each load module represents an object oriented class (for the most part). So a recompile of the entire application would require a testing/migration effort that is too arduous for the application team. However, if we can just change the statically compiled BA4C1426 program and relink it into the existing 11,000 load modules, it significantly reduces the scope of the change to something that is more manageable from a testing and migration effort. Thanks, Tim Zielke CICS/MQ Systems Programmer Aon Hewitt -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
JCL example to relink a CSECT into an existing load module
I sent the following to the CICS LISTSERV, and someone mentioned that the IBM-MAIN would be a better place for this type of inquiry. I did get some good JCL examples from the CICS LISTSERV, but if someone has some past experience of this working with specifically COBOL, that would be great. Some of these existing COBOL modules that will be relinked with the new BA4C1426 CSECT were compiled/linked under COBOL-II. We now use Enterprise COBOL 3.4 and the new BA4C1426 will be generated with Enterprise COBOL 3.4. Hello, We have 1000's of CICS COBOL programs that COPY in a COBOL source program called BA4C1426 and then statically call it. I have given some code examples of how this works below. In this example, COBOL program BA4C1976 does a COPY to bring in the COBOL source of BA4C1426 at compile time and then statically calls BA4C1426. Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. So for the example below, BA4C1976 would not be recompiled, but the binder step would be run to update the existing BA4C1976 load module with a new CSECT for BA4C1426. Would anyone have some examples of existing JCL of how to do the relink step of swapping in a new CSECT into an existing load module? I was going to research it, but was thinking someone on this list has already done it and would have an example already available. I didn't find any examples quickly with google searches. Here is an example of how a module like BA4C1976 references BA4C1426: Identification Division. * Object-Class PrsnDBPmtInstRef. Program-Id. BA4C1976. . . . Procedure Division using Self Client-Variables Global-Variables Arglist. . . . Call 'BA4C1426' Using DfhEiBlk DfhCommArea TV-023-PRSNDBPMTINSTRSLT-LS Client-Variables Global-Variables ParmList . . . COPY BA4C1426. End Program BA4C1976. The BA4C1426 source that is referenced by the COPY BA4C1426 line is a COBOL program: Identification Division. * Object-Class PARNLIST. Program-Id. BA4C1426. . . . COBOL source . . . End Program BA4C1426. Thanks, Tim Zielke Aon Hewit CICS/MQ Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
Tim, What wouldn't you want to compile and link the appropriate way ? Just curious here and not judging...what's the reasoning ? Maybe other methods ... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 8, 2012, at 11:57 AM, Tim Zielke tim.zie...@aonhewitt.com wrote: I sent the following to the CICS LISTSERV, and someone mentioned that the IBM-MAIN would be a better place for this type of inquiry. I did get some good JCL examples from the CICS LISTSERV, but if someone has some past experience of this working with specifically COBOL, that would be great. Some of these existing COBOL modules that will be relinked with the new BA4C1426 CSECT were compiled/linked under COBOL-II. We now use Enterprise COBOL 3.4 and the new BA4C1426 will be generated with Enterprise COBOL 3.4. Hello, We have 1000's of CICS COBOL programs that COPY in a COBOL source program called BA4C1426 and then statically call it. I have given some code examples of how this works below. In this example, COBOL program BA4C1976 does a COPY to bring in the COBOL source of BA4C1426 at compile time and then statically calls BA4C1426. Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. So for the example below, BA4C1976 would not be recompiled, but the binder step would be run to update the existing BA4C1976 load module with a new CSECT for BA4C1426. Would anyone have some examples of existing JCL of how to do the relink step of swapping in a new CSECT into an existing load module? I was going to research it, but was thinking someone on this list has already done it and would have an example already available. I didn't find any examples quickly with google searches. Here is an example of how a module like BA4C1976 references BA4C1426: Identification Division. * Object-Class PrsnDBPmtInstRef. Program-Id. BA4C1976. . . . Procedure Division using Self Client-Variables Global-Variables Arglist. . . . Call 'BA4C1426' Using DfhEiBlk DfhCommArea TV-023-PRSNDBPMTINSTRSLT-LS Client-Variables Global-Variables ParmList . . . COPY BA4C1426. End Program BA4C1976. The BA4C1426 source that is referenced by the COPY BA4C1426 line is a COBOL program: Identification Division. * Object-Class PARNLIST. Program-Id. BA4C1426. . . . COBOL source . . . End Program BA4C1426. Thanks, Tim Zielke Aon Hewit CICS/MQ Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
This would require a recompile of pretty much the entire application which is around 11,000 load modules. This COBOL application is written in proprietary object oriented COBOL and each load module represents an object oriented class (for the most part). So a recompile of the entire application would require a testing/migration effort that is too arduous for the application team. However, if we can just change the statically compiled BA4C1426 program and relink it into the existing 11,000 load modules, it significantly reduces the scope of the change to something that is more manageable from a testing and migration effort. Thanks, Tim Zielke CICS/MQ Systems Programmer Aon Hewitt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Thursday, March 08, 2012 11:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL example to relink a CSECT into an existing load module Tim, What wouldn't you want to compile and link the appropriate way ? Just curious here and not judging...what's the reasoning ? Maybe other methods ... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 8, 2012, at 11:57 AM, Tim Zielke tim.zie...@aonhewitt.com wrote: I sent the following to the CICS LISTSERV, and someone mentioned that the IBM-MAIN would be a better place for this type of inquiry. I did get some good JCL examples from the CICS LISTSERV, but if someone has some past experience of this working with specifically COBOL, that would be great. Some of these existing COBOL modules that will be relinked with the new BA4C1426 CSECT were compiled/linked under COBOL-II. We now use Enterprise COBOL 3.4 and the new BA4C1426 will be generated with Enterprise COBOL 3.4. Hello, We have 1000's of CICS COBOL programs that COPY in a COBOL source program called BA4C1426 and then statically call it. I have given some code examples of how this works below. In this example, COBOL program BA4C1976 does a COPY to bring in the COBOL source of BA4C1426 at compile time and then statically calls BA4C1426. Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. So for the example below, BA4C1976 would not be recompiled, but the binder step would be run to update the existing BA4C1976 load module with a new CSECT for BA4C1426. Would anyone have some examples of existing JCL of how to do the relink step of swapping in a new CSECT into an existing load module? I was going to research it, but was thinking someone on this list has already done it and would have an example already available. I didn't find any examples quickly with google searches. Here is an example of how a module like BA4C1976 references BA4C1426: Identification Division. * Object-Class PrsnDBPmtInstRef. Program-Id. BA4C1976. . . . Procedure Division using Self Client-Variables Global-Variables Arglist. . . . Call 'BA4C1426' Using DfhEiBlk DfhCommArea TV-023-PRSNDBPMTINSTRSLT-LS Client-Variables Global-Variables ParmList . . . COPY BA4C1426. End Program BA4C1976. The BA4C1426 source that is referenced by the COPY BA4C1426 line is a COBOL program: Identification Division. * Object-Class PARNLIST. Program-Id. BA4C1426. . . . COBOL source . . . End Program BA4C1426. Thanks, Tim Zielke Aon Hewit CICS/MQ Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
On 8 March 2012 11:57, Tim Zielke tim.zie...@aonhewitt.com wrote: Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. So for the example below, BA4C1976 would not be recompiled, but the binder step would be run to update the existing BA4C1976 load module with a new CSECT for BA4C1426. I may well be missing the real question, and I don't know COBOL or its potential intricacies, but it seems to me trivial to replace one CSECT in an existing load module. Essentially you want to INCLUDE the new module, INCLUDE the existing load module, and save the result. Something like //SYSLMOD DD DSN=main.loadlib //NEWMOD DD DSN=load.library.where.you.put.the.new.module //SYSLIN DD * INCLUDE NEWMOD(BA4C1426) INCLUDE SYSLMOD(BA4C1976) NAME BA4C1976(R) And that's it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
On the basis of the information provided, below, IMO, the only *SAFE* way to make this change is to recompile the entire application. Perhaps if you provided some additional info about BA4C1426, I might have some additional alternatives. Since you have go through the pain of a mass compile, I would make BA4C1426 a stand-alone module and dynamically call it. I understand that this might take some additional time to recoded for dynamic calls. As to the original request: 1) Compile BA4C1976 into a stand-alone csect and link into the special loadlib of your choice 2) Execute the following for each LOAD module currently existing //STEP1 exec pgm=hewl,parm=... //SYSPRINT DD SYSOUT=* //SYSLMOD DD DSN=(new loadmod library) //SYSLIB1 DD DSN=(original loadmod library) //SYSLIB DD DSN=( special loadmod library) //SYSIN DD * Include syslib(BA4C1426) Include syslib1(original loadmod name) Name original loadmod name(r) HTH, snip We have 1000's of CICS COBOL programs that COPY in a COBOL source program called BA4C1426 and then statically call it. I have given some code examples of how this works below. In this example, COBOL program BA4C1976 does a COPY to bring in the COBOL source of BA4C1426 at compile time and then statically calls BA4C1426. Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. So for the example below, BA4C1976 would not be recompiled, but the binder step would be run to update the existing BA4C1976 load module with a new CSECT for BA4C1426. Would anyone have some examples of existing JCL of how to do the relink step of swapping in a new CSECT into an existing load module? I was going to research it, but was thinking someone on this list has already done it and would have an example already available. I didn't find any examples quickly with google searches. Here is an example of how a module like BA4C1976 references BA4C1426: Identification Division. * Object-Class PrsnDBPmtInstRef. Program-Id. BA4C1976. . . . Procedure Division using Self Client-Variables Global-Variables Arglist. . . . Call 'BA4C1426' Using DfhEiBlk DfhCommArea TV-023-PRSNDBPMTINSTRSLT-LS Client-Variables Global-Variables ParmList . . . COPY BA4C1426. End Program BA4C1976. The BA4C1426 source that is referenced by the COPY BA4C1426 line is a COBOL program: Identification Division. * Object-Class PARNLIST. Program-Id. BA4C1426. . . . COBOL source . . . End Program BA4C1426. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
Tony, Yeah, I also thought. I am assuming, bad word, that the COBOL call will be resolved correctly Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 8, 2012, at 12:56 PM, Tony Harminc t...@harminc.net wrote: On 8 March 2012 11:57, Tim Zielke tim.zie...@aonhewitt.com wrote: Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. So for the example below, BA4C1976 would not be recompiled, but the binder step would be run to update the existing BA4C1976 load module with a new CSECT for BA4C1426. I may well be missing the real question, and I don't know COBOL or its potential intricacies, but it seems to me trivial to replace one CSECT in an existing load module. Essentially you want to INCLUDE the new module, INCLUDE the existing load module, and save the result. Something like //SYSLMOD DD DSN=main.loadlib //NEWMOD DD DSN=load.library.where.you.put.the.new.module //SYSLIN DD * INCLUDE NEWMOD(BA4C1426) INCLUDE SYSLMOD(BA4C1976) NAME BA4C1976(R) And that's it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
JCL example to relink a CSECT into an existing load module
Let me try to begin at the beginning. The scheme you used to produce the around 11,000 executables you want to modify was ill-chosen. There was no need to recompile the source text of program BA4C1426 around 11,000 times. Compiling it just once would have been enough. The object module produced by that single compilation could then have been link edited or bound into a convenient library specifying NCAL. Then, when your applications were compiled (WITHOUT including BA4C1426 in them) and subsequently linked or bound---with the library into which the NCAL load module for BA4C1426 was linked or bound made available to these other link or bind steps---the linkage editor or binder would have done the necessary automatically. Now as to your present situation, from circa 1965 forward the various linkage editors and now the binder have supported a REPLACE operation---It is also the delete operation; if you replace something with nothing, something is just deleted---that permits one CSECT to be replaced by another. Please post the linkage-editor [or binder] output for one of your old load modules. If it shows that BA4C1426 is a separate CSECT, a trivial relink or rebind operation with the same REPLACE statement for each of your around 11,000 applications will solve your problem, If not, not. (The ill-advised COPY operations may perhaps, depending upon when they were done, preclude this operation.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
On 8 Mar 2012 09:51:54 -0800, in bit.listserv.ibm-main you wrote: This would require a recompile of pretty much the entire application which is around 11,000 load modules. This COBOL application is written in proprietary object oriented COBOL and each load module represents an object oriented class (for the most part). So a recompile of the entire application would require a testing/migration effort that is too arduous for the application team. However, if we can just change the statically compiled BA4C1426 program and relink it into the existing 11,000 load modules, it significantly reduces the scope of the change to something that is more manageable from a testing and migration effort. Because of the way optimization works, BA4C1426 may not be a separate CSECT and may even be inline code with no actual CALL being issued. If you have a smart change management system that can trigger recompiles based on copybook changes, that is probably the way to go. The other choice is to scan the source library for all instances of COPY BA4C1426 and generate the compile jobs for these programs. Clark Morris Thanks, Tim Zielke CICS/MQ Systems Programmer Aon Hewitt -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Scott Ford Sent: Thursday, March 08, 2012 11:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JCL example to relink a CSECT into an existing load module Tim, What wouldn't you want to compile and link the appropriate way ? Just curious here and not judging...what's the reasoning ? Maybe other methods ... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Mar 8, 2012, at 11:57 AM, Tim Zielke tim.zie...@aonhewitt.com wrote: I sent the following to the CICS LISTSERV, and someone mentioned that the IBM-MAIN would be a better place for this type of inquiry. I did get some good JCL examples from the CICS LISTSERV, but if someone has some past experience of this working with specifically COBOL, that would be great. Some of these existing COBOL modules that will be relinked with the new BA4C1426 CSECT were compiled/linked under COBOL-II. We now use Enterprise COBOL 3.4 and the new BA4C1426 will be generated with Enterprise COBOL 3.4. Hello, We have 1000's of CICS COBOL programs that COPY in a COBOL source program called BA4C1426 and then statically call it. I have given some code examples of how this works below. In this example, COBOL program BA4C1976 does a COPY to bring in the COBOL source of BA4C1426 at compile time and then statically calls BA4C1426. Our application team would like to change just the BA4C1426 code and then relink the change into the existing modules. So for the example below, BA4C1976 would not be recompiled, but the binder step would be run to update the existing BA4C1976 load module with a new CSECT for BA4C1426. Would anyone have some examples of existing JCL of how to do the relink step of swapping in a new CSECT into an existing load module? I was going to research it, but was thinking someone on this list has already done it and would have an example already available. I didn't find any examples quickly with google searches. Here is an example of how a module like BA4C1976 references BA4C1426: Identification Division. * Object-Class PrsnDBPmtInstRef. Program-Id. BA4C1976. . . . Procedure Division using Self Client-Variables Global-Variables Arglist. . . . Call 'BA4C1426' Using DfhEiBlk DfhCommArea TV-023-PRSNDBPMTINSTRSLT-LS Client-Variables Global-Variables ParmList . . . COPY BA4C1426. End Program BA4C1976. The BA4C1426 source that is referenced by the COPY BA4C1426 line is a COBOL program: Identification Division. * Object-Class PARNLIST. Program-Id. BA4C1426. . . . COBOL source . . . End Program BA4C1426. Thanks, Tim Zielke Aon Hewit CICS/MQ Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
On Thu, 8 Mar 2012 12:56:32 -0500, Tony Harminc wrote: //SYSLMOD DD DSN=main.loadlib //NEWMOD DD DSN=load.library.where.you.put.the.new.module //SYSLIN DD * INCLUDE NEWMOD(BA4C1426) INCLUDE SYSLMOD(BA4C1976) NAME BA4C1976(R) In order for this to work correctly, an ENTRY statement is needed: //SYSLMOD DD DSN=main.loadlib //NEWMOD DD DSN=load.library.where.you.put.the.new.module //SYSLIN DD * INCLUDE NEWMOD(BA4C1426) INCLUDE SYSLMOD(BA4C1976) ENTRY BA4C1976 NAME BA4C1976(R) The binder will include the new BA4C1426 first, then the old BA4C1976. The old BA4C1976 contains a BA4C1426 CSECT, but since you have already included a CSECT by that name, the old BA4C1426 CSECT is not retained. The ENTRY statement is needed or the entry point for the new load module would be BA4C1426. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
The scheme Tom Marchant proposes is workable, but it is order-dependent in a way that I find disagreeable. I suggest the use of the REPLACE statement instead. Its syntax is | REPLACE oldsec(newsec) See pp. 63ff of z/Os MVS Program management: User's guide and reference, SA22-7643-10, which includes some COBOL examples. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
On Thu, 8 Mar 2012 14:01:03 -0600, Tom Marchant wrote: In order for this to work correctly, an ENTRY statement is needed: //SYSLMOD DD DSN=main.loadlib //NEWMOD DD DSN=load.library.where.you.put.the.new.module //SYSLIN DD * INCLUDE NEWMOD(BA4C1426) INCLUDE SYSLMOD(BA4C1976) ENTRY BA4C1976 NAME BA4C1976(R) Or not. I've never used it, but an alternative would seem to be: //SYSLMOD DD DSN=main.loadlib //NEWMOD DD DSN=load.library.where.you.put.the.new.module //SYSLIN DD * INCLUDE NEWMOD(BA4C1426) INCLUDE -ATTR SYSLMOD(BA4C1976) NAME BA4C1976(R) This kills many birds with one stone: AC, AMODE, DC, OL, REUS, RMODE, SSI, TEST, entry point, DYNAM, and MIGRATABLE. I suspect this option was introduced to support invocation of Binder by IEBCOPY. I expect a regular contributor to this forum to bristle at such a lazy shortcut. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
ASG-PRO/JCL
Does anyone have experience with ASG's JCL/XREF (PRO/JCL and INFO/X Enterprise)? ASG has presented a proposal to move us away from ASG-JCLPREP to PRO/JCL. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ASG-PRO/JCL
Hello, Contact me offline, if you will. I have lots of information for you about your query and can probably provide you with some alternatives that are more seamless. Mitch McCluhan, Legacy Modernization Consultant -Original Message- From: JT jethin...@aol.com To: IBM-MAIN IBM-MAIN@bama.ua.edu Sent: Thu, Mar 1, 2012 8:49 am Subject: ASG-PRO/JCL Does anyone have experience with ASG's JCL/XREF (PRO/JCL and INFO/X Enterprise)? ASG has presented a proposal to move us away from ASG-JCLPREP to PRO/JCL. -- or IBM-MAIN subscribe / signoff / archive access instructions, end email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tony Harminc Sent: Monday, February 27, 2012 7:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On 27 February 2012 15:12, McKown, John john.mck...@healthmarkets.com wrote: I need to learn how to use the STORAGE function to do chain chasing in REXX. I generally dislike this any more. I am becoming more of a GUPI programmer as I age. Or maybe I'm just too lazy anymore. Regardless, you're a positive anymore guy - the only one on this list that I've noticed. Native or learned? I had thought it carried a young demographic, but I see not particularly. Midwestern US, mostly, it seems. Tony H. Neither learned nor native. I just don't have the energy to argue any more. grin Three years of ill health have just made it not worth while. I save my argument energy for use on the Windows weenies. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Tony, This is a great idea...btw there are a buch of Midwesterners I think on this listserver, I am a Hoosier originally, just living in NJ lol for 30 yrs Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 27, 2012, at 6:35 PM, Tony Harminc t...@harminc.net wrote: On 27 February 2012 06:18, Thomas Berg thomas.b...@swedbank.se wrote: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Thirty years ago I would have said that it sounds like an ideal job for GPSAM (file 648 on the CBT site). You'd write a little access method that accepts a couple of DDNAMEs as arguments, and writes the output to both. Now I don't know if GPSAM has been updated for newer OS levels (the File 648 version is dated 1982), but conceptually and maybe even practically, it should still be fine on z/OS today. Preferably by JCL means. Um, well, once you write your little access method (all nice, unauthorized code, btw) and install GPSAM, it would all be by JCL means. It would look something like this: // EXEC PGM=yourprog //STEPLIB DD DSN=your.private.unauth.loadlib //SYSPRINT DD SUBSYS=(GPSM,DOUBLER,'COPY1,COPY2') //COPY1 DD SYSOUT=* //COPY2 DD DSN=dataset,DISP=...,etc. You just have to write the DOUBLER routine. Or make it as general as you like - TUPLER...? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
That's a bunch not buch Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 28, 2012, at 8:14 AM, Scott Ford scott_j_f...@yahoo.com wrote: Tony, This is a great idea...btw there are a buch of Midwesterners I think on this listserver, I am a Hoosier originally, just living in NJ lol for 30 yrs Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 27, 2012, at 6:35 PM, Tony Harminc t...@harminc.net wrote: On 27 February 2012 06:18, Thomas Berg thomas.b...@swedbank.se wrote: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Thirty years ago I would have said that it sounds like an ideal job for GPSAM (file 648 on the CBT site). You'd write a little access method that accepts a couple of DDNAMEs as arguments, and writes the output to both. Now I don't know if GPSAM has been updated for newer OS levels (the File 648 version is dated 1982), but conceptually and maybe even practically, it should still be fine on z/OS today. Preferably by JCL means. Um, well, once you write your little access method (all nice, unauthorized code, btw) and install GPSAM, it would all be by JCL means. It would look something like this: // EXEC PGM=yourprog //STEPLIB DD DSN=your.private.unauth.loadlib //SYSPRINT DD SUBSYS=(GPSM,DOUBLER,'COPY1,COPY2') //COPY1 DD SYSOUT=* //COPY2 DD DSN=dataset,DISP=...,etc. You just have to write the DOUBLER routine. Or make it as general as you like - TUPLER...? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On Mon, 27 Feb 2012 17:35:39 -0600, Kirk Wolf k...@dovetail.com wrote: So, I found that it is actually tricky to get the current jobid using REXX in a WLM-initiated environment. Here's a slightly patched REXX script that I found by Bill Lalonde that will do it: /* REXX */ /* curjobid.rexx (adapted from http://billlalonde.tripod.com/rexx/findjsab.txt ) */ ... Works in TSO and shell. And it's a great site -- I'll bookmark it alongside PlanetMVS and CBTTape. Do you feel left out of John G.'s CABAL? Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 02/27/2012 at 10:20 AM, McKown, John john.mck...@healthmarkets.com said: I know how to write code to get it, Why is that not acceptable? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, February 28, 2012 9:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 02/27/2012 at 10:20 AM, McKown, John john.mck...@healthmarkets.com said: I know how to write code to get it, Why is that not acceptable? -- Shmuel (Seymour J.) Metz, SysProg and JOAT It works for me, but does not help the OP because he won't have my code. And, in some cases, I've been told that some shops can only use either in-house developed code or, in extremis, only vendor supplied code, no freeware or unsupported code allowed. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 02/27/2012 at 02:12 PM, McKown, John john.mck...@healthmarkets.com said: I need to learn how to use the STORAGE function to do chain chasing in REXX. Or to write Rexx-callable routines in HLA. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
In 231f0103-e497-46e1-86bb-c2ccd6ebc...@yahoo.com, on 02/28/2012 at 08:14 AM, Scott Ford scott_j_f...@yahoo.com said: This is a great idea...btw there are a buch of Midwesterners I think on this listserver, I am a Hoosier originally, just living in NJ lol for 30 yrs I know of no reason that GPSAM wouldn't work in a current z/OS system. Michigander in exile, just inside the Capital Beltway. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
In CAHm_n2=7u1del2+9s0zlmtkdz9sqp7cbrp11uyib7fgw0ow...@mail.gmail.com, on 02/27/2012 at 05:35 PM, Kirk Wolf k...@dovetail.com said: Here's a slightly patched REXX script that I found by Bill Lalonde that will do it: That looks overly complicated. Why not just pull it from the SSIB? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On Tue, Feb 28, 2012 at 10:31 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In CAHm_n2=7u1del2+9s0zlmtkdz9sqp7cbrp11uyib7fgw0ow...@mail.gmail.com, on 02/27/2012 at 05:35 PM, Kirk Wolf k...@dovetail.com said: Here's a slightly patched REXX script that I found by Bill Lalonde that will do it: That looks overly complicated. Why not just pull it from the SSIB? Someone else may know the details, but I have found that SSIBJBID is blank for WLM-initiated jobs. Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On Tue, Feb 28, 2012 at 9:25 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Mon, 27 Feb 2012 17:35:39 -0600, Kirk Wolf k...@dovetail.com wrote: ... Do you feel left out of John G.'s CABAL? Gil, If you are referring to John G's recent post: Still, their UNIX-oriented initiatives are a clear danger to legitimate, MVS-based undertakings; and some of the hybrid schemes they have urged are flagrantly subversive of good order. then, I would like to say absolutely: I'M IN (were the CABAL not so secretive :-). One might assume then that we are still two short of John G's phony 5-member benchmark, but this is not true. Hopefully, it will be more of a bandwagon than a CABAL :-) Kirk Wolf Dovetailed Technologies http://dovetail.com PS A secret weapon for subversive MVS-Unix hybrid batch jobs: http://dovetail.com/products/coz.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
And stupid me thought he just couldn't spell COBOL. sigh Penguinista and proud! Yes, I a member of FSF. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Tuesday, February 28, 2012 10:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On Tue, Feb 28, 2012 at 9:25 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Mon, 27 Feb 2012 17:35:39 -0600, Kirk Wolf k...@dovetail.com wrote: ... Do you feel left out of John G.'s CABAL? Gil, If you are referring to John G's recent post: Still, their UNIX-oriented initiatives are a clear danger to legitimate, MVS-based undertakings; and some of the hybrid schemes they have urged are flagrantly subversive of good order. then, I would like to say absolutely: I'M IN (were the CABAL not so secretive :-). One might assume then that we are still two short of John G's phony 5-member benchmark, but this is not true. Hopefully, it will be more of a bandwagon than a CABAL :-) Kirk Wolf Dovetailed Technologies http://dovetail.com PS A secret weapon for subversive MVS-Unix hybrid batch jobs: http://dovetail.com/products/coz.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On Tue, 28 Feb 2012 11:31:16 -0500, Shmuel Metz (Seymour J.) wrote:
That looks overly complicated. Why not just pull it from the SSIB?
Someone shared such an example with me. It worked under TSO;
not under z/OS UNIX. I was then asked (on TSO-REXX), Why don't
you just run it under TSO, then?
Kind of like:
The heater in my car doesn't work.
Move to a warmer climate, then.
The following kludge works in both TSO and UNIX:
/* Rexx */ signal on novalue; /*
Doc: function JOBID() returns current Job ID.
*/
RC = BPXWDYN( 'alloc rtddn(DD) rtdsn(DSN) sysout msg(WTP)' )
RC = BPXWDYN( 'freedd('DD') msg(WTP)' )
parse value DSN with . '.' . '.' Job '.' .
return( Job )
I'm not proud,
gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Thomas, This is what I do to capture *any line range* from a SYSOUT being currently populated: //SDSFBTCH EXEC PGM=SDSF //ISFOUT DD SYSOUT=* //PRINTFL DD SYSOUT=*,DCB=RECFM=VB [or point to a FILE] //ISFINDD * PRE job-name OWNER ST FIND job-name ++? FIND dd-name for SYSOUT ++S PRINT FILE PRINTFL PRINT from-line-number to-line-number /* // HTH, -Victor- = Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
What happens if there are multiple jobs with the same name? We have that problem all the time. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Victor Gil Sent: Tuesday, February 28, 2012 1:27 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) Thomas, This is what I do to capture *any line range* from a SYSOUT being currently populated: //SDSFBTCH EXEC PGM=SDSF //ISFOUT DD SYSOUT=* //PRINTFL DD SYSOUT=*,DCB=RECFM=VB [or point to a FILE] //ISFINDD * PRE job-name OWNER ST FIND job-name ++? FIND dd-name for SYSOUT ++S PRINT FILE PRINTFL PRINT from-line-number to-line-number /* // HTH, -Victor- = Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
In a6b9336cdb62bb46b9f8708e686a7ea00e924b3...@nrhmms8p02.uicnrh.dom, on 02/28/2012 at 10:57 AM, McKown, John john.mck...@healthmarkets.com said: And stupid me thought he just couldn't spell COBOL. What's the Usenet COBOL? -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Thanks! Interesting variant of SDSF access. I'm so used with the rexx interface that I haven't thought of the more direct way. (I got the rexx way to work thanks to an example by Miklos Szigetvari.) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Victor Gil Skickat: den 28 februari 2012 20:27 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) Thomas, This is what I do to capture *any line range* from a SYSOUT being currently populated: //SDSFBTCH EXEC PGM=SDSF //ISFOUT DD SYSOUT=* //PRINTFL DD SYSOUT=*,DCB=RECFM=VB [or point to a FILE] //ISFINDD * PRE job-name OWNER ST FIND job-name ++? FIND dd-name for SYSOUT ++S PRINT FILE PRINTFL PRINT from-line-number to-line-number /* // HTH, -Victor- = Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
YES!. Define multiple output statements //out1 output. //out2 output... And refer to them //sysprint dd output=(*.out1,*.out2) HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Staller, Allan allan.stal...@kbmg.com wrote in message news:45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc... YES!. Define multiple output statements //out1 output. //out2 output... And refer to them //sysprint dd output=(*.out1,*.out2) HTH, That is what I thought first, but I think he wants it to both sysout and a dataset. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. I do a similar process, I write the SYSOUT to a dataset, then pass it to IEBGENER step to put it back to the JOB. Then I can use the SYSOUT DSN that was created for inspection later. I do not know of a process in JES that would create both a DSN and SYSOUT at the same time. If you have control over the program, then you could create 2 DCBs - one for SYSOUT and one for a DSN. Unfortunately I do not think that is what you want to do. And I know of no mechanism in JES that will do this. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
AFAIK, this will not work with a dataset. snip YES!. Define multiple output statements //out1 output. //out2 output... And refer to them //sysprint dd output=(*.out1,*.out2) HTH, That is what I thought first, but I think he wants it to both sysout and a dataset. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
That's right. I'm about to process DB2 REBIND en masse and need to see in realtime that it executes ok (if in error it needs to be stopped) and at the same time save it for processing in a later step. As the execution can take 30 minutes I don't want to wait until end. (Using the DSN command under IKJEFT01.) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Vernooij, CP - SPLXM Skickat: den 27 februari 2012 14:44 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) Staller, Allan allan.stal...@kbmg.com wrote in message news:45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc... YES!. Define multiple output statements //out1 output. //out2 output... And refer to them //sysprint dd output=(*.out1,*.out2) HTH, That is what I thought first, but I think he wants it to both sysout and a dataset. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On 2/27/2012 4:18 AM, Thomas Berg wrote: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK If you want to 'follow the execution by inspecting the output' and 'in realtime', I gather you don't want an automated process. Why not just go to SDSF (or (E)JES or IOF or Flasher or ... ) and select the sysout file? It will show you what's been output so far, but does not disturb the final distribution. You can set up an automated, timed refresh of the screen (say, every 5 seconds) to watch the SYSOUT data grow, or just hit enter to see the latest entries. Or maybe I'm not clear on what you are after. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Steve Comstock Skickat: den 27 februari 2012 14:58 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On 2/27/2012 4:18 AM, Thomas Berg wrote: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK If you want to 'follow the execution by inspecting the output' and 'in realtime', I gather you don't want an automated process. Why not just go to SDSF (or (E)JES or IOF or Flasher or ... ) and select the sysout file? It will show you what's been output so far, but does not disturb the final distribution. You can set up an automated, timed refresh of the screen (say, every 5 seconds) to watch the SYSOUT data grow, or just hit enter to see the latest entries. Or maybe I'm not clear on what you are after. The output needs to be processed in a later step. But if the output is directed to SYSOUT, are there any way for a later step to read that output ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
That's right. I'm about to process DB2 REBIND en masse and need to see in realtime that it executes ok (if in error it needs to be stopped) and at the same time save it for processing in a later step. As the execution can take 30 minutes I don't want to wait until end. (Using the DSN command under IKJEFT01.) Then why not put a REXX around it and then inspect the SQL as it is produced? You can use a REXX to invoke the DSNREXX or use DSN natively. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On 2/27/2012 7:01 AM, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Steve Comstock Skickat: den 27 februari 2012 14:58 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On 2/27/2012 4:18 AM, Thomas Berg wrote: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK If you want to 'follow the execution by inspecting the output' and 'in realtime', I gather you don't want an automated process. Why not just go to SDSF (or (E)JES or IOF or Flasher or ... ) and select the sysout file? It will show you what's been output so far, but does not disturb the final distribution. You can set up an automated, timed refresh of the screen (say, every 5 seconds) to watch the SYSOUT data grow, or just hit enter to see the latest entries. Or maybe I'm not clear on what you are after. The output needs to be processed in a later step. But if the output is directed to SYSOUT, are there any way for a later step to read that output ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK Ah! So the output is not originally SYSOUT? Can you direct the output to a z/OS UNIX file? Then from a UNIX session (omvs or telnet) you could use 'tail' commands to watch the file grow. If things are not going well, cancel the job. If all goes well, copy the UNIX file back to an MVS file (or just process the UNIX file if that would be supported). -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 27 februari 2012 15:06 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) That's right. I'm about to process DB2 REBIND en masse and need to see in realtime that it executes ok (if in error it needs to be stopped) and at the same time save it for processing in a later step. As the execution can take 30 minutes I don't want to wait until end. (Using the DSN command under IKJEFT01.) Then why not put a REXX around it and then inspect the SQL as it is produced? You can use a REXX to invoke the DSNREXX or use DSN natively. I'm worried about performance. As it is now I'm feeding one invocation of DSN with 25000 REBIND's. If I do a new invoke of DSN for every (or every 10:th) REBIND it will prolong the execution (I think, haven't tested). My experience of DSNREXX is that performance is not one of its points... What I'm doing is to manually run a package cleaning routine for future automatic execution. So I want to have a close control of what's happening now in the beginning. Maybe I should go back to the drawing board... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Hi I used to say : With the SDSF REXX interface you can process the output in the next STEP, but lately we have tested this again, and got some error codes during processing the own job. (i.e sfmsg is:JCT NOT AVAILABLE ) Anyhow if you submit a job to process the JES output from the previous job, it would work, even if the job is still ruing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Steve Comstock Skickat: den 27 februari 2012 15:13 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On 2/27/2012 7:01 AM, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Steve Comstock Skickat: den 27 februari 2012 14:58 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On 2/27/2012 4:18 AM, Thomas Berg wrote: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK If you want to 'follow the execution by inspecting the output' and 'in realtime', I gather you don't want an automated process. Why not just go to SDSF (or (E)JES or IOF or Flasher or ... ) and select the sysout file? It will show you what's been output so far, but does not disturb the final distribution. You can set up an automated, timed refresh of the screen (say, every 5 seconds) to watch the SYSOUT data grow, or just hit enter to see the latest entries. Or maybe I'm not clear on what you are after. The output needs to be processed in a later step. But if the output is directed to SYSOUT, are there any way for a later step to read that output ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK Ah! So the output is not originally SYSOUT? Can you direct the output to a z/OS UNIX file? Then from a UNIX session (omvs or telnet) you could use 'tail' commands to watch the file grow. If things are not going well, cancel the job. If all goes well, copy the UNIX file back to an MVS file (or just process the UNIX file if that would be supported). Well, I suppose that's a good idea. But here I'm out on unchartered territories. :) Although *NIX land is not totally unknown for me I haven't used the z/OS variant much. Maybe it's a time for me to explore it... But as this routine will go into automated production in future I prefer MVS proper (as I don't want to change the job to much between the manual period and the automated production. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Regarding even if the job is still running, is that true ? When I tried that last time I couldn't get hold of the output as long as the job was running. Exactly how do You do that ? (E g which ISF-commands etc.) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Miklos Szigetvari Skickat: den 27 februari 2012 15:52 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) Hi I used to say : With the SDSF REXX interface you can process the output in the next STEP, but lately we have tested this again, and got some error codes during processing the own job. (i.e sfmsg is:JCT NOT AVAILABLE ) Anyhow if you submit a job to process the JES output from the previous job, it would work, even if the job is still ruing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On 2/27/2012 9:01 AM, Thomas Berg wrote: The output needs to be processed in a later step. But if the output is directed to SYSOUT, are there any way for a later step to read that output ? Regards, Thomas Berg We use IOF, which allows a REXX EXEC in a later step to read the SYSOUT sent to a DD card in an earlier step. I would hope that rival products can do the same thing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Hi
This is more or less a sample from the REXX SDSF book .
/* REXX
*/ .
/* trace ?i
*/ .
/* accesses sdsf ST panel, thn list the column variables
*/ .
/* This is an example taken from SDSF bookshelf
*/ .
arg jobname
ddname .
Say
'jobname:'jobname
.
Say
'ddname:'ddname
.
rc=isfcalls('ON')
.
/* access the ST panel
*/.
/* Address SDSF ISFEXEC ST
*/ .
/* access the DA panel
*/.
Address SDSF ISFEXEC INPUT
ON .
Say '1.
rc:'rc .
Address SDSF ISFEXEC
DA.
Say '2.
rc:'rc .
lrc=rc
.
if
lrc0
.
then
do
.
call
msgrtn.
exit
20.
end
.
/* Loop for all running SYSLOG jobs
*/ .
do ix=1 to
JNAME.0 .
/*
.
Say
'JNAME.'ix':'JNAME.ix
.
Say
'TOKEN.'ix':'TOKEN.ix
.
*/
.
found = 1 /* if 1, then found
*/ .
if JNAME.ix jobname
then.
found =
0.
if found
0 .
then
do.
Say
'JNAME.'ix':'JNAME.ix.
Say
'STEPN.'ix':'STEPN.ix.
Say
'TOKEN.'ix':'TOKEN.ix.
/* Issue the ? (JDS) action agains the
*/.
/* row to list the data sets in the job
*/ .
Address SDSF ISFACT DA TOKEN('TOKEN.ix') PARM(NP ?)
,.
( prefix
jds_.
lrc=rc
.
Say 'aha
lrc:'lrc.
if
lrc0.
then
do .
call
msgrtn.
exit
20.
end
.
/* Find the JESMSGLG data set and allocate it
*/ .
/* using the SA action character
*/ .
endindex =
jds_DDNAME.0 .
On 2/27/2012 4:03 PM, Thomas Berg wrote:
Regarding even if the job is still running, is that true ? When I tried that
last time I couldn't get hold of the output as long as the job was running.
Exactly how do You do that ? (E g which ISF-commands etc.)
Regards,
Thomas Berg
_
Thomas Berg Specialist A M SWEDBANK
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
Miklos Szigetvari
Skickat: den 27 februari 2012 15:52
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: Duplicating SYSOUT output to another DD/DSN in realtime ?
(JCL)
Hi
I used to say : With the SDSF REXX interface you can process the
output in the next STEP, but lately we have tested
SV: SV: SV: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Well that's what I did (IIRC), but I didn't get the ds, I think I got an in
use msg when doing the SA.
But if You can get this to work so must I be able to do. Will maybe try it
again.
Regards,
Thomas Berg
_
Thomas Berg Specialist A M SWEDBANK
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
Miklos Szigetvari
Skickat: den 27 februari 2012 16:19
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: SV: Duplicating SYSOUT output to another DD/DSN in realtime
? (JCL)
Hi
This is more or less a sample from the REXX SDSF book .
/* REXX
*/ .
/* trace ?i
*/ .
/* accesses sdsf ST panel, thn list the column variables
*/ .
/* This is an example taken from SDSF bookshelf
*/ .
arg jobname
ddname .
Say
'jobname:'jobname
.
Say
'ddname:'ddname
.
rc=isfcalls('ON')
.
/* access the ST panel
*/.
/* Address SDSF ISFEXEC ST
*/ .
/* access the DA panel
*/.
Address SDSF ISFEXEC INPUT
ON .
Say '1.
rc:'rc .
Address SDSF ISFEXEC
DA.
Say '2.
rc:'rc .
lrc=rc
.
if
lrc0
.
then
do
.
call
msgrtn
.
exit
20
.
end
.
/* Loop for all running SYSLOG jobs
*/ .
do ix=1 to
JNAME.0 .
/*
.
Say
'JNAME.'ix':'JNAME.ix
.
Say
'TOKEN.'ix':'TOKEN.ix
.
*/
.
found = 1 /* if 1, then found
*/ .
if JNAME.ix jobname
then.
found =
0.
if found
0 .
then
do
.
Say
'JNAME.'ix':'JNAME.ix.
Say
'STEPN.'ix':'STEPN.ix.
Say
'TOKEN.'ix':'TOKEN.ix.
/* Issue the ? (JDS) action agains the
*/.
/* row to list the data sets in the job
*/ .
Address SDSF ISFACT DA TOKEN('TOKEN.ix') PARM(NP ?)
,.
( prefix
jds_.
lrc=rc
.
Say 'aha
lrc:'lrc.
if
lrc0
.
then
do .
call
msgrtn.
exit
20.
end
.
/* Find the JESMSGLG data set and allocate it
*/ .
/* using the SA action character
*/ .
endindex =
jds_DDNAME.0 .
On 2/27/2012 4:03 PM, Thomas Berg wrote:
Regarding even if the job is still running, is that true ? When I
tried that last time I couldn't get hold of the output as long as the job
was running.
Exactly how do You do that ? (E g which ISF-commands etc.)
Regards,
Thomas Berg
_
Thomas Berg Specialist A M SWEDBANK
-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För
Miklos Szigetvari
Skickat: den 27 februari 2012 15:52
Till: IBM-MAIN@bama.ua.edu
Ämne: Re: SV: Duplicating SYSOUT output to another DD/DSN in realtime ?
(JCL)
Hi
I used to say : With the SDSF REXX interface you can process the
output in the next STEP, but lately we have tested this again, and got
some
error codes during processing the own job. (i.e sfmsg is:JCT NOT
AVAILABLE )
Anyhow if you submit a job to process the JES output from the previous
job, it would work, even if the job is still ruing.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, February 27, 2012 5:19 AM To: IBM-MAIN@bama.ua.edu Subject: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Preferably by JCL means. Regards, Thomas Berg Of course, change your program to write the record once to each DD. Oh, you want a system level function to do it for you? You didn't say that! grin To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. However, there is a possible work around, if you are open to new functionality and are writing TEXT data (no binary garbage). Instead of writing to a sequential output dataset, allocate a UNIX file to your output DD. //ddname DD PATH='/some/path/file', // FILEDATA=TEXT,PATHOPTS=(OWRONLY,OCREAT,OTRUNC), // PATHDISP=(KEEP,KEEP), // PATHMODE=(SIRWXU,SIRGRP,SIROTH), // RECFM=??,LRECL=??,BLKSIZE=?? Now, the OWRONLY says output. OCREAT says create it if it doesn't exist, but reuse it if it already exists. OTRUNC says to truncate the existing records (like VSAM REUSE) if the file already exists. In the reading step, replace those three with a single ORDONLY to indicate read. You can use IEBGENER to copy the data to a sequential dataset, if you need to. The plus is that z/OS does not do enqueues on UNIX file names like it does on sequential datasets. So you can browse the file using ISPF if you want to. If you are a UNIX shell user, you can use the tail command with the -f option. This makes the tail command follow the file and print new records to your UNIX shell every two seconds. I havent' tried this, but if might be possible to create the dataset in a separate job, and then write to it in this job with a DISP=SHR. You could then browse the dataset as the job runs. Don't know when or if this will hit the list. We're having Internet connectivity problems right now. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On Mon, 27 Feb 2012 08:02:36 -0600, McKown, John wrote: To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. With a Rube Goldberg Rexx wrapper you could use tee, possibly under a BPXWUNIX task to write to SYSOUT and a data set concurrently. It might be more within your skill set to add an intervening step to use the Rexx SDSF interface to copy the SYSOUT from a previous step to a data set. In fact, at one point the Rexx SDSF interface allocates a DDNAME to the spool file -- you might be able to LINKMVS your postprocessor passing that DDNAME ln the alternate DDNAME list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
I was trying to write up a way to do something like that: fetching the sysout from the currently running job into a disk dataset in a later step. But ran into a problem in trying to find an IBM-supplied way to get the running job's JES job number. I know how to write code to get it, but I can't find a TSO or UNIX program to do it for me. I could then use Dovetail Technologies' Data Set Pipes to get the sysout into a disk dataset (fromdsn -jes.j.stepname.procstep.ddname | todsn //DD:ddname) in a subsequent step. But I got frustrated in trying to find the current JES job number. I would guess that somebody could use the SDSF/REXX interface to do it. But I still don't see how to get the jobname/jobnumber which I need. Using standard IBM programs, that is. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 10:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On Mon, 27 Feb 2012 08:02:36 -0600, McKown, John wrote: To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. With a Rube Goldberg Rexx wrapper you could use tee, possibly under a BPXWUNIX task to write to SYSOUT and a data set concurrently. It might be more within your skill set to add an intervening step to use the Rexx SDSF interface to copy the SYSOUT from a previous step to a data set. In fact, at one point the Rexx SDSF interface allocates a DDNAME to the spool file -- you might be able to LINKMVS your postprocessor passing that DDNAME ln the alternate DDNAME list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On Mon, 27 Feb 2012 10:20:34 -0600, McKown, John wrote: I was trying to write up a way to do something like that: fetching the sysout from the currently running job into a disk dataset in a later step. But ran into a problem in trying to find an IBM-supplied way to get the running job's JES job number. Hmmm... Allocate a temporary data set. Use BPXWDYN( 'info dd(...) inrtdsn(X)' ) and PARSE the job name out of X? How many Rube Goldbergs in a day am I allowed? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
In a90e503c23f97441b05ee302853b0e626401626...@fspas01ev010.fspa.myntet.se, on 02/27/2012 at 12:18 PM, Thomas Berg thomas.b...@swedbank.se said: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? For Unix applications there's the tee command. I'm not sure whether it is included in z/OS or ported tools. -- 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...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
How about a simple REXX unix script that uses STORAGE to grab the jobid out of the SSIB? Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Feb 27, 2012 at 10:20 AM, McKown, John john.mck...@healthmarkets.com wrote: I was trying to write up a way to do something like that: fetching the sysout from the currently running job into a disk dataset in a later step. But ran into a problem in trying to find an IBM-supplied way to get the running job's JES job number. I know how to write code to get it, but I can't find a TSO or UNIX program to do it for me. I could then use Dovetail Technologies' Data Set Pipes to get the sysout into a disk dataset (fromdsn -jes.j.stepname.procstep.ddname | todsn //DD:ddname) in a subsequent step. But I got frustrated in trying to find the current JES job number. I would guess that somebody could use the SDSF/REXX interface to do it. But I still don't see how to get the jobname/jobnumber which I need. Using standard IBM programs, that is. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 10:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On Mon, 27 Feb 2012 08:02:36 -0600, McKown, John wrote: To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. With a Rube Goldberg Rexx wrapper you could use tee, possibly under a BPXWUNIX task to write to SYSOUT and a data set concurrently. It might be more within your skill set to add an intervening step to use the Rexx SDSF interface to copy the SYSOUT from a previous step to a data set. In fact, at one point the Rexx SDSF interface allocates a DDNAME to the spool file -- you might be able to LINKMVS your postprocessor passing that DDNAME ln the alternate DDNAME list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
I need to learn how to use the STORAGE function to do chain chasing in REXX. I generally dislike this any more. I am becoming more of a GUPI programmer as I age. Or maybe I'm just too lazy anymore. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Monday, February 27, 2012 2:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) How about a simple REXX unix script that uses STORAGE to grab the jobid out of the SSIB? Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Feb 27, 2012 at 10:20 AM, McKown, John john.mck...@healthmarkets.com wrote: I was trying to write up a way to do something like that: fetching the sysout from the currently running job into a disk dataset in a later step. But ran into a problem in trying to find an IBM-supplied way to get the running job's JES job number. I know how to write code to get it, but I can't find a TSO or UNIX program to do it for me. I could then use Dovetail Technologies' Data Set Pipes to get the sysout into a disk dataset (fromdsn -jes.j.stepname.procstep.ddname | todsn //DD:ddname) in a subsequent step. But I got frustrated in trying to find the current JES job number. I would guess that somebody could use the SDSF/REXX interface to do it. But I still don't see how to get the jobname/jobnumber which I need. Using standard IBM programs, that is. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 10:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On Mon, 27 Feb 2012 08:02:36 -0600, McKown, John wrote: To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. With a Rube Goldberg Rexx wrapper you could use tee, possibly under a BPXWUNIX task to write to SYSOUT and a data set concurrently. It might be more within your skill set to add an intervening step to use the Rexx SDSF interface to copy the SYSOUT from a previous step to a data set. In fact, at one point the Rexx SDSF interface allocates a DDNAME to the spool file -- you might be able to LINKMVS your postprocessor passing that DDNAME ln the alternate DDNAME list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
This seems to work: /* REXX */ NUMERIC DIGITS 24 ; CVTPTR=STORAGE(10,4) /*CVT*/ TCBW=STORAGE(D2X(C2D(CVTPTR)),4) TCB=STORAGE(D2X(C2D(TCBW)+4),4) TIOT=STORAGE(D2X(C2D(TCB)+12),4) JBID=STORAGE(D2X(C2D(TIOT)),8) JBID=STRIP(JBID) SAY JBID On Mon, Feb 27, 2012 at 2:04 PM, Kirk Wolf k...@dovetail.com wrote: How about a simple REXX unix script that uses STORAGE to grab the jobid out of the SSIB? Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Feb 27, 2012 at 10:20 AM, McKown, John john.mck...@healthmarkets.com wrote: I was trying to write up a way to do something like that: fetching the sysout from the currently running job into a disk dataset in a later step. But ran into a problem in trying to find an IBM-supplied way to get the running job's JES job number. I know how to write code to get it, but I can't find a TSO or UNIX program to do it for me. I could then use Dovetail Technologies' Data Set Pipes to get the sysout into a disk dataset (fromdsn -jes.j.stepname.procstep.ddname | todsn //DD:ddname) in a subsequent step. But I got frustrated in trying to find the current JES job number. I would guess that somebody could use the SDSF/REXX interface to do it. But I still don't see how to get the jobname/jobnumber which I need. Using standard IBM programs, that is. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 10:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On Mon, 27 Feb 2012 08:02:36 -0600, McKown, John wrote: To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. With a Rube Goldberg Rexx wrapper you could use tee, possibly under a BPXWUNIX task to write to SYSOUT and a data set concurrently. It might be more within your skill set to add an intervening step to use the Rexx SDSF interface to copy the SYSOUT from a previous step to a data set. In fact, at one point the Rexx SDSF interface allocates a DDNAME to the spool file -- you might be able to LINKMVS your postprocessor passing that DDNAME ln the alternate DDNAME list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Thanks! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Monday, February 27, 2012 2:15 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) This seems to work: /* REXX */ NUMERIC DIGITS 24 ; CVTPTR=STORAGE(10,4) /*CVT*/ TCBW=STORAGE(D2X(C2D(CVTPTR)),4) TCB=STORAGE(D2X(C2D(TCBW)+4),4) TIOT=STORAGE(D2X(C2D(TCB)+12),4) JBID=STORAGE(D2X(C2D(TIOT)),8) JBID=STRIP(JBID) SAY JBID On Mon, Feb 27, 2012 at 2:04 PM, Kirk Wolf k...@dovetail.com wrote: How about a simple REXX unix script that uses STORAGE to grab the jobid out of the SSIB? Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Feb 27, 2012 at 10:20 AM, McKown, John john.mck...@healthmarkets.com wrote: I was trying to write up a way to do something like that: fetching the sysout from the currently running job into a disk dataset in a later step. But ran into a problem in trying to find an IBM-supplied way to get the running job's JES job number. I know how to write code to get it, but I can't find a TSO or UNIX program to do it for me. I could then use Dovetail Technologies' Data Set Pipes to get the sysout into a disk dataset (fromdsn -jes.j.stepname.procstep.ddname | todsn //DD:ddname) in a subsequent step. But I got frustrated in trying to find the current JES job number. I would guess that somebody could use the SDSF/REXX interface to do it. But I still don't see how to get the jobname/jobnumber which I need. Using standard IBM programs, that is. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 10:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On Mon, 27 Feb 2012 08:02:36 -0600, McKown, John wrote: To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. With a Rube Goldberg Rexx wrapper you could use tee, possibly under a BPXWUNIX task to write to SYSOUT and a data set concurrently. It might be more within your skill set to add an intervening step to use the Rexx SDSF interface to copy the SYSOUT from a previous step to a data set. In fact, at one point the Rexx SDSF interface allocates a DDNAME to the spool file -- you might be able to LINKMVS your postprocessor passing that DDNAME ln the alternate DDNAME list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
Duh. This prints the jobname, not the jobid. But you get the idea :-) On Mon, Feb 27, 2012 at 2:15 PM, Kirk Wolf k...@dovetail.com wrote: This seems to work: /* REXX */ NUMERIC DIGITS 24 ; CVTPTR=STORAGE(10,4) /*CVT*/ TCBW=STORAGE(D2X(C2D(CVTPTR)),4) TCB=STORAGE(D2X(C2D(TCBW)+4),4) TIOT=STORAGE(D2X(C2D(TCB)+12),4) JBID=STORAGE(D2X(C2D(TIOT)),8) JBID=STRIP(JBID) SAY JBID On Mon, Feb 27, 2012 at 2:04 PM, Kirk Wolf k...@dovetail.com wrote: How about a simple REXX unix script that uses STORAGE to grab the jobid out of the SSIB? Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Feb 27, 2012 at 10:20 AM, McKown, John john.mck...@healthmarkets.com wrote: I was trying to write up a way to do something like that: fetching the sysout from the currently running job into a disk dataset in a later step. But ran into a problem in trying to find an IBM-supplied way to get the running job's JES job number. I know how to write code to get it, but I can't find a TSO or UNIX program to do it for me. I could then use Dovetail Technologies' Data Set Pipes to get the sysout into a disk dataset (fromdsn -jes.j.stepname.procstep.ddname | todsn //DD:ddname) in a subsequent step. But I got frustrated in trying to find the current JES job number. I would guess that somebody could use the SDSF/REXX interface to do it. But I still don't see how to get the jobname/jobnumber which I need. Using standard IBM programs, that is. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, February 27, 2012 10:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL) On Mon, 27 Feb 2012 08:02:36 -0600, McKown, John wrote: To the best of my knowledge, z/OS does not come with this functionality. You basically want the equivalent of the UNIX tee command. With a Rube Goldberg Rexx wrapper you could use tee, possibly under a BPXWUNIX task to write to SYSOUT and a data set concurrently. It might be more within your skill set to add an intervening step to use the Rexx SDSF interface to copy the SYSOUT from a previous step to a data set. In fact, at one point the Rexx SDSF interface allocates a DDNAME to the spool file -- you might be able to LINKMVS your postprocessor passing that DDNAME ln the alternate DDNAME list. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On 27 February 2012 06:18, Thomas Berg thomas.b...@swedbank.se wrote: Is there any possibility to duplicate the output to SYSOUT to another Ddname/DSname in realtime ? I want to follow the execution by inspecting the output but at the same time save it for processing in a following step. Thirty years ago I would have said that it sounds like an ideal job for GPSAM (file 648 on the CBT site). You'd write a little access method that accepts a couple of DDNAMEs as arguments, and writes the output to both. Now I don't know if GPSAM has been updated for newer OS levels (the File 648 version is dated 1982), but conceptually and maybe even practically, it should still be fine on z/OS today. Preferably by JCL means. Um, well, once you write your little access method (all nice, unauthorized code, btw) and install GPSAM, it would all be by JCL means. It would look something like this: // EXEC PGM=yourprog //STEPLIB DD DSN=your.private.unauth.loadlib //SYSPRINT DD SUBSYS=(GPSM,DOUBLER,'COPY1,COPY2') //COPY1 DD SYSOUT=* //COPY2 DD DSN=dataset,DISP=...,etc. You just have to write the DOUBLER routine. Or make it as general as you like - TUPLER...? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
So, I found that it is actually tricky to get the current jobid using REXX in a WLM-initiated environment. Here's a slightly patched REXX script that I found by Bill Lalonde that will do it: /* REXX */ /* curjobid.rexx (adapted from http://billlalonde.tripod.com/rexx/findjsab.txt) */ /* Based on expansion of IAZXJSAB macro */ /* This EXEC returns current jobname, jobid, userid and */ /* name of the component which created the JSAB */ /* for the current task / address space */ NUMERIC DIGITS 10 tcb = C2D(STORAGE(21C,4))/* get current TCB */ jsab = 0 /* null pointer*/ if tcb \= 0 then do stcb = C2D(STORAGE(D2X(tcb+312),4)) jsab = C2D(STORAGE(D2X(stcb+188),4)) end if jsab = 0 then do ascb = C2D(STORAGE(224,4))/* get current TCB */ assb = C2D(STORAGE(D2X(ascb+336),4)) if ascb = 0 then do call lineout stderr,'Unable to locate JSAB from ASCB at 'D2X(ascb) exit 8 end jsab = C2D(STORAGE(D2X(assb+168),4)) if jsab = 0 then do call lineout stderr,'Unable to locate JSAB from ASCB at 'D2X(ascb) exit 8 end end flg1 = C2D(STORAGE(D2X(jsab+13),1)) DO WHILE flg1 127 eye = STORAGE(D2X(jsab),4) If eye \= 'JSAB' then do call lineout stderr,'Invalid JSAB found at 'D2X(jsab) exit 8 end jsab = C2D(STORAGE(D2X(jsab+4),4)) if jsab = 0 then do call lineout stderr,'Unable to locate a valid JSAB' exit 8 end flg1 = C2D(STORAGE(D2X(jsab+13),1)) END /* jbnm = STORAGE(D2X(jsab+28),8) */ jbid = STORAGE(D2X(jsab+20),8) /* comp = STORAGE(D2X(jsab+16),4) */ /* usid = STORAGE(D2X(jsab+44),8) */ say jbid exit 0 So, then you can add this step to your job to copy a previous step's spool file to another DD: // EXEC PGM=COZBATCH //STDIN DD * fromdsn //-jes.$(curjobid.rexx).stepname.procstep.ddname | todsn //DD:OUT //OUT DD ... // -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Duplicating SYSOUT output to another DD/DSN in realtime ? (JCL)
On 27 February 2012 15:12, McKown, John john.mck...@healthmarkets.com wrote: I need to learn how to use the STORAGE function to do chain chasing in REXX. I generally dislike this any more. I am becoming more of a GUPI programmer as I age. Or maybe I'm just too lazy anymore. Regardless, you're a positive anymore guy - the only one on this list that I've noticed. Native or learned? I had thought it carried a young demographic, but I see not particularly. Midwestern US, mostly, it seems. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
On Thu, 23 Feb 2012 07:52:38 -0500, Bill Ashton wrote: I use this sort of trick often for controlling sections of JCL, For example, I might have a step or two that deletes and allocates files, then another step that processes data into the new files, and finally a step that prints report files from the job. Then at the top I would SET ALLOC = either 1 to run or 0 to not run, SET PROCESS to 1/0, and SET REPORTS to 1/0. In the JCL I start with a do-nothing BR14, and then surround each section with IF ALLOC=1 THEN..ENDIF If PROCESS=1 THEN.ENDIF and If REPORTS=1 THEN.ENDIF This would appear to be disallowed by: * z/OS V1R13.0 MVS JCL Reference * SA22-7597-15 where I read: 17.1.9 Considerations when Using the IF/THEN/ELSE/ENDIF Construct Be aware of the following considerations when using the IF/THEN/ELSE/ENDIF statement construct: ... # You can specify symbolic parameters on IF/THEN/ELSE/ENDIF statements provided that they resolve to one of the supported relational-expression keywords listed in the preceding topic (that is, RC, ABEND, ...). Any other symbolic parameters, even if accepted by the system, are not intended or supported. Would you submit to a code review any code that depends on behavior which is not intended or supported by the vendor? Which leaves a question: what about constructs that are not documented in an earlier topic as supported, but are coded directly, not involving symbolic parameters? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
Hey Gil, Is the IF/THEN assuming, big word here, that the 1 is a return code, just a thought Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 24, 2012, at 8:37 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 23 Feb 2012 07:52:38 -0500, Bill Ashton wrote: I use this sort of trick often for controlling sections of JCL, For example, I might have a step or two that deletes and allocates files, then another step that processes data into the new files, and finally a step that prints report files from the job. Then at the top I would SET ALLOC = either 1 to run or 0 to not run, SET PROCESS to 1/0, and SET REPORTS to 1/0. In the JCL I start with a do-nothing BR14, and then surround each section with IF ALLOC=1 THEN..ENDIF If PROCESS=1 THEN.ENDIF and If REPORTS=1 THEN.ENDIF This would appear to be disallowed by: * z/OS V1R13.0 MVS JCL Reference * SA22-7597-15 where I read: 17.1.9 Considerations when Using the IF/THEN/ELSE/ENDIF Construct Be aware of the following considerations when using the IF/THEN/ELSE/ENDIF statement construct: ... # You can specify symbolic parameters on IF/THEN/ELSE/ENDIF statements provided that they resolve to one of the supported relational-expression keywords listed in the preceding topic (that is, RC, ABEND, ...). Any other symbolic parameters, even if accepted by the system, are not intended or supported. Would you submit to a code review any code that depends on behavior which is not intended or supported by the vendor? Which leaves a question: what about constructs that are not documented in an earlier topic as supported, but are coded directly, not involving symbolic parameters? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
One of my favourite tricks is to use the ISPF editor to Exclude the lines I don't want, and then issue the SUB NX command. Only the JCL in the non-excluded lines will be submitted. On Fri, Feb 24, 2012 at 10:58, Scott Ford scott_j_f...@yahoo.com wrote: Hey Gil, Is the IF/THEN assuming, big word here, that the 1 is a return code, just a thought Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 24, 2012, at 8:37 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 23 Feb 2012 07:52:38 -0500, Bill Ashton wrote: I use this sort of trick often for controlling sections of JCL, For example, I might have a step or two that deletes and allocates files, then another step that processes data into the new files, and finally a step that prints report files from the job. Then at the top I would SET ALLOC = either 1 to run or 0 to not run, SET PROCESS to 1/0, and SET REPORTS to 1/0. In the JCL I start with a do-nothing BR14, and then surround each section with IF ALLOC=1 THEN..ENDIF If PROCESS=1 THEN.ENDIF and If REPORTS=1 THEN.ENDIF This would appear to be disallowed by: * z/OS V1R13.0 MVS JCL Reference * SA22-7597-15 where I read: 17.1.9 Considerations when Using the IF/THEN/ELSE/ENDIF Construct Be aware of the following considerations when using the IF/THEN/ELSE/ENDIF statement construct: ... # You can specify symbolic parameters on IF/THEN/ELSE/ENDIF statements provided that they resolve to one of the supported relational-expression keywords listed in the preceding topic (that is, RC, ABEND, ...). Any other symbolic parameters, even if accepted by the system, are not intended or supported. Would you submit to a code review any code that depends on behavior which is not intended or supported by the vendor? Which leaves a question: what about constructs that are not documented in an earlier topic as supported, but are coded directly, not involving symbolic parameters? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
On Fri, 24 Feb 2012 10:58:50 -0500, Scott Ford wrote: Hey Gil, Is the IF/THEN assuming, big word here, that the 1 is a return code, just a thought On Thu, 23 Feb 2012 07:52:38 -0500, Bill Ashton wrote: In the JCL I start with a do-nothing BR14, and then surround each section with IF ALLOC=1 THEN..ENDIF If PROCESS=1 THEN.ENDIF and If REPORTS=1 THEN.ENDIF Empirically, it appears to do the intuitively obvious: treat the operand as an integer constqnt. But given the pains that IBM takes to declare the construct unintended and unsupported, they appear to be reserving the right to implement whatever changes in behavior they choose, perhaps making it dependent on ambient temperature, barometric pressure, relative humidity, and phase of Moon. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
Gil, Maybe some mumbo jumbo too... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 24, 2012, at 10:43 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Fri, 24 Feb 2012 10:58:50 -0500, Scott Ford wrote: Hey Gil, Is the IF/THEN assuming, big word here, that the 1 is a return code, just a thought On Thu, 23 Feb 2012 07:52:38 -0500, Bill Ashton wrote: In the JCL I start with a do-nothing BR14, and then surround each section with IF ALLOC=1 THEN..ENDIF If PROCESS=1 THEN.ENDIF and If REPORTS=1 THEN.ENDIF Empirically, it appears to do the intuitively obvious: treat the operand as an integer constqnt. But given the pains that IBM takes to declare the construct unintended and unsupported, they appear to be reserving the right to implement whatever changes in behavior they choose, perhaps making it dependent on ambient temperature, barometric pressure, relative humidity, and phase of Moon. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Stupid JCL trick?
It seems to me more convenient to have an edit macro that make comments of a step. Something like: COMSTEP stepname and ACTSTEP stepname (to de-comment the step). Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Andrew Armstrong Skickat: den 23 februari 2012 08:23 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Stupid JCL trick? On Tue, 21 Feb 2012 15:48:12 -0600, Paul Gilmartin paulgboul...@aim.com wrote: Nope. RTFM. ...nevertheless (even though it's not in the fine manual) something that appears to work for me is: // IF 1 = 1 THEN ...do this stuff... // ENDIF and // IF 1 = 0 THEN ...don't do this stuff... // ENDIF hmmm...bug or feature? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
On Tue, 21 Feb 2012 10:16:25 -0600, McKown, John john.mck...@healthmarkets.com wrote: Do you ever want to retire some step(s) from a job? But you don't really want to remove the step(s) just in case? Did you consider managing your JCL through a change managment product (Endevor, ChangeMan, ISPW, SCLM, ...). I know we do and I prefer that to any other trick. Not only does it provide a version history, but a decent audit trail as well. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
I use this sort of trick often for controlling sections of JCL, For example, I might have a step or two that deletes and allocates files, then another step that processes data into the new files, and finally a step that prints report files from the job. Then at the top I would SET ALLOC = either 1 to run or 0 to not run, SET PROCESS to 1/0, and SET REPORTS to 1/0. In the JCL I start with a do-nothing BR14, and then surround each section with IF ALLOC=1 THEN..ENDIF If PROCESS=1 THEN.ENDIF and If REPORTS=1 THEN.ENDIF This might be a weak example, but I can't go into more specific real details of our jobs. I think you can get the idea. billy On Thu, Feb 23, 2012 at 2:22 AM, Andrew Armstrong androidarmstr...@gmail.com wrote: On Tue, 21 Feb 2012 15:48:12 -0600, Paul Gilmartin paulgboul...@aim.com wrote: Nope. RTFM. ...nevertheless (even though it's not in the fine manual) something that appears to work for me is: // IF 1 = 1 THEN ...do this stuff... // ENDIF and // IF 1 = 0 THEN ...don't do this stuff... // ENDIF hmmm...bug or feature? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- Thank you and best regards, *Billy Ashton* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
I may not manage my own personal JCL via Endevor. We do use Endevor for cycle (test, mdof, prod) JCL. If I wanted to use change management, I would maintain it on my Linux box and use git. But I'm known to be just a bit strange. grin I know this sounds weird, but I already keep my source in z/OS UNIX files. I could keep them on my Linux system use NFS to allow z/OS to access the subdirectories involved. But I don't trust my Linux box quite that much ... yet. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jan MOEYERSONS Sent: Thursday, February 23, 2012 5:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Stupid JCL trick? On Tue, 21 Feb 2012 10:16:25 -0600, McKown, John john.mck...@healthmarkets.com wrote: Do you ever want to retire some step(s) from a job? But you don't really want to remove the step(s) just in case? Did you consider managing your JCL through a change managment product (Endevor, ChangeMan, ISPW, SCLM, ...). I know we do and I prefer that to any other trick. Not only does it provide a version history, but a decent audit trail as well. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Stupid JCL trick?
On Tue, 21 Feb 2012 15:48:12 -0600, Paul Gilmartin paulgboul...@aim.com wrote: Nope. RTFM. ...nevertheless (even though it's not in the fine manual) something that appears to work for me is: // IF 1 = 1 THEN ...do this stuff... // ENDIF and // IF 1 = 0 THEN ...don't do this stuff... // ENDIF hmmm...bug or feature? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Stupid JCL trick?
Do you ever want to retire some step(s) from a job? But you don't really want to remove the step(s) just in case? I don't remember this being mentioned before, so I thought I would. It will work for any step, other than the first one in the job. Find a step, any step, before the step(s) you want to bypass. Wrap the step(s) you want to bypass with: // IF (stepname.RUN=TRUE AND stepname.RUN=FALSE) THEN steps to be bypassed // ENDIF Replace stepname with the name of the step you selected which exists before the bypassed step(s). This works if the previous step ran or didn't run, regardless of the step's return code if it did run. Sorry if this was obvious. Maybe my brain has retired already. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
