Re: Using JCL Symbld and TYPRUN=SCAN
On Fri, 13 Jul 2018 09:56:45 +1000, Andrew Rowley wrote: >On 13/07/2018 1:55 AM, Seymour J Metz wrote: >> WTF? Dynamic allocation has supported temporary data sets since Old Man >> Noach cornered the market in Gopher Wood. We don't need mo stinking JCL for >> that. >I assume you're correct (I was referring to temporary unix files) but I >tried to look up the details in the documentation and I couldn't find >anything specific. > UNIX tmpfile() has some of that function. Its semantics are different and it's difficult to pass a temporary file from program to program. >How would you do the equivalent of DISP=(NEW,DELETE) or (NEW,PASS) using >dynamic allocation? > I believe DELETE works much the same with dynamic allocation as with JCL. In fact, one way to use BPXDYN to delete a file is to ALLOC it MOD DELETE, then FREE it. PASS is peculiar to JCL and is unavailable from dynamic allocation. BPXWDYN( rtddn(name) ) is an alternative, but not equivalent. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 13/07/2018 1:55 AM, Seymour J Metz wrote: Again it is something that we take for granted in JCL that becomes difficult to do correctly without it. WTF? Dynamic allocation has supported temporary data sets since Old Man Noach cornered the market in Gopher Wood. We don't need mo stinking JCL for that. I assume you're correct (I was referring to temporary unix files) but I tried to look up the details in the documentation and I couldn't find anything specific. How would you do the equivalent of DISP=(NEW,DELETE) or (NEW,PASS) using dynamic allocation? Assembler solutions fall into my definition of "difficult to do", compared to JCL. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Thu, 12 Jul 2018 12:32:55 +, Pew, Curtis G wrote: >On Jul 11, 2018, at 11:27 PM, Andrew Rowley wrote: >> That's sort of true, but it vastly expands the competition. It makes HTML, >> even GML programming languages. Is JCL a worse programming language than GML? > >That’s kind of how I meant it. I think of JCL as much closer to XML or JSON >than to something like BASIC. You can’t, for example, use JCL to add two >numbers. > Which was one incentive for my using a program to generate JCL. When I want to create a multi-file tape a script automates creating the sequence number in the label. If I add a file I don't need to modify all later steps. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Well, progrmming is what the TV networks do. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Thursday, July 12, 2018 12:10 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Using JCL Symbld and TYPRUN=SCAN Ed said 'constitute programming'. He did not use the term 'language'. Ah, another war of words! -- My assembler instructor in computer school got into the biz when 'programming' changes were made with Home Depot tools. Hard to fit the term 'language' to wire clippers and soldering irons. OK, long before Home Depot but not before Sears. -- I've heard stories of veteran CEs entering simple 'programs' into a CEC directly via HMC store operations. Again, no obvious 'language' involved. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, July 12, 2018 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Using JCL Symbld and TYPRUN=SCAN I doubt that many programmers ,or lexicographers, would agree with that. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ed Jaffe Sent: Thursday, July 12, 2018 12:05 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Using JCL Symbld and TYPRUN=SCAN On 7/11/2018 4:04 PM, Pew, Curtis G wrote: > I don’t think it’s true that JCL is the worst programming language > (with all due respect to Fred Brooks) because it isn’t really a > programming language. Should it have been a programming language? > Almost certainly, as shown by Unix scripting languages. But it isn’t... With all due respect to whomever deserves it, ANY instructions telling the computer what to do constitute programming... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1zjCfruIOOKZw4mRJqIBjCcQV4BgvaKOI8jDbdP_z_xMndsVRFWmgc0S-QwOhS7djTkXSAK2UyQ41QhfXYjoPd6Kla3zdAmLSKJ9gbv5ITWHLdW-sa_O3hv6BZvb6RJI6VTAax1C5Z_2SoXhwbv9hNAVDzVnZJTQIK3XiNluAanvZjrZP3CWwzGvmB72RGNJ3mPiXRXZuIYN9A5cUaCrttoqEShN0i8Opkj2ekiQH4f7FeYaWcTuFhVCe7z3Y8-i0oOWDXp-xkbVxMFH7z1bizf40ppsqOrYpHtdzRExg0SY67wENmBazGYNpG1RQDxJT_dlyxE_PsqspAg85zxdkbuvfAm8HVksAZ-81bE8662LOQ3t2ULe9UzBFvg9s4qq4jjSaQ5KlNfWUw5mu7H81InRXlH-66ibH3GM3Rx1JPEIEu3SmP4w00Pe8__KkMM39/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Ed said 'constitute programming'. He did not use the term 'language'. Ah, another war of words! -- My assembler instructor in computer school got into the biz when 'programming' changes were made with Home Depot tools. Hard to fit the term 'language' to wire clippers and soldering irons. OK, long before Home Depot but not before Sears. -- I've heard stories of veteran CEs entering simple 'programs' into a CEC directly via HMC store operations. Again, no obvious 'language' involved. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, July 12, 2018 8:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Using JCL Symbld and TYPRUN=SCAN I doubt that many programmers ,or lexicographers, would agree with that. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ed Jaffe Sent: Thursday, July 12, 2018 12:05 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Using JCL Symbld and TYPRUN=SCAN On 7/11/2018 4:04 PM, Pew, Curtis G wrote: > I don’t think it’s true that JCL is the worst programming language > (with all due respect to Fred Brooks) because it isn’t really a > programming language. Should it have been a programming language? > Almost certainly, as shown by Unix scripting languages. But it isn’t... With all due respect to whomever deserves it, ANY instructions telling the computer what to do constitute programming... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1zjCfruIOOKZw4mRJqIBjCcQV4BgvaKOI8jDbdP_z_xMndsVRFWmgc0S-QwOhS7djTkXSAK2UyQ41QhfXYjoPd6Kla3zdAmLSKJ9gbv5ITWHLdW-sa_O3hv6BZvb6RJI6VTAax1C5Z_2SoXhwbv9hNAVDzVnZJTQIK3XiNluAanvZjrZP3CWwzGvmB72RGNJ3mPiXRXZuIYN9A5cUaCrttoqEShN0i8Opkj2ekiQH4f7FeYaWcTuFhVCe7z3Y8-i0oOWDXp-xkbVxMFH7z1bizf40ppsqOrYpHtdzRExg0SY67wENmBazGYNpG1RQDxJT_dlyxE_PsqspAg85zxdkbuvfAm8HVksAZ-81bE8662LOQ3t2ULe9UzBFvg9s4qq4jjSaQ5KlNfWUw5mu7H81InRXlH-66ibH3GM3Rx1JPEIEu3SmP4w00Pe8__KkMM39/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
> Again it is something that we take for granted in JCL that becomes > difficult to do correctly without it. WTF? Dynamic allocation has supported temporary data sets since Old Man Noach cornered the market in Gopher Wood. We don't need mo stinking JCL for that. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Andrew Rowley Sent: Wednesday, July 11, 2018 11:18 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: Using JCL Symbld and TYPRUN=SCAN On 12/07/2018 11:47 AM, Paul Gilmartin wrote: > On Thu, 12 Jul 2018 11:01:50 +1000, Andrew Rowley wrote: >> Creating temporary files has its own security exposures. I am always >> wary in case I am creating a security problem I don't understand. > You'd better not use SORT. I am comfortable that the temporary file facilities in JCL are secure, and constructs like DISP=(NEW,DELETE) are not an issue. And temporary files created by something like DFSORT are someone else's problem. It is temporary files in the HFS side of things that are the issue. Again it is something that we take for granted in JCL that becomes difficult to do correctly without it. A couple of articles on the subject: http://secure-web.cisco.com/19zTgw5l4mNMUIFLg54Kdy_vy9ovUURWUPgH9qMMXVmbpny7rVDAErUcD1xXOFVijoMy5AROis-PJEDTMBbfjG0LUFTJh13Dr5s_sGROocBeKc7WUVjJQkmShPbjgKyWdlRLFPlqW1TnOzgJeH5jDEUy0lcxMOu7TjQ-DWvebVmwwCwEFWUU8YLbeKu2nj71rbxyIV8Akc2BMamAsQVQ8HAIcucVuVk3M-0hWT68fYEg40lpUXrYhG486Kh5jGSlRVAn6WyinZHGfF9VmXDq0TcR9vPZZXJHoL261yMyDKz6xOXkIdwsdbSwgYaevoQZ_ZqCKwdlNSm7RGXerHeLxqrKdfh6auKz1XQow8yyEw5A-dHrNLIywohsT4feIoZ7PNjYh9MoVL2OTVrOXGqXUr9dLBVLMywBqM5SfTWv-8Cy4m9lMeVN6zn_7VNSpOJJv/http%3A%2F%2Fwww.linuxsecurity.com%2Fcontent%2Fview%2F115462%2F81%2F https://blogs.msdn.microsoft.com/secureapps/2007/01/22/temporary-file-generation-and-usage-best-practices/ There are enough issues there that for me, the best solution is point 1: Don't use tempfiles/Avoid temporary files altogether -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
I doubt that many programmers ,or lexicographers, would agree with that. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Ed Jaffe Sent: Thursday, July 12, 2018 12:05 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Using JCL Symbld and TYPRUN=SCAN On 7/11/2018 4:04 PM, Pew, Curtis G wrote: > I don’t think it’s true that JCL is the worst programming language > (with all due respect to Fred Brooks) because it isn’t really a > programming language. Should it have been a programming language? > Almost certainly, as shown by Unix scripting languages. But it isn’t... With all due respect to whomever deserves it, ANY instructions telling the computer what to do constitute programming... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1zjCfruIOOKZw4mRJqIBjCcQV4BgvaKOI8jDbdP_z_xMndsVRFWmgc0S-QwOhS7djTkXSAK2UyQ41QhfXYjoPd6Kla3zdAmLSKJ9gbv5ITWHLdW-sa_O3hv6BZvb6RJI6VTAax1C5Z_2SoXhwbv9hNAVDzVnZJTQIK3XiNluAanvZjrZP3CWwzGvmB72RGNJ3mPiXRXZuIYN9A5cUaCrttoqEShN0i8Opkj2ekiQH4f7FeYaWcTuFhVCe7z3Y8-i0oOWDXp-xkbVxMFH7z1bizf40ppsqOrYpHtdzRExg0SY67wENmBazGYNpG1RQDxJT_dlyxE_PsqspAg85zxdkbuvfAm8HVksAZ-81bE8662LOQ3t2ULe9UzBFvg9s4qq4jjSaQ5KlNfWUw5mu7H81InRXlH-66ibH3GM3Rx1JPEIEu3SmP4w00Pe8__KkMM39/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
No, the GML Starter Set is implemented in Script but is not Script and has very different syntax. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Andrew Rowley Sent: Thursday, July 12, 2018 12:56 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Using JCL Symbld and TYPRUN=SCAN On 12/07/2018 2:48 PM, Ed Jaffe wrote: > > If you are referring to the GameMaker Language (GML) then yes, JCL is > clearly much, much worse... > > https://secure-web.cisco.com/1cKxvSgUaXO4DyyVa9rcjD0tV4VTM2jAjYR0dnFzUyYzSoeAcJicuzQOBu3cboe_mdq21wRP2VEJ7YTriFQZa9MnNl4_KW0xbIiO-rr1ajYnc7QTKrahupyWEUQdKX2RLChgTfnWi6-ZXXPTbUdvoBAVwZUPFxouP2a4_L_992tWe3kQManlaU9wTgMQlrM_Clw2h238pXVc25kzYZ37i_r7JmOkDiukxR1qiEOUHWpfwmMHgsDqDqR9ys-IeQMzHwIwxWXCljDisuM67LPiU_2UCwANUc2X4uykiXS7L0RvdGPazif5uxNj0g7Ma0FAU17tGoGNfvEZthzRTYK9awJXxYem2ETJUt4JhE-5pUPnZsjQ7pHcphHX_ktV6doPC/https%3A%2F%2Fdocs.yoyogames.com%2Fsource%2Fdadiospice%2F002_reference%2F001_gml%2520language%2520overview%2F > > No, Generalized Markup Language i.e. SCRIPT. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Nice program, I made it a long time ago for load tests and called it IEFBR15.
Grtn,
Kees.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Smith
> Sent: 12 July, 2018 16:19
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Using JCL Symbld and TYPRUN=SCAN
>
> And that's the point...
>
> SR 14,14
> BR 15
>
> is easier and clearer than machine language, but
>
> main {}
>
> is (sorta) clearer than that.
>
> sas
>
> p.s. bonus points if you see what I did there ;-)
>
>
> On Thu, Jul 12, 2018 at 9:19 AM, John Eells wrote:
>
> > Ed Jaffe wrote:
> >
> >> On 7/11/2018 4:04 PM, Pew, Curtis G wrote:
> >>
> >>> I don’t think it’s true that JCL is the worst programming language
> (with
> >>> all due respect to Fred Brooks) because it isn’t really a
> programming
> >>> language. Should it have been a programming language? Almost
> certainly, as
> >>> shown by Unix scripting languages. But it isn’t...
> >>>
> >>
> >> With all due respect to whomever deserves it, ANY instructions
> telling
> >> the computer what to do constitute programming...
> >>
> >>
> > This opens up the "competition for the race to the bottom" to machine
> > language, which is clearly the "winner" here! Even 1BFF07FE is harder
> to
> > read and code than its 2-instruction assembler counterpart.
> >
> > (OK, so I could not resist. Back into my hole now.)
> >
> > --
> > John Eells
> > IBM Poughkeepsie
> > ee...@us.ibm.com
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> sas
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
And that's the point...
SR 14,14
BR 15
is easier and clearer than machine language, but
main {}
is (sorta) clearer than that.
sas
p.s. bonus points if you see what I did there ;-)
On Thu, Jul 12, 2018 at 9:19 AM, John Eells wrote:
> Ed Jaffe wrote:
>
>> On 7/11/2018 4:04 PM, Pew, Curtis G wrote:
>>
>>> I don’t think it’s true that JCL is the worst programming language (with
>>> all due respect to Fred Brooks) because it isn’t really a programming
>>> language. Should it have been a programming language? Almost certainly, as
>>> shown by Unix scripting languages. But it isn’t...
>>>
>>
>> With all due respect to whomever deserves it, ANY instructions telling
>> the computer what to do constitute programming...
>>
>>
> This opens up the "competition for the race to the bottom" to machine
> language, which is clearly the "winner" here! Even 1BFF07FE is harder to
> read and code than its 2-instruction assembler counterpart.
>
> (OK, so I could not resist. Back into my hole now.)
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
sas
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Ed Jaffe wrote: On 7/11/2018 4:04 PM, Pew, Curtis G wrote: I don’t think it’s true that JCL is the worst programming language (with all due respect to Fred Brooks) because it isn’t really a programming language. Should it have been a programming language? Almost certainly, as shown by Unix scripting languages. But it isn’t... With all due respect to whomever deserves it, ANY instructions telling the computer what to do constitute programming... This opens up the "competition for the race to the bottom" to machine language, which is clearly the "winner" here! Even 1BFF07FE is harder to read and code than its 2-instruction assembler counterpart. (OK, so I could not resist. Back into my hole now.) -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Jul 11, 2018, at 11:27 PM, Andrew Rowley wrote: > > That's sort of true, but it vastly expands the competition. It makes HTML, > even GML programming languages. Is JCL a worse programming language than GML? > That’s kind of how I meant it. I think of JCL as much closer to XML or JSON than to something like BASIC. You can’t, for example, use JCL to add two numbers. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 2:48 PM, Ed Jaffe wrote: If you are referring to the GameMaker Language (GML) then yes, JCL is clearly much, much worse... https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/ No, Generalized Markup Language i.e. SCRIPT. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 7/11/2018 9:27 PM, Andrew Rowley wrote: On 12/07/2018 2:05 PM, Ed Jaffe wrote: With all due respect to whomever deserves it, ANY instructions telling the computer what to do constitute programming... That's sort of true, but it vastly expands the competition. It makes HTML, even GML programming languages. Is JCL a worse programming language than GML? If you are referring to the GameMaker Language (GML) then yes, JCL is clearly much, much worse... https://docs.yoyogames.com/source/dadiospice/002_reference/001_gml%20language%20overview/ -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 2:05 PM, Ed Jaffe wrote: With all due respect to whomever deserves it, ANY instructions telling the computer what to do constitute programming... That's sort of true, but it vastly expands the competition. It makes HTML, even GML programming languages. Is JCL a worse programming language than GML? -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 7/11/2018 4:04 PM, Pew, Curtis G wrote: I don’t think it’s true that JCL is the worst programming language (with all due respect to Fred Brooks) because it isn’t really a programming language. Should it have been a programming language? Almost certainly, as shown by Unix scripting languages. But it isn’t... With all due respect to whomever deserves it, ANY instructions telling the computer what to do constitute programming... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 11:47 AM, Paul Gilmartin wrote: On Thu, 12 Jul 2018 11:01:50 +1000, Andrew Rowley wrote: Creating temporary files has its own security exposures. I am always wary in case I am creating a security problem I don't understand. You'd better not use SORT. I am comfortable that the temporary file facilities in JCL are secure, and constructs like DISP=(NEW,DELETE) are not an issue. And temporary files created by something like DFSORT are someone else's problem. It is temporary files in the HFS side of things that are the issue. Again it is something that we take for granted in JCL that becomes difficult to do correctly without it. A couple of articles on the subject: http://www.linuxsecurity.com/content/view/115462/81/ https://blogs.msdn.microsoft.com/secureapps/2007/01/22/temporary-file-generation-and-usage-best-practices/ There are enough issues there that for me, the best solution is point 1: Don't use tempfiles/Avoid temporary files altogether -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Thu, 12 Jul 2018 11:01:50 +1000, Andrew Rowley wrote: > >Creating temporary files has its own security exposures. I am always >wary in case I am creating a security problem I don't understand. > You'd better not use SORT. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 10:46 AM, Paul Gilmartin wrote: Is it any worse than if the processes operated sequentially; no overlap. Second guy wins. Conscientious second guy will create the file with O_EXCL. If you don't trust the second guy, lock him out with RACF profile or file permissions. It probably is worse, e.g. a likely example is where the second guy is processing the output from the first guy. The designers of z/OS thought this scenario was most likely an error and so protected you from it - I tend to agree. I don't trust the second guy to get the serialization right, where it is not built-in. If I want to be very nondisruptive I write to a temp name and rename at the end. This guarantees that no other job sees the update in transit. Creating temporary files has its own security exposures. I am always wary in case I am creating a security problem I don't understand. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Thu, 12 Jul 2018 09:40:50 +1000, Andrew Rowley wrote: > >On a unix system, you can open a file for writing and another process >can delete it while you have it open and create a new file with the same >name. The file you are writing disappears when you close it. > That's a sort of LUW isolation, a facility that has come relatively recently to z/OS in PDSE members. For better or for worse, however you view it. Is it any worse than if the processes operated sequentially; no overlap. Second guy wins. Conscientious second guy will create the file with O_EXCL. If you don't trust the second guy, lock him out with RACF profile or file permissions. If I want to be very nondisruptive I write to a temp name and rename at the end. This guarantees that no other job sees the update in transit. UNIX rename() is preemptive: it quietly replaces any older file with the same name; and atomic: no process will perceive an instant when the file appears not to exist. I wish I could get the same behavior from IDCAMS RENAME. >... This sort >of thing is considered bad on z/OS. Sure, that's a function of z/OS >enqueues etc., but JCL is the (relatively) easy to use interface to >allocation. On Thu, 12 Jul 2018 09:49:41 +1000, Andrew Rowley wrote: > >This works OK except when it doesn't. I recently encountered a problem >where the command implicitly sourced /etc/profile. Which meant that >things broke when /etc/profile changed the value of the environment >variable. > That sounds like a "Don't do that!" Don't do that. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 3:22 AM, John McKown wrote:
I've seen a lot of UNIX programs which implement the same concept using
shell environment variables. Simple, universal almost, examples are
${HOME}, ${TMPDIR} (and variants), ${CLASSPATH} for Javca, ${PATH} for an
//STEPLIB equivalent.
I have a PERL script which implements this. When run, you can specify the
"database name" (PostgreSQL) using --dbname= on the command. If not
specified, it will look for the DBNAME environment variable. If neither,
then it takes a default.
This works OK except when it doesn't. I recently encountered a problem
where the command implicitly sourced /etc/profile. Which meant that
things broke when /etc/profile changed the value of the environment
variable.
--
Andrew Rowley
Black Hill Software
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 12/07/2018 12:51 AM, Hobart Spitz wrote: It may take a little more skill and experience to write in a real scripting language than in JCL, but it should be done. Here is an example of something that is simple in JCL, but very difficult to get right in a scripting language (i.e. 6 equivalent scripts): //JOB1 JOB //S1 EXEC PGM=PROGRAMA //DD1 DD DSN=DATASET.A,DISP=SHR //DD2 DD DSN=DATASET.B,DISP=SHR //JOB2 JOB //S1 EXEC PGM=PROGRAMB //DD1 DD DSN=DATASET.A,DISP=OLD //DD2 DD DSN=DATASET.B,DISP=SHR //JOB3 JOB //S1 EXEC PGM=PROGRAMC //DD1 DD DSN=DATASET.A,DISP=SHR //DD2 DD DSN=DATASET.B,DISP=OLD //JOB4 JOB //S1 EXEC PGM=PROGRAMD //DD1 DD DSN=DATASET.A,DISP=OLD //DD2 DD DSN=DATASET.B,DISP=OLD //JOB5 JOB //S1 EXEC PGM=PROGRAME //DD1 DD DSN=DATASET.A,DISP=SHR //JOB6 JOB //S1 EXEC PGM=PROGRAMF //DD2 DD DSN=DATASET.B,DISP=SHR I have debugged problems on unix where (unattended) overnight backups never completed because 2 jobs deadlocked and just sat there for hours. Jobs that do dynamic allocation with anything other than DISP=SHR can't be trusted, particularly if they are 3rd party programs where you don't know exactly what will be allocated and under what circumstances. I haven't seen large amounts of batch processing on platforms other than z/OS. I suspect a big reason is that without JCL it is impractical. A reasonably common message from tar on unix systems is "file changed as we read it". I know how to fix the equivalent with z/OS datasets. How do you prevent it on Unix? And tar is probably an unusual case, in that it notices and reports when it happens. The reality seems to be that on other platforms everything is shared, and if you are concerned about simultaneous updates (or even guaranteeing that a file isn't changed while you read it) it is up to everyone accessing that file to cooperate with some form of locking. Difficult, if you didn't write all the programs. On a unix system, you can open a file for writing and another process can delete it while you have it open and create a new file with the same name. The file you are writing disappears when you close it. This sort of thing is considered bad on z/OS. Sure, that's a function of z/OS enqueues etc., but JCL is the (relatively) easy to use interface to allocation. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Jul 11, 2018, at 5:47 PM, Ed Jaffe wrote:
>
> I disagree. BASIC has iterations ('for' loops), forward and backward
> branching, and subroutine call/return. These fundamental programming language
> constructs are missing from JCL. This is why it's such a bad programming
> language.
I don’t think it’s true that JCL is the worst programming language (with all
due respect to Fred Brooks) because it isn’t really a programming language.
Should it have been a programming language? Almost certainly, as shown by Unix
scripting languages. But it isn’t, and although JCL does have many other
deficiencies, it’s biggest problem is that people come to it expecting a
programming language, and that’s not what it is.
When I try to explain JCL, I describe it as a human-interface language for an
obsolete input technology (punch cards) that was thrown together at the last
minute rather than designed and exposes technical details you’d rather not have
to know about, but other than that it’s great! An EXEC statement is like
double-clicking on an app icon, DD statements are like open/save dialogs, etc.
But it’s not programming.
--
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 7/11/2018 3:16 PM, Paul Gilmartin wrote:
So of you search far enough, you can find something worse than JCL to
compare it to, making JCL only the *second* worst programming
language in existence. Provided BASIC is still viable; otherwise JCL
reclaims last place.
I disagree. BASIC has iterations ('for' loops), forward and backward
branching, and subroutine call/return. These fundamental programming
language constructs are missing from JCL. This is why it's such a bad
programming language.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Wed, 11 Jul 2018 09:56:26 -0700, Tom Brennan wrote: >I've always considered DD's one of the major differences between MVS and >other platforms. I remember one of my first BASIC programs in college >where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1" >and sort. The first thing I thought of was, "So we have to update the >program every time we want to sort a different file?" > So of you search far enough, you can find something worse than JCL to compare it to, making JCL only the *second* worst programming language in existence. Provided BASIC is still viable; otherwise JCL reclaims last place. But don't you have to update the JCL every time you want to sort a different file?" Code is code. I have a number of scripts with symbol assignments at the top. I EDIT; SUBMIT; CANCEL. Why should it be better to edit a JCLLIB member; SAVE; and INCLUDE it instead? >DD redirection: Genius, whoever thought of it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Wed, Jul 11, 2018 at 11:57 AM Tom Brennan
wrote:
> I've always considered DD's one of the major differences between MVS and
> other platforms. I remember one of my first BASIC programs in college
> where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1"
> and sort. The first thing I thought of was, "So we have to update the
> program every time we want to sort a different file?"
>
> DD redirection: Genius, whoever thought of it.
>
I've seen a lot of UNIX programs which implement the same concept using
shell environment variables. Simple, universal almost, examples are
${HOME}, ${TMPDIR} (and variants), ${CLASSPATH} for Javca, ${PATH} for an
//STEPLIB equivalent.
I have a PERL script which implements this. When run, you can specify the
"database name" (PostgreSQL) using --dbname= on the command. If not
specified, it will look for the DBNAME environment variable. If neither,
then it takes a default.
>
> On 7/11/2018 8:40 AM, Steve Smith wrote:
>
> > DDNAMEs are a pretty nice feature of z/OS! So you *don't* have to pass a
> > bunch of (potentially very long) file names. DDNAMEs can be thought of
> as
> > a limited form of environment variables.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
There is no such thing as the Cloud. It is just somebody else’s computer.
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
I've always considered DD's one of the major differences between MVS and other platforms. I remember one of my first BASIC programs in college where we had to code something like "OPEN PAYROLL.DATA FOR INPUT AS #1" and sort. The first thing I thought of was, "So we have to update the program every time we want to sort a different file?" DD redirection: Genius, whoever thought of it. On 7/11/2018 8:40 AM, Steve Smith wrote: DDNAMEs are a pretty nice feature of z/OS! So you *don't* have to pass a bunch of (potentially very long) file names. DDNAMEs can be thought of as a limited form of environment variables. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Wed, 11 Jul 2018 11:40:19 -0400, Steve Smith wrote: >Not sure if this was pointed out before, but DDNAMEs are required by z/OS >access methods, not JCL. There is no reason these or dataset names need to >be arguments just because REXX is used instead of JCL. > Most programs that don't expose DDNAMEs externaly create them internally using DYNALLOC. This is true for z/OS Rexx, not for CMS Rexx. >DDNAMEs are a pretty nice feature of z/OS! So you *don't* have to pass a >bunch of (potentially very long) file names. DDNAMEs can be thought of as >a limited form of environment variables. > It stretches the understanding, but, yes. In the UNIX environment, descriptors perform much the same function as DDNAMES in the OS environment. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Not sure if this was pointed out before, but DDNAMEs are required by z/OS access methods, not JCL. There is no reason these or dataset names need to be arguments just because REXX is used instead of JCL. DDNAMEs are a pretty nice feature of z/OS! So you *don't* have to pass a bunch of (potentially very long) file names. DDNAMEs can be thought of as a limited form of environment variables. sas On Wed, Jul 11, 2018 at 10:51 AM, Hobart Spitz wrote: > Andrew wrote: > > ... > > >The connection between program (DDNAME) and resources (dataset etc.) is > nice too. In something like Rexx you need to pass the names as arguments > (JCL is >much better than one long command line) or hard code them. > > That's only because z/OS is so JCL oriented. Again, this works in IBM (and > shareholders) favor. It's harder to leave for another platform. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Andrew wrote:
>I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.
Then you haven't fully considered the alternatives. That's not a
criticism, just a statement of fact. How many of us really know how our
computers, cars, phones, bodies or anything else we live with day to day,
really work, at least until they don't, then we start caring.
Here's an actual example: I was riding in the back of an Uber recently,
and I felt every single bump, as if the chassis was bottoming out. I asked
some casual questions of the driver about the car. She said she bought it
used and tires kept exploding when she hit a pothole. I'd never had
exploding tire, so I suggested that the cause might be that her shocks
weren't not doing the job they were intended for, i.e. mitigating
irregularities in the roadway. (Consider a pothole a large value of
irregularity.)
The point is, you can proceed for a long time without understanding what
your tools are doing for you, but the day may come when you (or someone
else) will need to have that knowledge.
>In a previous job I tried to write scripts on a unix system to try to fix
tasks that had a tendency to open one file and then wait for another, where
multiple tasks >were deadlocking.
It may take a little more skill and experience to write in a real scripting
language than in JCL, but it should be done. I submit that this attitude
contributes to the high cost of running z/OS. The many things that happen
in batch are hidden, and IMHO, contribute to greater "large system effect"
than with leaner operating systems such as z/VM, *nix and *nix
derivatives. IBM and its stockholders love it when your company has to
spend more on hardware, especially when that hardware is so cheap to make
that they can afford to ship you 16 processors, when your company only
orders and pays for 1.
>This is so simple with JCL because you don't get one allocation until you
get them all.
That's what my suggested host command/function would do. It would probably
have a behaviour that would allow it to be used only once, to prevent
deadlocks, unless all previous ENQs were freed. The second use, without
FREE, could cause a JOB cancelation, possibly unconditionally, so that
well-meaning misuse would be discouraged, or, alternatively, only if the
ENQs could not be satisfied.
>The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is >much better than one long command line) or hard code them.
That's only because z/OS is so JCL oriented. Again, this works in IBM (and
shareholders) favor. It's harder to leave for another platform.
Gil wrote:
>Have you a realistic alternative?
For starters, consider something that uses REXX syntax and JCL semantics:
1.
*/* REXX */ *
2.
*arg String /* From SUBMIT or start task command. */ *
3.
*"jcl myjob: job (acct),'john smith',class=t,msgclass=h,notify="userid()" *
4.
*"jcl exec pgm=myprog,parm="date("s") *
5.
*"jcl sysprint: dd sysout=*" *
6. *...*
The JCL host command could create the exact same control blocks and
structures as the existing JCL statements today. When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup. All exits would be preserved so
that third-party software would still work unchanged. The JCL EXEC host
command could generate code to set RC.stepname supporting condition code
testing, and the JCL DD host command could set stepname.ddname.DSN, etc.,
to allow for reference to all parameters. This approach would, however,
limit the benefits of batch REXX.
I'm sure there are lots of other ways to do it. Use more DB2 and PDSEs. A
combination of REXX and PIPElines means that temporary datasets, and their
2 (or more) can be replaced with just one single character.
>In one case, I was able to enumerate a superset of the
>DSNs I might want to allocate in a Rexx step. I added EXEC
PGM=IEFBR14,COND=(0,LE)
>with DD statements for those at the end of the job just to avoid ENQ
surprises.
>JCL automates the enumeration of the ENQs; DYNALLOC, a newcomer, doesn't
>play by the old rules.
I use this technique when all else fails, and recommend it with one
exception. Put that those DDs in the first step of the job. You can FREE
something you won't need in the rest of the JOB, in case another
JOB/process might need it, without risking a deadly embrace.
I do advocate a combined REXX and PIPElines environment as a replacement
for JCL; z/VM works swimmingly with it. Perhaps z/OS fossilized thinking
is why the best things in z/OS (DB2, REXX, PIPElines) came from z/VM. We'd
all be just as happy if *nix could offer the same productivity and
performance benefits. Doing things character by character is just as bad
and old as JCL. That needs to change.
OREXXMan
JCL is the buggy whip of 21st century computing.
Re: Using JCL Symbld and TYPRUN=SCAN
On Sun, Jul 1, 2018 at 12:12 PM Hobart Spitz wrote: > )Why don't we just skip the JCL, and write our jobs in REXX? The two > > Here, here!! Actually, there is one thing that is critical to retiring > JCL. It's a host command that allows a REXX program to list and wait for > all it's datasets and their enqueues to be available. This is not trivial, > so that's why no installation has taken it on. I don't know why IBM keeps > shoe-horning new features with big astonishment factors into JCL. z/OS is > the only major platform with a separate batch-only language. > > Anyone want to write sn RFE? > > I very much agree that JCL needs to be retired. It has a long and not-so-lustrous career. However, at least for me, one major thing which needs to be a critical consideration is restarting a "batch process" (aka REXX program, shell script). There needs to be someway which will, like CA-11 for instance, track what DSNs / UNIX files were created so that they can be automatically deleted when it is necessary. The new process must have a monitor which will keep track of which "step" equivalent has executed and be able to do something like a CA-11 restart. This becomes very complicated if the new processor can do looping. I can envision a REXX like environment where you can something like: /* REXX batch process */ ADDRESS BATCH /* activate the BATCH environment */ DSNPATTERN='SOMEHLQ.PROCESS.**.INPUT' "FINDDSNS (DSNPATTERN) (STEM DSN." /* Above does a catalog search for the DSNs described in DSNPATTERN */ /* DSN.0 == Number of DSNs found */ /* DSN.? (1 to DSN.0) == DSN found */ "ENQDSN (ISTEM DSN. OSTEM DDN. TIMEOUT 3600" /* Above does a SYSDSN enqueue on all DSNs in the stem, waiting up to 3600 seconds -- 1 hour */ /* ISTEM is a REXX "array" of DSNs which are input to the ENQDSN OSTEM is a parallel REXX "array" of DDNs which are allocated to the corresponding ISTEM input DSN. */ IF RC <> 0 THEN DO; /* ENQ FAILED -- nothing allocated */ SAY "ENQ TIMED OUT -- ABORTING" EXIT 16 /* END BATCH PROCESS WITH CC OF 16 */ END DO DDN_NUM = 1 TO DDN.0 "REALLOC SYSIN " DDN.DDN_NUM /* The above does a FREE on SYSIN (unless OPEN) and reallocates DDN.DDN_NUM to the DDN of SYSIN -- assumes DDN is harded coded in the program */ ADDRESS ATTACH "SOMEPGM PARM TO SOMEPGM" /* standard BATCH parameter list */ "CKPT" /* tell the BATCH environment to "checkpoint" somewhere */ END The above is just some "off the cuff" thoughts and a simple example of how something _might_ look. The BATCH environment is the replacement for JCL. It somehow communicates either with the JES system record checkpoint information for "restarting" the batch process if something happens. I didn't go into this because I simply don't have any good ideas. -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Sun, 1 Jul 2018 13:11:27 -0400, Hobart Spitz wrote: >)Why don't we just skip the JCL, and write our jobs in REXX? The two > >Here, here!! Actually, there is one thing that is critical to retiring >JCL. It's a host command that allows a REXX program to list and wait for >all it's datasets and their enqueues to be available. This is not trivial, >so that's why no installation has taken it on. I don't know why IBM keeps >shoe-horning new features with big astonishment factors into JCL. z/OS is >the only major platform with a separate batch-only language. > >Anyone want to write sn RFE? > Have you a realistic alternative? In one case, I was able to enumerate a superset of the DSNs I might want to allocate in a Rexx step. I added EXEC PGM=IEFBR14,COND=(0,LE) with DD statements for those at the end of the job just to avoid ENQ surprises. JCL automates the enumeration of the ENQs; DYNALLOC, a newcomer, doesn't play by the old rules. I could envision an alternative to S99WTDSN, not requiring authorization, which would cause a wait unless that created a deadlock (recognizable as a cycle in the ENQ graph) and fail immediately if a deadlock was created. Still, lots of questions. Which job should fail? The newcomer to the party? Why? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
)Why don't we just skip the JCL, and write our jobs in REXX? The two Here, here!! Actually, there is one thing that is critical to retiring JCL. It's a host command that allows a REXX program to list and wait for all it's datasets and their enqueues to be available. This is not trivial, so that's why no installation has taken it on. I don't know why IBM keeps shoe-horning new features with big astonishment factors into JCL. z/OS is the only major platform with a separate batch-only language. Anyone want to write sn RFE? On 21 Jun 2018 9:48 pm, "Andrew Rowley" wrote: On 22/06/2018 11:21 AM, Steve Smith wrote: > Why don't we just skip the JCL, and write our jobs in REXX? The two > main things JCL does, EXEC and DD, are just as easy in REXX, (call, > alloc) with a ton more flexibility. EXPORT, SET, IF, and symbols are > lipstick for a pig. I actually like JCL. One of the things it does so well that no-one even notices is allocation of resources. In a previous job I tried to write scripts on a unix system to try to fix tasks that had a tendency to open one file and then wait for another, where multiple tasks were deadlocking. This is so simple with JCL because you don't get one allocation until you get them all. The connection between program (DDNAME) and resources (dataset etc.) is nice too. In something like Rexx you need to pass the names as arguments (JCL is much better than one long command line) or hard code them. -- Andrew Rowley Black Hill Software +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 22/06/2018 11:21 AM, Steve Smith wrote: Why don't we just skip the JCL, and write our jobs in REXX? The two main things JCL does, EXEC and DD, are just as easy in REXX, (call, alloc) with a ton more flexibility. EXPORT, SET, IF, and symbols are lipstick for a pig. I actually like JCL. One of the things it does so well that no-one even notices is allocation of resources. In a previous job I tried to write scripts on a unix system to try to fix tasks that had a tendency to open one file and then wait for another, where multiple tasks were deadlocking. This is so simple with JCL because you don't get one allocation until you get them all. The connection between program (DDNAME) and resources (dataset etc.) is nice too. In something like Rexx you need to pass the names as arguments (JCL is much better than one long command line) or hard code them. -- Andrew Rowley Black Hill Software +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Thu, 21 Jun 2018 21:21:56 -0400, Steve Smith wrote: >My only point was the SET wasn't needed the way I used symbols. It's >hardly any big deal if it's needed for library PROCs. The fact that >there doesn't seem to be any obvious logical reason for it, is just one >of things you take for granted with JCL. > Not logical, but diachronic. >Why don't we just skip the JCL, and write our jobs in REXX? The two >main things JCL does, EXEC and DD, are just as easy in REXX, (call, >alloc) with a ton more flexibility. EXPORT, SET, IF, and symbols are >lipstick for a pig. > (I use LINKMVS and BPXWDYN. No need for TSO.) What Rexx lacks is the multiple ENQ with S99WTDSN that prevents deadlocks. I could imagine this as an enhancement to BPXWDYN. >All you must keep in JCL is the JOB card, and a standard EXEC PGM=IRXJCL >+ SYSEXEC DD. Everything else you can code in an actual programming >language. > IRXJCL lacks support for //SYSEXEC DD *. You need at least an IEBUPDTE step to create a (temporary) SYSEXEC PDS. (There's an unsupported workaround.) >JCL is fun as a puzzle-solving activity (sometimes), but for busy people >trying to get their work done, it's been a black cloud since 1964. Even >Fred P. Brooks said he didn't like it. > Ipse dixit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
My only point was the SET wasn't needed the way I used symbols. It's hardly any big deal if it's needed for library PROCs. The fact that there doesn't seem to be any obvious logical reason for it, is just one of things you take for granted with JCL. Why don't we just skip the JCL, and write our jobs in REXX? The two main things JCL does, EXEC and DD, are just as easy in REXX, (call, alloc) with a ton more flexibility. EXPORT, SET, IF, and symbols are lipstick for a pig. All you must keep in JCL is the JOB card, and a standard EXEC PGM=IRXJCL + SYSEXEC DD. Everything else you can code in an actual programming language. JCL is fun as a puzzle-solving activity (sometimes), but for busy people trying to get their work done, it's been a black cloud since 1964. Even Fred P. Brooks said he didn't like it. sas On 6/21/2018 20:50, Paul Gilmartin wrote: On Fri, 22 Jun 2018 10:34:54 +1000, Andrew Rowley wrote: On 21/06/2018 11:05 PM, Steve Smith wrote: I've gotten good results with the EXPORT before the PROC Which means the EXPORT needs to be in the calling job, not the PROC. My examples used inline PROCs for convenience, but I was trying to do it with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the job needs to know exactly which variables the PROC needs exported, which negates some of the convenience of abstracting stuff into a PROC. Does it not suffice to code EXPORT before SET, but in the PROC? (But then are symbols exported to open code, outside the PROC?) The best solution seems to be SET VAR= in the PROC. Hardly practical if the vaue of VAR contains metacharacters. JCL sorely needs HLASM's DOUBLE BIF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Fri, 22 Jun 2018 10:34:54 +1000, Andrew Rowley wrote: >On 21/06/2018 11:05 PM, Steve Smith wrote: >> I've gotten good results with the EXPORT before the PROC > >Which means the EXPORT needs to be in the calling job, not the PROC. My >examples used inline PROCs for convenience, but I was trying to do it >with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the >job needs to know exactly which variables the PROC needs exported, which >negates some of the convenience of abstracting stuff into a PROC. > Does it not suffice to code EXPORT before SET, but in the PROC? (But then are symbols exported to open code, outside the PROC?) >The best solution seems to be SET VAR= in the PROC. > Hardly practical if the vaue of VAR contains metacharacters. JCL sorely needs HLASM's DOUBLE BIF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 21/06/2018 11:05 PM, Steve Smith wrote: I've gotten good results with the EXPORT before the PROC Which means the EXPORT needs to be in the calling job, not the PROC. My examples used inline PROCs for convenience, but I was trying to do it with a PROC in a PROCLIB. If the EXPORT needs to be before the PROC, the job needs to know exactly which variables the PROC needs exported, which negates some of the convenience of abstracting stuff into a PROC. The best solution seems to be SET VAR= in the PROC. -- Andrew Rowley Black Hill Software +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
I've gotten good results with the EXPORT before the PROC, this example is cut down from a working job: //TSRCMHL1 JOB 1000,STEVE.SMITH,NOTIFY=, // CLASS=C,MSGCLASS=X,COND=(1,LT) // EXPORT SYMLIST=(PFX,VER,REL,FIX) //HLDLIBS PROC PFX=RCM,VER=VV,REL=RR,FIX=TAC9 //AMS1EXEC PGM=IDCAMS,REGION=0M //SYSPRINT DD SYSOUT=* //SYSIN DD *,SYMBOLS=JCLONLY DELETE * SET MAXCC=0 //COPY1 EXEC PGM=IEBCOPY,REGION=0M //SYSPRINT DD SYSOUT=* //ASMIN DD DSN=RCM.WRK07,DISP=SHR //LOADINDD DSN=RCM.WRK07,DISP=SHR //ASMOUTDD DSN=,DISP=(NEW,CATLG), // UNIT=SYSDA,SPACE=(CYL,(5,10,1),RLSE), // DSNTYPE=LIBRARY,RECFM=FB,LRECL=80 //LOADOUT DD DSN=, // DISP=(NEW,CATLG), // UNIT=SYSDA,SPACE=(TRK,(30,20,3),RLSE), // RECFM=U,BLKSIZE=6233 //SYSIN DD DDNAME= // DD *,SYMBOLS=JCLONLY LOADLIB COPY INDD=LOADIN,OUTDD=LOADOUT SELECT MEMBER= //MKCASMIN DD * ASM COPY INDD=ASMIN,OUTDD=ASMOUT SELECT MEMBER=((RCM00222,MKC00222)) //RCMASMIN DD * ASM COPY INDD=ASMIN,OUTDD=ASMOUT SELECT MEMBER=RCM00222 //PEND //JS16730 EXEC HLDLIBS,PFX=RCM,VER=07,REL=05,FIX=TAC16730 //JS2740 EXEC HLDLIBS,PFX=MKC,VER=02,REL=05,FIX=MCA2740 //JS2741 EXEC HLDLIBS,PFX=MKC,VER=02,REL=06,FIX=MCA2741 //JS2742 EXEC HLDLIBS,PFX=MKC,VER=02,REL=07,FIX=MCA2742 //JS16731 EXEC HLDLIBS,PFX=RCM,VER=07,REL=07,FIX=TAC16731 // Ain't JCL fun! sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 21/06/2018 12:28 PM, Paul Gilmartin wrote: I believe that symbols assigned values in a PROC statement or in EXEC PRC= are local to that PROC (and its children?) Symbols assigned values in a SET statement within a PROC are global. Ugh! It may be better to eschew SET within a PROC; rather supply default values in the PROC header. Symbols in a PROC header don't work consistently. SET is required for predictable behaviour. //PROC1 PROC VVV= // EXPORT SYMLIST=VVV //PSTEP1 EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1 DD *,SYMBOLS=JCLONLY SYMBOL VVV= /* //SYSUT2 DD SYSOUT=* // PEND //JSTEP1 EXEC PROC1,VVV=VALUE1 //JSTEP2 EXEC PROC1,VVV=VALUE2 gives IEFC657I THE SYMBOL VVV WAS NOT USED for the first step, but not subsequent steps (occurring after the first proc's EXPORT SYMLIST=VVV). If symbol VVV is used in the JCL: //PROC1 PROC VVV=VPWRKA // EXPORT SYMLIST=VVV //PSTEP1 EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1 DD *,SYMBOLS=JCLONLY SYMBOL VVV= /* //SYSUT2 DD SYSOUT=* //DD1 DD DISP=(OLD,DELETE),UNIT=SYSDA,VOL=SER= // PEND //JSTEP1 EXEC PROC1,VVV=VPWRKB //JSTEP2 EXEC PROC1,VVV=VPWRKC gives output: SYMBOL VVV= SYMBOL VVV=VPWRKC The in stream symbol is not substituted in the first step but it is substituted correctly in subsequent steps. The JCL symbol is substituted as expected. If you SET VVV= the symbols are substituted as expected: //PROC1 PROC VVV=VPWRKA // EXPORT SYMLIST=VVV // SET VVV= //PSTEP1 EXEC PGM=IEBGENER //SYSPRINT DD DUMMY //SYSIN DD DUMMY //SYSUT1 DD *,SYMBOLS=JCLONLY SYMBOL VVV= /* //SYSUT2 DD SYSOUT=* // PEND //JSTEP1 EXEC PROC1,VVV=VPWRKB //JSTEP2 EXEC PROC1,VVV=VPWRKC SYMBOL VVV=VPWRKB SYMBOL VVV=VPWRKC Be careful. If the SYSIN appears within a PROC and different symbol values are in effect at various EXEC PRC=... statements, multiple copies of that SYSIN might need to be supplied for the various proc steps. If I have //DD1 DD DISP=(OLD,DELETE),UNIT=SYSDA,VOL=SER= I end up with multiple copies of that JCL statement with different values. I have no problem with multiple copies of the SYSIN, it is what I expected. -- Andrew Rowley Black Hill Software +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Lucas, Ok, without SYSAFF, the submitting system has a good chance to handle the job first, but I thought you meant to say that this was a rule. We have seen the opposite, maybe because of JESs loads, that another system than the submitting system handled most of the converts. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lucas Rosalen > Sent: 21 June, 2018 9:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Using JCL Symbld and TYPRUN=SCAN > > Thanks Kees, that's exactly what I tried to say and failed miserably :) > > > --- > *Lucas Rosalen* > rosalen.lu...@gmail.com / lucas.rosal...@ibm.com > http://br.linkedin.com/in/lrosalen > > > 2018-06-21 9:09 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM < > kees.verno...@klm.com>: > > > Lucas, > > > > I think this is a mis-interpretation of your observations: > > > > With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: > for > > convertor, interpretor and execution, so here you can be sure of the > > substituted values. > > > > Without /*JOBPARM SYSAFF: the job can be handled by any system in the > MAS > > for all 3 phases, so it can be submitted on system1, converted on > system 2 > > and executed on system 3. You will not know in advance which system > will do > > what. > > > > Kees. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] On > > > Behalf Of Lucas Rosalen > > > Sent: 21 June, 2018 8:57 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Using JCL Symbld and TYPRUN=SCAN > > > > > > On the side topic... > > > > > > Based on our latest "experience": > > > - without /*JOBPARM SYSAFF: symbols got resolved in the submitting > LPAR, > > > which caused some problems as they were different from the executing > > > LPAR > > > (and used as a dataset qualifier); > > > - with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR > > > (even > > > with SYSAFF=*); > > > > > > I also don't know about the documentation, just learned from a > colleague > > > that had worked on our issue. > > > > > > > > > > > > > --- > > > *Lucas Rosalen* > > > rosalen.lu...@gmail.com / lucas.rosal...@ibm.com > > > http://br.linkedin.com/in/lrosalen > > > > > > > > > 2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht < > > > elardus.engelbre...@sita.co.za>: > > > > > > > Andrew Rowley wrote: > > > > > > > > >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN > and > > > place > > > > it in a JCL comment): > > > > >> //* DELETE KVPO.MOST.DB2DATA. > > > > >> //SYSIN DD *,SYMBOLS=(JCLONLY,X) > > > > >> SET MAXCC = 0 > > > > > > > > >Unfortunately that may not work because the symbols in SYSIN are > not > > > > substituted the same way as in the regular JCL. I have been > playing > > > around > > > > with them and my conclusion is that the whole feature seems to > have > > > been > > > > badly thought out. > > > > > > > > Thanks for this reminder. I remember that I also discovered that > > > > substition is not always correct, but I was too busy to follow it > up. > > > > > > > > > > > > >If IBM had omitted some features, e.g. system symbols on the > > > execution > > > > system and instead substituted the symbols at the same time as the > > > symbols > > > > in the rest of the JCL, they would have lost maybe 10% of the > > > usefulness > > > > but decreased the astonishment by 90%. > > > > > > > > Which brings another question - I am just curious - Where are the > > > Symbols > > > > resolved? At the submitting LPAR or at the Executing LPAR? Or is > the > > > > '/*JOBPARM SYSAFF=' used to determine the LPAR where the > Symbols > > > are > > > > to be resolved/substituted? > > > > > > > > I
Re: Using JCL Symbld and TYPRUN=SCAN
Thanks Kees, that's exactly what I tried to say and failed miserably :) --- *Lucas Rosalen* rosalen.lu...@gmail.com / lucas.rosal...@ibm.com http://br.linkedin.com/in/lrosalen 2018-06-21 9:09 GMT+02:00 Vernooij, Kees (ITOPT1) - KLM < kees.verno...@klm.com>: > Lucas, > > I think this is a mis-interpretation of your observations: > > With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: for > convertor, interpretor and execution, so here you can be sure of the > substituted values. > > Without /*JOBPARM SYSAFF: the job can be handled by any system in the MAS > for all 3 phases, so it can be submitted on system1, converted on system 2 > and executed on system 3. You will not know in advance which system will do > what. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Lucas Rosalen > > Sent: 21 June, 2018 8:57 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Using JCL Symbld and TYPRUN=SCAN > > > > On the side topic... > > > > Based on our latest "experience": > > - without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR, > > which caused some problems as they were different from the executing > > LPAR > > (and used as a dataset qualifier); > > - with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR > > (even > > with SYSAFF=*); > > > > I also don't know about the documentation, just learned from a colleague > > that had worked on our issue. > > > > > > > > --- > > *Lucas Rosalen* > > rosalen.lu...@gmail.com / lucas.rosal...@ibm.com > > http://br.linkedin.com/in/lrosalen > > > > > > 2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht < > > elardus.engelbre...@sita.co.za>: > > > > > Andrew Rowley wrote: > > > > > > >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and > > place > > > it in a JCL comment): > > > >> //* DELETE KVPO.MOST.DB2DATA. > > > >> //SYSIN DD *,SYMBOLS=(JCLONLY,X) > > > >> SET MAXCC = 0 > > > > > > >Unfortunately that may not work because the symbols in SYSIN are not > > > substituted the same way as in the regular JCL. I have been playing > > around > > > with them and my conclusion is that the whole feature seems to have > > been > > > badly thought out. > > > > > > Thanks for this reminder. I remember that I also discovered that > > > substition is not always correct, but I was too busy to follow it up. > > > > > > > > > >If IBM had omitted some features, e.g. system symbols on the > > execution > > > system and instead substituted the symbols at the same time as the > > symbols > > > in the rest of the JCL, they would have lost maybe 10% of the > > usefulness > > > but decreased the astonishment by 90%. > > > > > > Which brings another question - I am just curious - Where are the > > Symbols > > > resolved? At the submitting LPAR or at the Executing LPAR? Or is the > > > '/*JOBPARM SYSAFF=' used to determine the LPAR where the Symbols > > are > > > to be resolved/substituted? > > > > > > I am asking, because there are Symbols unique for a LPAR, like this: > > > > > > D SYMBOLS > > > IEA007I STATIC SYSTEM SYMBOL VALUES > > >= "2" > > > = "C4" <--- Unique per LPAR > > >= "" <--- Unique per LPAR > > > > > > If that is documented, I must missed it somewhere ... > > > > > > Sorry for this topic drift, but ... ;-) > > > > > > Groete / Greetings > > > Elardus Engelbrecht > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ***
Re: Using JCL Symbld and TYPRUN=SCAN
Lucas, I think this is a mis-interpretation of your observations: With /*JOBPARM SYSAFF: the job has affinity to the mentioned system: for convertor, interpretor and execution, so here you can be sure of the substituted values. Without /*JOBPARM SYSAFF: the job can be handled by any system in the MAS for all 3 phases, so it can be submitted on system1, converted on system 2 and executed on system 3. You will not know in advance which system will do what. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lucas Rosalen > Sent: 21 June, 2018 8:57 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Using JCL Symbld and TYPRUN=SCAN > > On the side topic... > > Based on our latest "experience": > - without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR, > which caused some problems as they were different from the executing > LPAR > (and used as a dataset qualifier); > - with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR > (even > with SYSAFF=*); > > I also don't know about the documentation, just learned from a colleague > that had worked on our issue. > > > > --- > *Lucas Rosalen* > rosalen.lu...@gmail.com / lucas.rosal...@ibm.com > http://br.linkedin.com/in/lrosalen > > > 2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht < > elardus.engelbre...@sita.co.za>: > > > Andrew Rowley wrote: > > > > >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and > place > > it in a JCL comment): > > >> //* DELETE KVPO.MOST.DB2DATA. > > >> //SYSIN DD *,SYMBOLS=(JCLONLY,X) > > >> SET MAXCC = 0 > > > > >Unfortunately that may not work because the symbols in SYSIN are not > > substituted the same way as in the regular JCL. I have been playing > around > > with them and my conclusion is that the whole feature seems to have > been > > badly thought out. > > > > Thanks for this reminder. I remember that I also discovered that > > substition is not always correct, but I was too busy to follow it up. > > > > > > >If IBM had omitted some features, e.g. system symbols on the > execution > > system and instead substituted the symbols at the same time as the > symbols > > in the rest of the JCL, they would have lost maybe 10% of the > usefulness > > but decreased the astonishment by 90%. > > > > Which brings another question - I am just curious - Where are the > Symbols > > resolved? At the submitting LPAR or at the Executing LPAR? Or is the > > '/*JOBPARM SYSAFF=' used to determine the LPAR where the Symbols > are > > to be resolved/substituted? > > > > I am asking, because there are Symbols unique for a LPAR, like this: > > > > D SYMBOLS > > IEA007I STATIC SYSTEM SYMBOL VALUES > >= "2" > > = "C4" <--- Unique per LPAR > >= "" <--- Unique per LPAR > > > > If that is documented, I must missed it somewhere ... > > > > Sorry for this topic drift, but ... ;-) > > > > Groete / Greetings > > Elardus Engelbrecht > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On the side topic... Based on our latest "experience": - without /*JOBPARM SYSAFF: symbols got resolved in the submitting LPAR, which caused some problems as they were different from the executing LPAR (and used as a dataset qualifier); - with /*JOBPARM SYSAFF: symbols are resolved in the executing LPAR (even with SYSAFF=*); I also don't know about the documentation, just learned from a colleague that had worked on our issue. --- *Lucas Rosalen* rosalen.lu...@gmail.com / lucas.rosal...@ibm.com http://br.linkedin.com/in/lrosalen 2018-06-21 8:16 GMT+02:00 Elardus Engelbrecht < elardus.engelbre...@sita.co.za>: > Andrew Rowley wrote: > > >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place > it in a JCL comment): > >> //* DELETE KVPO.MOST.DB2DATA. > >> //SYSIN DD *,SYMBOLS=(JCLONLY,X) > >> SET MAXCC = 0 > > >Unfortunately that may not work because the symbols in SYSIN are not > substituted the same way as in the regular JCL. I have been playing around > with them and my conclusion is that the whole feature seems to have been > badly thought out. > > Thanks for this reminder. I remember that I also discovered that > substition is not always correct, but I was too busy to follow it up. > > > >If IBM had omitted some features, e.g. system symbols on the execution > system and instead substituted the symbols at the same time as the symbols > in the rest of the JCL, they would have lost maybe 10% of the usefulness > but decreased the astonishment by 90%. > > Which brings another question - I am just curious - Where are the Symbols > resolved? At the submitting LPAR or at the Executing LPAR? Or is the > '/*JOBPARM SYSAFF=' used to determine the LPAR where the Symbols are > to be resolved/substituted? > > I am asking, because there are Symbols unique for a LPAR, like this: > > D SYMBOLS > IEA007I STATIC SYSTEM SYMBOL VALUES >= "2" > = "C4" <--- Unique per LPAR >= "" <--- Unique per LPAR > > If that is documented, I must missed it somewhere ... > > Sorry for this topic drift, but ... ;-) > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Andrew Rowley wrote: >> to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in >> a JCL comment): >> //* DELETE KVPO.MOST.DB2DATA. >> //SYSIN DD *,SYMBOLS=(JCLONLY,X) >> SET MAXCC = 0 >Unfortunately that may not work because the symbols in SYSIN are not >substituted the same way as in the regular JCL. I have been playing around >with them and my conclusion is that the whole feature seems to have been badly >thought out. Thanks for this reminder. I remember that I also discovered that substition is not always correct, but I was too busy to follow it up. >If IBM had omitted some features, e.g. system symbols on the execution system >and instead substituted the symbols at the same time as the symbols in the >rest of the JCL, they would have lost maybe 10% of the usefulness but >decreased the astonishment by 90%. Which brings another question - I am just curious - Where are the Symbols resolved? At the submitting LPAR or at the Executing LPAR? Or is the '/*JOBPARM SYSAFF=' used to determine the LPAR where the Symbols are to be resolved/substituted? I am asking, because there are Symbols unique for a LPAR, like this: D SYMBOLS IEA007I STATIC SYSTEM SYMBOL VALUES = "2" = "C4" <--- Unique per LPAR = "" <--- Unique per LPAR If that is documented, I must missed it somewhere ... Sorry for this topic drift, but ... ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
> Well, I think "amazing" may be a bit much. Maybe EZACFMS1 predates DD > SYMBOLS=, but it's pretty easy to just use it: > > // EXEC PGM=IEBGENER > //SYSUT1 DD DATA,SYMBOLS=EXECSYS > ...your job here > /* > //SYSUT2 DD SYSOUT=* Or just use the logging-DDname option of the SYMBOLS= parameter. Then you don't even need an additional step in the JCL: //SYSIN DD *,SYMBOLS=(JCLONLY,TRACEDD) Input with variables... /* //TRACEDD SYSOUT=* - ATTENTION: The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Thu, 21 Jun 2018 10:45:01 +1000, Andrew Rowley wrote:
>
>Unfortunately [ ... ] the symbols in SYSIN are not
>substituted the same way as in the regular JCL. I have been playing
>around with them and my conclusion is that the whole feature seems to
>have been badly thought out.
>
Yes.
>- Symbols in in stream data are not necessarily substituted with the
>same value as the same symbol in the JCL of the same step
>
o First, PROCs are expanded by the converter at the point of EXEC PRC=...
o Then, symbols in JCL statements are resolved to the last value assigned
before the point of reference.
o Symbols in SYSIN are resolved to the last value assigned before the next
EXEC PGM... statement. Those steeped in MVS internals ("Kool-Aid") say
this makes perfect sense. To normal people it's utter nonsense.
>- Symbols "leak" from step to step and from PROCs into the main JCL, so
>if you modify or add a symbol in a PROC you can break subsequent steps
>in any job that calls that PROC.
>
I believe that symbols assigned values in a PROC statement or in EXEC PRC=
are local to that PROC (and its children?) Symbols assigned values in a SET
statement within a PROC are global. Ugh! It may be better to eschew SET
within a PROC; rather supply default values in the PROC header.
>If IBM had omitted some features, e.g. system symbols on the execution
>system and instead substituted the symbols at the same time as the
>symbols in the rest of the JCL, they would have lost maybe 10% of the
>usefulness but decreased the astonishment by 90%.
>
Be careful. If the SYSIN appears within a PROC and different symbol values
are in effect at various EXEC PRC=... statements, multiple copies of that
SYSIN might need to be supplied for the various proc steps. But the effect
could be realized by passing along with each reference to that SYSIN a list
of name-value pairs of symbols used in that SYSIN, with the values at the
point //SYSIN DD * appears in the JCL source.
>The good news is that the syntax probably allows an easy fix in a new
>version: a new value such as SYMBOLS=(JCLCNVT) where symbols are
>substituted at the same time with the same logic as the rest of the JCL.
>
>Please IBM?
>
They'd only need to do it right.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On 20/06/2018 8:53 PM, Elardus Engelbrecht wrote: Easy, a quick and dirty trick I sometimes do is this little change: //SYSIN DD *,SYMBOLS=(JCLONLY,X) DELETE KVPO.MOST.DB2DATA. SET MAXCC = 0 to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in a JCL comment): //* DELETE KVPO.MOST.DB2DATA. //SYSIN DD *,SYMBOLS=(JCLONLY,X) SET MAXCC = 0 Unfortunately that may not work because the symbols in SYSIN are not substituted the same way as in the regular JCL. I have been playing around with them and my conclusion is that the whole feature seems to have been badly thought out. - Symbols in in stream data are not necessarily substituted with the same value as the same symbol in the JCL of the same step - Symbols "leak" from step to step and from PROCs into the main JCL, so if you modify or add a symbol in a PROC you can break subsequent steps in any job that calls that PROC. If IBM had omitted some features, e.g. system symbols on the execution system and instead substituted the symbols at the same time as the symbols in the rest of the JCL, they would have lost maybe 10% of the usefulness but decreased the astonishment by 90%. The good news is that the syntax probably allows an easy fix in a new version: a new value such as SYMBOLS=(JCLCNVT) where symbols are substituted at the same time with the same logic as the rest of the JCL. Please IBM? -- Andrew Rowley Black Hill Software +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
On Wed, 20 Jun 2018 18:35:01 -0400, Steve Smith wrote: >Actually, the upshot is exactly not that. Symbols in SYSIN are always >resolved when requested by SYMBOLS=. The program that reads that SYSIN >never sees any symbols. > >The 2nd parm of SYMBOLS is a DDname for a substitution report. I would >have assumed you'd get that regardless, but evidently, the SYSIN file has >to be OPENed to get the substitution report. > I suspect that substitution is lazy, performed at the last possible moment. For example if the SYSIN is in a PROC called multiple times with different values of a symbol in effect, won't different executions show those different values substituted? Even more, it's possible to cause a (simulated) I/O error if substitution causes an overlong line. Will lines prior to that point be read correctly? >On Wed, Jun 20, 2018 at 5:35 PM, Jesse 1 Robinson wrote: > >> I think the upshot here is that support for symbols in *data* is a >> function of the program being executed. The 'system' will resolve symbols >> encountered in JCL, but the 'application' has to resolve symbols read from, >> We might quibble about the distinction between 'system' and 'application'. I believe the substitution is done by the access method or JES. Is that 'system' or 'application'? >> say, SYSIN. That's why TYPRUN=SCAN will not show resolved symbols in data: >> the program is not actually executed. Whether it's EZACFSM1 or IEBGENER, >> the program has to run in order to resolve symbols. > TYPRUN=SCAN is a farce; increasingly so as new features appear in JCL and SCAN (SCAM?) fails to accommodate them. But it never reported things as basic as overlong qualifiers in data set names. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Actually, the upshot is exactly not that. Symbols in SYSIN are always resolved when requested by SYMBOLS=. The program that reads that SYSIN never sees any symbols. The 2nd parm of SYMBOLS is a DDname for a substitution report. I would have assumed you'd get that regardless, but evidently, the SYSIN file has to be OPENed to get the substitution report. sas On Wed, Jun 20, 2018 at 5:35 PM, Jesse 1 Robinson wrote: > I think the upshot here is that support for symbols in *data* is a > function of the program being executed. The 'system' will resolve symbols > encountered in JCL, but the 'application' has to resolve symbols read from, > say, SYSIN. That's why TYPRUN=SCAN will not show resolved symbols in data: > the program is not actually executed. Whether it's EZACFSM1 or IEBGENER, > the program has to run in order to resolve symbols. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
I think the upshot here is that support for symbols in *data* is a function of the program being executed. The 'system' will resolve symbols encountered in JCL, but the 'application' has to resolve symbols read from, say, SYSIN. That's why TYPRUN=SCAN will not show resolved symbols in data: the program is not actually executed. Whether it's EZACFSM1 or IEBGENER, the program has to run in order to resolve symbols. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Wednesday, June 20, 2018 11:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Using JCL Symbld and TYPRUN=SCAN Well, I think "amazing" may be a bit much. Maybe EZACFMS1 predates DD SYMBOLS=, but it's pretty easy to just use it: // EXEC PGM=IEBGENER //SYSUT1 DD DATA,SYMBOLS=EXECSYS ...your job here /* //SYSUT2 DD SYSOUT=* sas On Wed, Jun 20, 2018 at 1:50 PM, Sri h Kolusu wrote: > > Where is that EZACFSM1 thing documented? > > Elardus, > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3. > 0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm > > I used to use the program EZACFSM1 before the EXPORT enhancements came > in as it supports both static and dynamic symbols. > > sample > > //STEP0100 EXEC PGM=EZACFSM1 > //SYSOUT DD SYSOUT=* > //SYSINDD DATA,DLM=@@ > CURRENT DATE IS : > CURRENT JULIAN DAY OF YEAR IS : > CURRENT DAY OF THE WEEKIS : > CURRENT YEAR IS : > CURRENT DAYIS : > CURRENT MONTH IS : > CURRENT TIME IS : > CURRENT HOUR IS : > CURRENT MINUTE IS : > CURRENT SECONDSIS : > CURRENT JOBNAMEIS : > @@ > > > Thanks, > Kolusu > > IBM Mainframe Discussion List wrote on > 06/20/2018 10:26:15 AM: > > > From: Elardus Engelbrecht > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 06/20/2018 10:27 AM > > Subject: Re: Using JCL Symbld and TYPRUN=SCAN Sent by: IBM Mainframe > > Discussion List > > > > Sri h Kolusu wrote: > > > > >If you are interested to see the symbol substitution then you can > > use the EZACFSM1 symbol translator utility. > > > > My oh my! That is amazing! > > > > Where is that EZACFSM1 thing documented? > > > > I really appreciate your most helpful reply. I am really humbled by > > your kind reply. I believe all in IBM-MAIN would also be grateful > > for your post. > > > > Thanks again! > > > > Groete / Greetings > > Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Well, I think "amazing" may be a bit much. Maybe EZACFMS1 predates DD SYMBOLS=, but it's pretty easy to just use it: // EXEC PGM=IEBGENER //SYSUT1 DD DATA,SYMBOLS=EXECSYS ...your job here /* //SYSUT2 DD SYSOUT=* sas On Wed, Jun 20, 2018 at 1:50 PM, Sri h Kolusu wrote: > > Where is that EZACFSM1 thing documented? > > Elardus, > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3. > 0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm > > I used to use the program EZACFSM1 before the EXPORT enhancements came in > as it supports both static and dynamic symbols. > > sample > > //STEP0100 EXEC PGM=EZACFSM1 > //SYSOUT DD SYSOUT=* > //SYSINDD DATA,DLM=@@ > CURRENT DATE IS : > CURRENT JULIAN DAY OF YEAR IS : > CURRENT DAY OF THE WEEKIS : > CURRENT YEAR IS : > CURRENT DAYIS : > CURRENT MONTH IS : > CURRENT TIME IS : > CURRENT HOUR IS : > CURRENT MINUTE IS : > CURRENT SECONDSIS : > CURRENT JOBNAMEIS : > @@ > > > Thanks, > Kolusu > > IBM Mainframe Discussion List wrote on > 06/20/2018 10:26:15 AM: > > > From: Elardus Engelbrecht > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 06/20/2018 10:27 AM > > Subject: Re: Using JCL Symbld and TYPRUN=SCAN > > Sent by: IBM Mainframe Discussion List > > > > Sri h Kolusu wrote: > > > > >If you are interested to see the symbol substitution then you can > > use the EZACFSM1 symbol translator utility. > > > > My oh my! That is amazing! > > > > Where is that EZACFSM1 thing documented? > > > > I really appreciate your most helpful reply. I am really humbled by > > your kind reply. I believe all in IBM-MAIN would also be grateful > > for your post. > > > > Thanks again! > > > > Groete / Greetings > > Elardus Engelbrecht > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
> Where is that EZACFSM1 thing documented? Elardus, https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm I used to use the program EZACFSM1 before the EXPORT enhancements came in as it supports both static and dynamic symbols. sample //STEP0100 EXEC PGM=EZACFSM1 //SYSOUT DD SYSOUT=* //SYSINDD DATA,DLM=@@ CURRENT DATE IS : CURRENT JULIAN DAY OF YEAR IS : CURRENT DAY OF THE WEEKIS : CURRENT YEAR IS : CURRENT DAYIS : CURRENT MONTH IS : CURRENT TIME IS : CURRENT HOUR IS : CURRENT MINUTE IS : CURRENT SECONDSIS : CURRENT JOBNAMEIS : @@ Thanks, Kolusu IBM Mainframe Discussion List wrote on 06/20/2018 10:26:15 AM: > From: Elardus Engelbrecht > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/20/2018 10:27 AM > Subject: Re: Using JCL Symbld and TYPRUN=SCAN > Sent by: IBM Mainframe Discussion List > > Sri h Kolusu wrote: > > >If you are interested to see the symbol substitution then you can > use the EZACFSM1 symbol translator utility. > > My oh my! That is amazing! > > Where is that EZACFSM1 thing documented? > > I really appreciate your most helpful reply. I am really humbled by > your kind reply. I believe all in IBM-MAIN would also be grateful > for your post. > > Thanks again! > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Yes, thank you so very much Sri! It is apparently documented in "z/OS Communications Server: IP Configuration Guide": z/OS 2.1: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/ip_mvs_system_symbols.htm z/OS 2.2: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/ip_mvs_system_symbols.htm z/OS 2.3: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halz002/ip_mvs_system_symbols.htm Heck of a place to hide such a useful little utility. Why not at least a reference in the JCL reference manual or at least in the JCL User's Guide? No application programmer would ever even accidentally find it in the CS manuals, they would never think to look there. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Wednesday, June 20, 2018 1:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using JCL Symbld and TYPRUN=SCAN EXTERNAL EMAIL Sri h Kolusu wrote: >If you are interested to see the symbol substitution then you can use the >EZACFSM1 symbol translator utility. My oh my! That is amazing! Where is that EZACFSM1 thing documented? I really appreciate your most helpful reply. I am really humbled by your kind reply. I believe all in IBM-MAIN would also be grateful for your post. Thanks again! Groete / Greetings Elardus Engelbrecht -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
I learned something very useful here...thanks, Kolusu! On Wed, Jun 20, 2018 at 1:26 PM Elardus Engelbrecht < elardus.engelbre...@sita.co.za> wrote: > Sri h Kolusu wrote: > > >If you are interested to see the symbol substitution then you can use the > EZACFSM1 symbol translator utility. > > My oh my! That is amazing! > > Where is that EZACFSM1 thing documented? > > I really appreciate your most helpful reply. I am really humbled by your > kind reply. I believe all in IBM-MAIN would also be grateful for your post. > > Thanks again! > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Sri h Kolusu wrote: >If you are interested to see the symbol substitution then you can use the >EZACFSM1 symbol translator utility. My oh my! That is amazing! Where is that EZACFSM1 thing documented? I really appreciate your most helpful reply. I am really humbled by your kind reply. I believe all in IBM-MAIN would also be grateful for your post. Thanks again! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
>> Do you know of a way to check the parameter substitution in DD *? If you are interested to see the symbol substitution then you can use the EZACFSM1 symbol translator utility. Once you have verified the symbols are substituted correctly then you can route that to a dataset and use that as input sysin to your IDCAMS step. Here is an example. //DOALL PROC LVL4=LVL4,PART=PART // EXPORT SYMLIST=(LVL4,PART) // SET LVL4= // SET PART= //* //STEP0100 EXEC PGM=EZACFSM1 //SYSOUT DD SYSOUT=* //SYSINDD DATA,DLM=@@,SYMBOLS=JCLONLY DELETE KVPO.MOST.DB2DATA. SET MAXCC = 0 @@ //DOALL PEND //D1 EXEC DOALL,LVL4=PKVS1073,PART=PART1 Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
PROJCL (ASG) , CTL-J(BMC), CA-JCLCHECK. Probably some more that don't immediately come to mind. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gadi Ben-Avi Sent: Wednesday, June 20, 2018 2:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using JCL Symbld and TYPRUN=SCAN Thanks, Do you know of a way to check the parameter substitution in DD *? Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Wednesday, June 20, 2018 10:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using JCL Symbld and TYPRUN=SCAN Gadi Ben-Avi wrote: >The variables in the IDCAMS DELETE statement were not substituted. >When I ran the job without TYPRUN=SCAN, the variables were substituted. >Is there a way to have the variables get substituted, without actually running >the job. No. This is both WAD and BAD. In the JCL Ref this is stated, 'TYPRUN=SCAN checks the JCL only through the converter, not the interpreter.' >This is running in z/OS v2.2 And older versions too. One thread about this same problem was around July 2012 where with TYPRUN=SCAN, you could not see the SYSIN contents unless you use INPUT ON and then use ST in SDSF. ... and in that thread 'Show the //SYSIN DD * lines when using TYPRUN=SCAN?', there are two important comments amongst others: >TYPRUN=SCAN is only JCL checking and so will not really "show" the output of >the SYSIN. >TYPRUN=SCAN's "checking" is a bad joke. IIRC, it fails to report errors as >fundamental as DSNAME >44 characters. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
That's a good way to bypass it Thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Wednesday, June 20, 2018 1:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using JCL Symbld and TYPRUN=SCAN Gadi Ben-Avi wrote: >Do you know of a way to check the parameter substitution in DD *? Easy, a quick and dirty trick I sometimes do is this little change: //SYSIN DD *,SYMBOLS=(JCLONLY,X) DELETE KVPO.MOST.DB2DATA. SET MAXCC = 0 to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in a JCL comment): //* DELETE KVPO.MOST.DB2DATA. //SYSIN DD *,SYMBOLS=(JCLONLY,X) SET MAXCC = 0 Just submit that step (with or without TYPRUN) and if you see the substition is right, then submit the whole job with the correct SYSIN contents. That is a mild, but clean PITA... ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Elardus Engelbrechtwrote: >>Do you know of a way to check the parameter substitution in DD *? >Easy, a quick and dirty trick I sometimes do is this little change: >//SYSIN DD *,SYMBOLS=(JCLONLY,X) > DELETE KVPO.MOST.DB2DATA. >SET MAXCC = 0 >to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in a >JCL comment): >//* DELETE KVPO.MOST.DB2DATA. >//SYSIN DD *,SYMBOLS=(JCLONLY,X) >SET MAXCC = 0 >Just submit that step (with or without TYPRUN) and if you see the substition >is right, then submit the whole job with the correct SYSIN contents. What I wrote is not always 100% correct, sorry. I must also added, that if substition test is not working, I just submit a IEFBR14 job with the real DD (not in comments) and watch out for any 'IEFC653I SUBSTITUTION JCL' messages. PS: I don't have a JCL scanner product or something like that which could make your TYPRUN=SCAN and SYSIN easier. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Gadi Ben-Avi wrote: >Do you know of a way to check the parameter substitution in DD *? Easy, a quick and dirty trick I sometimes do is this little change: //SYSIN DD *,SYMBOLS=(JCLONLY,X) DELETE KVPO.MOST.DB2DATA. SET MAXCC = 0 to this one (clear out the SYSIN - at least for IDCAMS SYSIN and place it in a JCL comment): //* DELETE KVPO.MOST.DB2DATA. //SYSIN DD *,SYMBOLS=(JCLONLY,X) SET MAXCC = 0 Just submit that step (with or without TYPRUN) and if you see the substition is right, then submit the whole job with the correct SYSIN contents. That is a mild, but clean PITA... ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
I have had to do the indirection described in this document to make it work. http://www-01.ibm.com/support/docview.wss?uid=isg1OA47958 Alan From: Gadi Ben-Avi Sent: Tuesday, June 19, 2018 22:59 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Using JCL Symbld and TYPRUN=SCAN Hi, I am trying to create a procedure that receives parameters and then uses the values as the input for some steps. This is part of the procedure. //DOALL PROC LVL4=LVL4,PART=PART // EXPORT SYMLIST=(LVL4,PART) // SET LVL4= // SET PART= //DEL EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //X DD SYSOUT=X //SYSIN DD *,SYMBOLS=(JCLONLY,X) DELETE KVPO.MOST.DB2DATA. SET MAXCC = 0 //DOALL PEND When I tried running this using //G110FT24 JOB (00),'GET',CLASS=X,MSGCLASS=X,PRTY=9, // NOTIFY= TYPRUN=SCAN // JCLLIB ORDER=(SYSG.DB2.UNLOAD) //D1 EXEC DOALL,LVL4=PKVS1073,PART=PART1 The variables in the IDCAMS DELETE statement were not substituted. When I ran the job without TYPRUN=SCAN, the variables were substituted. Is there a way to have the variables get substituted, without actually running the job. This is running in z/OS v2.2 Gadi ? ?? ? ?? ??? ??? ?? ? ??? ?? ??. ?? , ?? ??? ?, ??? ? ?? ??? ? ?? ?? ?. ? ? ?? ?? ?? ?? ?? ??? ??? ???, ?/?? ?, ? ?? ? ? ? ? ?? ?? ? ??? ?/?? ?? ?? ??. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Thanks, Do you know of a way to check the parameter substitution in DD *? Gadi -Original Message- From: IBM Mainframe Discussion List On Behalf Of Elardus Engelbrecht Sent: Wednesday, June 20, 2018 10:32 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Using JCL Symbld and TYPRUN=SCAN Gadi Ben-Avi wrote: >The variables in the IDCAMS DELETE statement were not substituted. >When I ran the job without TYPRUN=SCAN, the variables were substituted. >Is there a way to have the variables get substituted, without actually running >the job. No. This is both WAD and BAD. In the JCL Ref this is stated, 'TYPRUN=SCAN checks the JCL only through the converter, not the interpreter.' >This is running in z/OS v2.2 And older versions too. One thread about this same problem was around July 2012 where with TYPRUN=SCAN, you could not see the SYSIN contents unless you use INPUT ON and then use ST in SDSF. ... and in that thread 'Show the //SYSIN DD * lines when using TYPRUN=SCAN?', there are two important comments amongst others: >TYPRUN=SCAN is only JCL checking and so will not really "show" the output of >the SYSIN. >TYPRUN=SCAN's "checking" is a bad joke. IIRC, it fails to report errors as >fundamental as DSNAME >44 characters. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN הודעה זו נשלחה אליך מטעם חברה בקבוצת מלם תים וייתכן שהיא מוגנת תחת סודיות מסחרית. כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשה החתימה של החברה. החברה רשאית לנטר כל תכתובת העוברת בשרתיה והיא לא תישא באחריות לכל נזק, ו/או אובדן, שיבוש או פגיעה במידע כלשהו שנגרם מסיבות של תקיפה חיצונית ו/או זדונית על הארגון. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using JCL Symbld and TYPRUN=SCAN
Gadi Ben-Avi wrote: >The variables in the IDCAMS DELETE statement were not substituted. >When I ran the job without TYPRUN=SCAN, the variables were substituted. >Is there a way to have the variables get substituted, without actually running >the job. No. This is both WAD and BAD. In the JCL Ref this is stated, 'TYPRUN=SCAN checks the JCL only through the converter, not the interpreter.' >This is running in z/OS v2.2 And older versions too. One thread about this same problem was around July 2012 where with TYPRUN=SCAN, you could not see the SYSIN contents unless you use INPUT ON and then use ST in SDSF. ... and in that thread 'Show the //SYSIN DD * lines when using TYPRUN=SCAN?', there are two important comments amongst others: >TYPRUN=SCAN is only JCL checking and so will not really "show" the output of >the SYSIN. >TYPRUN=SCAN's "checking" is a bad joke. IIRC, it fails to report errors as >fundamental as DSNAME >44 characters. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
