Re: PARMDD and Symbols in a Started PROC
No. is perfectly valid in a started task, and the keywords that don't have special meaning go on the generated EXEC statements. In particular, keywords that are valid on a DD go on IEFRDER. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Thursday, February 14, 2019 4:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC On Thu, 14 Feb 2019 13:07:07 -0800, Charles Mills wrote: >I think I could have done > >//jobname JOB ... >// EXPORT SYMLIST=* >//procname PROC ... Maybe. I had a similar problem a few years ago, but in my case, I had a PROC that was used in some jobs. I don't remember if I tried using the EXPORT in each of the jobs that invoked the PROC. >But I have never coded a started PROC with a JOB (and I know you can, but it >was just a wormhole I did not want to go down at this moment) IIRC, when you code a started job, you don't use PROC. When you start the task, specifying PARM1=value1,etc., it inserts a SET statement after the JOB card. I don't know how you would code default values for your parameters. >so I did more or less what Tom suggests. > >//procname PROC PARM1=value1,PARM2=value2 >// EXPORT SYMLIST=* >// SET $PARM1=PARM1 >// SET $PARM2=PARM2 >... >//MYPARMDD DD *,SYMBOLS=JCLONLY > $PARM1,$PARM2,... I did something like that too, but then I found out (at the suggestion of IBM) that I could use the same symbol name, like this: // SET PARM1= It looks strange, but it works. -- Tom Marchant -- 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: PARMDD and Symbols in a Started PROC
SYSSYM=ALLOW in JESPARMS? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 12:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC OK, I am making some progress. I got past the JCL error by coding a bunch of dummy // SET FOO= statements. I am not getting errors from the program. I can see that no symbol substitution has been done. Is there any restriction on DD *,SYMBOLS in a started PROC? Where should the EXPORT statement go? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PARMDD and Symbols in a Started PROC I know I am late to the party but I am just dipping my toe into the LONGPARM pool. I have a started PROC with the typical sort of symbols declared on the PROC statement. The PROC is two jobsteps, FWIW. The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME And //MYDDNAME DD *,SYMBOLS=JCLONLY Various references to the PROC symbols /* I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first step, and in the second step. The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED for every single one of the symbols. z/OS V2R3. The program is APF authorized and linked with LONGPARM=YES. What am I doing wrong? Or is the big picture of what I am attempting to do hopeless? -- 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: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 14:28:35 -0600, Tom Marchant wrote: >On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote: > >>>// SET PARM2= >> >>Doesn't this run afoul of a rule elsewhere in the Ref. that symbols >>are not to be defined in terms of other symbols. > >What rule is that? Where is it documented? > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/jdefine.htm Defining and nullifying JCL symbols o Do not specify JCL symbols within other JCL symbols. The results can be unpredictable, especially if the imbedded JCL symbol is not previously defined. Long ago, I submitted an RCF asking for a clarification of whether the "within" refers to the symbol name or the substitution text (I've tried both, and both work.) I don't see that any change has been made to the Ref. Looking for that passage, I was astonished and dismayed at the huge volume of text in the JCL Ref concerning symbols, their definition, and use. I consider this not an indication of good documentation but of bad design. There are rules and exceptions to the rules and exceptions to the exceptions. And "unpredictable" is shirking design responsibility. The semantics of any construct should be well-documented (and simple). The programmer's use of any construct for which the designer could not specify a semantic should be treated as an error. Simpler is better. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
NP Jerry. I *suspect* what Tom suggested would work and would be simpler than what I did. // SET PARM1= Rather than // SET $PARM1= Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Whitteridge Sent: Thursday, February 14, 2019 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC I'm keeping this as my set of examples - Thanks Charles Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 02/14/2019 02:07:07 PM: > From: Charles Mills > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/14/2019 02:07 PM > Subject: Re: PARMDD and Symbols in a Started PROC > Sent by: IBM Mainframe Discussion List > > @Tom's got it. Thanks. > > EXPORT works in a PROC and so forth but must come before the > definition of the symbols it exports. (Again, seems kind of > backwards, but what do I know?) > > I think I could have done > > //jobname JOB ... > // EXPORT SYMLIST=* > //procname PROC ... > > But I have never coded a started PROC with a JOB (and I know you > can, but it was just a wormhole I did not want to go down at this > moment) so I did more or less what Tom suggests. > > //procname PROC PARM1=value1,PARM2=value2 > // EXPORT SYMLIST=* > // SET $PARM1=PARM1 > // SET $PARM2=PARM2 > ... > //MYPARMDD DD *,SYMBOLS=JCLONLY >$PARM1,$PARM2,... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 13:07:07 -0800, Charles Mills wrote: >I think I could have done > >//jobname JOB ... >// EXPORT SYMLIST=* >//procname PROC ... Maybe. I had a similar problem a few years ago, but in my case, I had a PROC that was used in some jobs. I don't remember if I tried using the EXPORT in each of the jobs that invoked the PROC. >But I have never coded a started PROC with a JOB (and I know you can, but it >was just a wormhole I did not want to go down at this moment) IIRC, when you code a started job, you don't use PROC. When you start the task, specifying PARM1=value1,etc., it inserts a SET statement after the JOB card. I don't know how you would code default values for your parameters. >so I did more or less what Tom suggests. > >//procname PROC PARM1=value1,PARM2=value2 >// EXPORT SYMLIST=* >// SET $PARM1=PARM1 >// SET $PARM2=PARM2 >... >//MYPARMDD DD *,SYMBOLS=JCLONLY > $PARM1,$PARM2,... I did something like that too, but then I found out (at the suggestion of IBM) that I could use the same symbol name, like this: // SET PARM1= It looks strange, but it works. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
I'm keeping this as my set of examples - Thanks Charles Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 02/14/2019 02:07:07 PM: > From: Charles Mills > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/14/2019 02:07 PM > Subject: Re: PARMDD and Symbols in a Started PROC > Sent by: IBM Mainframe Discussion List > > @Tom's got it. Thanks. > > EXPORT works in a PROC and so forth but must come before the > definition of the symbols it exports. (Again, seems kind of > backwards, but what do I know?) > > I think I could have done > > //jobname JOB ... > // EXPORT SYMLIST=* > //procname PROC ... > > But I have never coded a started PROC with a JOB (and I know you > can, but it was just a wormhole I did not want to go down at this > moment) so I did more or less what Tom suggests. > > //procname PROC PARM1=value1,PARM2=value2 > // EXPORT SYMLIST=* > // SET $PARM1=PARM1 > // SET $PARM2=PARM2 > ... > //MYPARMDD DD *,SYMBOLS=JCLONLY >$PARM1,$PARM2,... > > And it is all working. Gosh some better doc AND SOME MEANINGFUL > EXAMPLES would be appreciated. > > Thanks all here for the help. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Tom Marchant > Sent: Thursday, February 14, 2019 11:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARMDD and Symbols in a Started PROC > > On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote: > > >> // EXPORT gets specified first before any // SET stmts > > > >How do I do that in a PROC where the SETs are implicit in the PROC > >statement, which is the very first statement? > > > >//procname PROC PARM1=value,PARM2=value > > Try this: > //procname PROC PARM1=value,PARM2=value > // EXPORT SYMLIST=* > // SET PARM1= > // SET PARM2= > > -- > 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: PARMDD and Symbols in a Started PROC
+1 And easy for me to say but wouldn't it be trivial to fix? Just pull out the code that checks for unused symbols? No compatibility issues -- no one is conceivably COUNTING ON a JCL error in that situation. Wasn't assembler the model for JCL? Assembler allows unreferenced fields. (Although interestingly my C++ compiler warns me about unused stack and formal parameter variables.) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, February 14, 2019 11:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC >The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED >for every single one of the symbols. > .. Tnat message has struck me as insane design since I first encountered it over 40 years ago. Completely backwards. What sane language designer would allow reference to an undefined symbol but fail definition a symbol with no references. (Perhaps a warning, not an error, on the latter would be a courtesy to the programmer.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
@Tom's got it. Thanks. EXPORT works in a PROC and so forth but must come before the definition of the symbols it exports. (Again, seems kind of backwards, but what do I know?) I think I could have done //jobname JOB ... // EXPORT SYMLIST=* //procname PROC ... But I have never coded a started PROC with a JOB (and I know you can, but it was just a wormhole I did not want to go down at this moment) so I did more or less what Tom suggests. //procname PROC PARM1=value1,PARM2=value2 // EXPORT SYMLIST=* // SET $PARM1=PARM1 // SET $PARM2=PARM2 ... //MYPARMDD DD *,SYMBOLS=JCLONLY $PARM1,$PARM2,... And it is all working. Gosh some better doc AND SOME MEANINGFUL EXAMPLES would be appreciated. Thanks all here for the help. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, February 14, 2019 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote: >> // EXPORT gets specified first before any // SET stmts > >How do I do that in a PROC where the SETs are implicit in the PROC >statement, which is the very first statement? > >//procname PROC PARM1=value,PARM2=value Try this: //procname PROC PARM1=value,PARM2=value // EXPORT SYMLIST=* // SET PARM1= // SET PARM2= -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 13:54:58 -0600, Paul Gilmartin wrote: >>// SET PARM2= > >Doesn't this run afoul of a rule elsewhere in the Ref. that symbols >are not to be defined in terms of other symbols. What rule is that? Where is it documented? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 10:57:06 -0800, Charles Mills wrote: > ... >Would it kill IBM to have some meaningful examples in the JCL reference? > The JCL Ref. contains a section: Using symbols in started task JCL Example: using JCL symbols Prepare to be disappointed. I see no meaningful example. Only a couple forlorn snippets. > ... >Try this: >//procname PROC PARM1=value,PARM2=value >// EXPORT SYMLIST=* >// SET PARM1= >// SET PARM2= Doesn't this run afoul of a rule elsewhere in the Ref. that symbols are not to be defined in terms of other symbols. I've tried it; it works, even on both sides of the "=". But I must recognize that if I do so and my program breaks I get to keep both pieces. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 10:02:26 -0800, Charles Mills wrote: > ... >I have a started PROC with the typical sort of symbols declared on the PROC >statement. >... >The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME > >//MYDDNAME DD *,SYMBOLS=JCLONLY > >I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first >step, and in the second step. > The JCL Ref. says: Chapter 17. EXPORT statement Purpose: Use the EXPORT statement to make specific JCL symbols available to the job step program. I suspect that "JCL symbols" means SET symbols but excludes PROC args. IBM makes too damned many rules. A name should be a name, whether SET or a PROC arg. > ... >The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED >for every single one of the symbols. > .. Tnat message has struck me as insane design since I first encountered it over 40 years ago. Completely backwards. What sane language designer would allow reference to an undefined symbol but fail definition a symbol with no references. (Perhaps a warning, not an error, on the latter would be a courtesy to the programmer.) >What am I doing wrong? Or is the big picture of what I am attempting to do >hopeless? > No more hopeful than an RFE to straighten out the whole mess. And did you know that if a symbol is SET to different values before and after the DD * statement, the one *after* is used!? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
On Thu, 14 Feb 2019 11:01:44 -0800, Charles Mills wrote: >> // EXPORT gets specified first before any // SET stmts > >How do I do that in a PROC where the SETs are implicit in the PROC >statement, which is the very first statement? > >//procname PROC PARM1=value,PARM2=value Try this: //procname PROC PARM1=value,PARM2=value // EXPORT SYMLIST=* // SET PARM1= // SET PARM2= -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
The EXPORT needs to precede the PROC statement, but I am not sure if that is legal for a STARTed PROC. In my experience at z/OS level 2.2, for regular batch JCL you must put the EXPORT prior to any SET's **and** prior to any PROC *execution* in order to catch the PROC default values. And I agree it would be helpful for IBM to supply specific examples for this area. Most of what I know about the subject is via trial-and-error. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC > // EXPORT gets specified first before any // SET stmts How do I do that in a PROC where the SETs are implicit in the PROC statement, which is the very first statement? //procname PROC PARM1=value,PARM2=value Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- 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: PARMDD and Symbols in a Started PROC
Job cards can be specified in members for libraries defined in MSTJCL00 - //IEFJOBS concatenation - job cards can be specified - also in any proclib member in //IEFPDSI concatenation. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC > // EXPORT gets specified first before any // SET stmts How do I do that in a PROC where the SETs are implicit in the PROC statement, which is the very first statement? //procname PROC PARM1=value,PARM2=value Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- 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: PARMDD and Symbols in a Started PROC
> // EXPORT gets specified first before any // SET stmts How do I do that in a PROC where the SETs are implicit in the PROC statement, which is the very first statement? //procname PROC PARM1=value,PARM2=value Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- 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: PARMDD and Symbols in a Started PROC
Hadn't seen SYMLIST=* learn something new every day... // EXPORT gets specified first before any // SET stmts -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- 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: PARMDD and Symbols in a Started PROC
I tried EXPORT SYMLIST=(PARM1,PARM2) No difference. Would it kill IBM to have some meaningful examples in the JCL reference? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
OK, I am making some progress. I got past the JCL error by coding a bunch of dummy // SET FOO= statements. I am not getting errors from the program. I can see that no symbol substitution has been done. Is there any restriction on DD *,SYMBOLS in a started PROC? Where should the EXPORT statement go? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PARMDD and Symbols in a Started PROC I know I am late to the party but I am just dipping my toe into the LONGPARM pool. I have a started PROC with the typical sort of symbols declared on the PROC statement. The PROC is two jobsteps, FWIW. The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME And //MYDDNAME DD *,SYMBOLS=JCLONLY Various references to the PROC symbols /* I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first step, and in the second step. The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED for every single one of the symbols. z/OS V2R3. The program is APF authorized and linked with LONGPARM=YES. What am I doing wrong? Or is the big picture of what I am attempting to do hopeless? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
I really and truly have // EXPORT SYMLIST=* I've used that before in batch jobs and you know how we lazy programmers are -- I just copied it over. Why? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rich Tabor Sent: Thursday, February 14, 2019 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
I tried spreading the first three parms across three lines -- no difference. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC Combo of the two, Lizette. There are nine parms spread across three lines. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 14, 2019 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
Try doing each one on one line Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Charles Mills > Sent: Thursday, February 14, 2019 11:21 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARMDD and Symbols in a Started PROC > > Combo of the two, Lizette. > > There are nine parms spread across three lines. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Thursday, February 14, 2019 10:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARMDD and Symbols in a Started PROC > > How do you have your parms set in the PARMDD input? > > I was told each parm needs to be on a separate line. Not sure how accurate > that is. > > Have you tried individual lines? > > Which way is your input coded? > > >//MYDDNAME DD *,SYMBOLS=JCLONLY >PARM1,PARM2,PARM3,etc > > Or >//MYDDNAME DD *,SYMBOLS=JCLONLY >PARM1 >PARM2 >PARM3 > Etc... > > -- > 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: PARMDD and Symbols in a Started PROC
Do you really have // EXPORT SYMLIST=* or something like // EXPORT SYMLIST=(PARM1,PARM2) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Thursday, February 14, 2019 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] PARMDD and Symbols in a Started PROC Combo of the two, Lizette. There are nine parms spread across three lines. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 14, 2019 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... -- 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: PARMDD and Symbols in a Started PROC
Combo of the two, Lizette. There are nine parms spread across three lines. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 14, 2019 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD and Symbols in a Started PROC How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD and Symbols in a Started PROC
How do you have your parms set in the PARMDD input? I was told each parm needs to be on a separate line. Not sure how accurate that is. Have you tried individual lines? Which way is your input coded? //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1,PARM2,PARM3,etc Or //MYDDNAME DD *,SYMBOLS=JCLONLY PARM1 PARM2 PARM3 Etc... Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Charles Mills > Sent: Thursday, February 14, 2019 11:02 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: PARMDD and Symbols in a Started PROC > > I know I am late to the party but I am just dipping my toe into the LONGPARM > pool. > > > > I have a started PROC with the typical sort of symbols declared on the PROC > statement. > > > > The PROC is two jobsteps, FWIW. > > > > The second step contains //stepname EXEC PGM=program,PARMDD=MYDDNAME > > > > And > > > > //MYDDNAME DD *,SYMBOLS=JCLONLY > > Various references to the PROC symbols > > /* > > > > I have a // EXPORT SYMLIST=*. I tried it before the first step, in the first > step, and in the second step. > > > > The start fails with a JCL error and IEFC657I THE SYMBOL x WAS NOT USED > for every single one of the symbols. > > > > z/OS V2R3. The program is APF authorized and linked with LONGPARM=YES. > > > > What am I doing wrong? Or is the big picture of what I am attempting to do > hopeless? > > > > Charles > > > > > -- > 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: PARMDD
On 2016-12-01 12:05, Farley, Peter x23353 wrote:
> Oh, and I forgot to say: For a DD * with symbol substitution:
>
> SYMBOLS=({JCLONLY|EXECSYS|CNVTSYS} [,logging-DDname])
>
> In anything *except* the PARMDD DD statement the " logging-DDname"
> subparameter will let you point to a logging DD (usually SYSOUT=*).
>
> In the JCL Reference under DD Statement / SYMBOLS parameter, I find the
> restrictions:
>
> Logging is not performed in the following cases:
>
> if logging-DDname is specified on the DD statement which describes an
> in-stream data set that is the target on the PARMDD keyword. See PARMDD
> parameter.
> if logging-DDname is specified on the SYSTSIN DD statement which describes
> input data for the TMP (Terminal Monitoring Program).
> if in-stream data set is opened by one task and then read by a different task.
>
I suspect the first two restrictions stated are consequences of the third.
> if data set specified by logging-DDname cannot be successfully opened.
>
That's almost a truism. I suppose it's likewise true if the sysin itself
can't be opened.
Bummer, bummer, bummer! So the solution (I tried it) is to preface a job
step that copies the substitutable sysin to a passed data set and use
that by referback as PARMDD.
I would hope (but hardly expect) that IBM would have the courtesy to
its customers to do that operation implicitly, transparently, behind
the scenes and spare customers the nuisance.
(RCF submitted on PARMDD, its homomorphism to PARM, 100-byte limit, and
APF entanglement.)
Thanks,
gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD
Oh, and I forgot to say: For a DD * with symbol substitution:
SYMBOLS=({JCLONLY|EXECSYS|CNVTSYS} [,logging-DDname])
In anything *except* the PARMDD DD statement the " logging-DDname" subparameter
will let you point to a logging DD (usually SYSOUT=*).
In the JCL Reference under DD Statement / SYMBOLS parameter, I find the
restrictions:
Logging is not performed in the following cases:
if logging-DDname is specified on the DD statement which describes an in-stream
data set that is the target on the PARMDD keyword. See PARMDD parameter.
if logging-DDname is specified on the SYSTSIN DD statement which describes
input data for the TMP (Terminal Monitoring Program).
if in-stream data set is opened by one task and then read by a different task.
if data set specified by logging-DDname cannot be successfully opened.
HTH
Peter
-Original Message-
From: Farley, Peter x23353
Sent: Thursday, December 01, 2016 1:58 PM
To: 'IBM Mainframe Discussion List'
Subject: RE: PARMDD
In:z/OS 2.1.0
z/OS MVS
z/OS MVS Programming: Assembler Services Guide
Linkage Conventions
Conventions for passing information through a parameter list
Program in primary ASC mode
The diagram (I can’t paste that in plain text here) shows a maximum PARM length
of 32760, which matches the PARMDD limit.
I suspect that the storage control block in which the PARMDD is actually held
is probably different from the old 100-byte PARM area, but the method shown to
access it (starting with GPR1) seems to be the same.
HTH
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Thursday, December 01, 2016 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PARMDD
In:z/OS 2.1.0
z/OS MVS
z/OS MVS JCL Reference
EXEC statement
PARMDD parameter
I read:
... To use the information, the processing program must contain
instructions to retrieve the information. ...
For details on the format of the passed information and its retrieval,
see z/OS MVS Programming: Assembler Services Guide.
Does this imply that the "passed information" is not in the venerable
R1 plist and that legacy programs probably won't be able to deal with it?
"Assembler Services Guide" is a pretty broad target. Must I read the whole
thing? The ToC contains no mention of PARMDD.
Hmmm. The description of PARM contains identical language. But the
description of PARMDD would be better if it mentioned the similarity to PARM.
And both might more specifically mention the CALL macro.
ISTR that there's a way to display substitutions performed on sysins with the
SYMBOLS= parameter but I can't find it. However, ISTR also that this is
ineffective for PARMDD. Bummer.
--
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: PARMDD
In:z/OS 2.1.0 z/OS MVS z/OS MVS Programming: Assembler Services Guide Linkage Conventions Conventions for passing information through a parameter list Program in primary ASC mode The diagram (I can’t paste that in plain text here) shows a maximum PARM length of 32760, which matches the PARMDD limit. I suspect that the storage control block in which the PARMDD is actually held is probably different from the old 100-byte PARM area, but the method shown to access it (starting with GPR1) seems to be the same. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, December 01, 2016 1:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PARMDD In:z/OS 2.1.0 z/OS MVS z/OS MVS JCL Reference EXEC statement PARMDD parameter I read: ... To use the information, the processing program must contain instructions to retrieve the information. ... For details on the format of the passed information and its retrieval, see z/OS MVS Programming: Assembler Services Guide. Does this imply that the "passed information" is not in the venerable R1 plist and that legacy programs probably won't be able to deal with it? "Assembler Services Guide" is a pretty broad target. Must I read the whole thing? The ToC contains no mention of PARMDD. Hmmm. The description of PARM contains identical language. But the description of PARMDD would be better if it mentioned the similarity to PARM. And both might more specifically mention the CALL macro. ISTR that there's a way to display substitutions performed on sysins with the SYMBOLS= parameter but I can't find it. However, ISTR also that this is ineffective for PARMDD. Bummer. -- 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: JES2 C/I Data (re: PARMDD issue)
On Tue, 2014-12-23 at 08:53 -0500, Steve Thompson wrote: Could someone give me a clue as to where converter text is defined? Here are some comments from an exit I wrote in 1990. I don't know how much of it is still accurate, so take it with a container ship full of NaCl. ** * * INTERNAL TEXT HAS THE FOLLOWING FORMAT: * *JOB STATEMENTS: * * 1 STRLTH - 2 BYTES BINARY, LENGTH OF ENTIRE TEXT INCLUDING * ITSELF * 1 STRINDCS - 1 BYTE FLAG, X'01' INDICATES JOB STMT * 1 STRJINDC - 1 BYTE FLAG * 1 STRJIND2 - 1 BYTE FLAG * 1 STRJLABD - 1 BYTE FLAG * 1 STRJKEY - VERB KEY ENTRIES BEGIN HERE UP TO END OF TEXT * *EXEC STATEMENTS: * * 1 STRLTH - 2 BYTES BINARY, LENGTH OF ENTIRE TEXT INCLUDING * ITSELF * 1 STRINDCS - 1 BYTE FLAG, X'02' INDICATES EXEC STMT * 1 STREINDC - 1 BYTE FLAG * 1 STREKEY - VERB KEY ENTRIES BEGIN HERE UP TO END OF TEXT * *DD STATEMENTS: * * 1 STRLTH - 2 BYTES BINARY, LENGTH OF ENTIRE TEXT INCLUDING * ITSELF * 1 STRINDCS - 1 BYTE FLAG, X'04' INDICATES DD STMT * 1 STRDINDC - 1 BYTE FLAG * 1 STRDKEY - VERB KEY ENTRIES BEGIN HERE UP TO END OF TEXT * * VERB KEY ENTRIES CORRESPOND TO POSITIONAL AND KEYWORD PARAMETERS * ON THE ASSOCIATED STATEMENTS. THE FORMAT OF A VERB KEY ENTRY IS: * * 1 VERBKEY - 1 BYTE BINARY, INDICATES PARAMETER TYPE. SEE * MACRO IEFVKEYS IN SYS1.AMODGEN FOR SPECIFIC VERB KEYS. * 2 NUMPARMS - 1 BYTE BINARY, NUMBER OF PARAMETERS ASSOCIATED * WITH THIS PARAMETER TYPE. * 2 PARMS OCCURS NUMPARMS TIMES. *3 SPFLAG - 1 BIT FLAG, IF ON INDICATES SUBPARAMETERS ARE * PRESENT. IF OFF, SUBPARAMETERS ARE NOT PRESENT. * * THE REMAINDER OF THE VERB KEY ENTRY IS DEPENDENT ON THE VALUE OF * SPFLAG. IF SPFLAG IS OFF, THEN THE REMAINDER OF THE ENTRY IS: * *3 PARMLEN - 7 BITS BINARY, INDICATES LENGTH OF ASSOCIATED *PARAMETER (VALUE 0 THROUGH 127). *3 PARMVAL - PARMLEM BYTES OF CLEAR TEXT. * * IF THE SPFLAG IS ON, INDICATING SUBPARAMETERS, THE REMAINDER OF * THE VERB KEY ENTRY IS COMPOSED OF REPEATING SUBPARAMETERS: * *3 SPCOUNT - 7 BITS BINARY, NUMBER OF SUBPARAMETERS. *3 SUBPARMS - OCCURS SPCOUNT TIMES. * 4 SPLENGTH - 1 BYTE BINARY, LENGTH OF SUBPARAMETER VALUE. * 4 SPVAL - SPLENGTH BYTES OF CLEAR TEXT. * ** EJECT ** * * SUBPARAMETERS CANNOT THEMSELVES HAVE SUBPARAMETERS. PARAMETERS * AND SUBPARAMETERS CAN HAVE ZERO LENGTH; WHEN A STEPNAME OR DDNAME * IS OMITTED FROM THE ORIGINAL JCL FOR EXAMPLE, THE INTERNAL TEXT * INDICATES A STEPNAME OR DDNAME OF ZERO BYTES. OMITTED (BUT NOT * TRAILING) PARAMETERS ALSO ARE INDICATED WITH ZERO-LENGTH ENTRIES. * *** THIS INFORMATION IS NOT
Re: JES2 C/I Data (re: PARMDD issue)
In 549973cc.3040...@copper.net, on 12/23/2014 at 08:53 AM, Steve Thompson ste...@copper.net said: Could someone give me a clue as to where converter text is defined? Try 4.0 MVS Converter / Interpreter Text Processing in z/OS MVS Installation Exits, SA22-7593 -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JES2 C/I Data (re: PARMDD issue)
It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Could someone give me a clue as to where converter text is defined? I've been using PDF copies of all the JES2 manuals in the SK5T-9234 download. And using the extended search I just can't seem to figure out which data areas I need to look at. It is also interesting that the manuals keep referring to a JES2 Customization manual, but it doesn't exist in this set of manuals. However that topic/chapter is in the JES2 Introduction. This happens to be a continuation of the PARMDD issue I mentioned earlier. It is working, then it isn't, then it is. And I can (using eJES) display the converter text, but I would like to understand the bit flags, because it appears that the EXPORT JCL statement is ignored when things don't work -- and I'd like to figure out why. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 C/I Data (re: PARMDD issue)
Steve Thompson wrote: It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Which of C/B or C/I (in your subject) are you refering? It is also interesting that the manuals keep referring to a JES2 Customization manual, but it doesn't exist in this set of manuals. However that topic/chapter is in the JES2 Introduction. I see your point. I immediately looked at 'Tailoring your JES2 system' amongst other places in 'JES2 Introduction' book, but must also missed something... Could that book be a RedBook or a Share presentation? 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: JES2 C/I Data (re: PARMDD issue)
On 12/23/2014 09:03 AM, Elardus Engelbrecht wrote: Steve Thompson wrote: It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Which of C/B or C/I (in your subject) are you refering? SNIPPAGE I am looking for where the Converter text is defined. The last time I was working in/with JES2 C/Bs I was doing the JES2 SRB support for ACS/WYLBUR (formerly OBS/WYLBUR). I haven't touched any of that since 1998. There, we would fake a DEB, build a minimal DCB, link 'em and go read spool direct. Me thinks I could not get WYLBUR to do the SRB work these days with all the changes that have been done since OS/390 2.4. Man I miss those days... Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 C/I Data (re: PARMDD issue)
There are Documentation WEB pages and within them, scroll down to the z/OS JES2 line on the left and locate the z/OS JES2 Data Areas volumes. For z/OS 1.13: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13/en/Homepage.html Oops, for version 2, these manuals appear to be missing: For z/OS 2.01: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1/en/homepage.html Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: Tuesday, December 23, 2014 8:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 C/I Data (re: PARMDD issue) It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Could someone give me a clue as to where converter text is defined? I've been using PDF copies of all the JES2 manuals in the SK5T-9234 download. And using the extended search I just can't seem to figure out which data areas I need to look at. It is also interesting that the manuals keep referring to a JES2 Customization manual, but it doesn't exist in this set of manuals. However that topic/chapter is in the JES2 Introduction. This happens to be a continuation of the PARMDD issue I mentioned earlier. It is working, then it isn't, then it is. And I can (using eJES) display the converter text, but I would like to understand the bit flags, because it appears that the EXPORT JCL statement is ignored when things don't work -- and I'd like to figure out why. Regards, Steve Thompson -- 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: JES2 C/I Data (re: PARMDD issue)
I think what you want starts here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E4B0/4.0 and, more specifically, here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E4B0/4.3 But these are the 1.12 version, because that's what I'm running. z/OS 2.1 version seems to be here: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae400/txfcvt.htm On Tue, Dec 23, 2014 at 7:53 AM, Steve Thompson ste...@copper.net wrote: It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Could someone give me a clue as to where converter text is defined? I've been using PDF copies of all the JES2 manuals in the SK5T-9234 download. And using the extended search I just can't seem to figure out which data areas I need to look at. It is also interesting that the manuals keep referring to a JES2 Customization manual, but it doesn't exist in this set of manuals. However that topic/chapter is in the JES2 Introduction. This happens to be a continuation of the PARMDD issue I mentioned earlier. It is working, then it isn't, then it is. And I can (using eJES) display the converter text, but I would like to understand the bit flags, because it appears that the EXPORT JCL statement is ignored when things don't work -- and I'd like to figure out why. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 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: JES2 C/I Data (re: PARMDD issue)
On 12/23/2014 09:21 AM, Nims,Alva John (Al) wrote: There are Documentation WEB pages and within them, scroll down to the z/OS JES2 line on the left and locate the z/OS JES2 Data Areas volumes. For z/OS 1.13: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13/en/Homepage.html Oops, for version 2, these manuals appear to be missing: For z/OS 2.01: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1/en/homepage.html Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 SNIPPAGE When all else fails, use SRCHFOR on the macro library (SHASMAC), then read a few macros. Now search the mighty fine JES2 manuals. Security via obscurity. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 C/I Data (re: PARMDD issue)
Aside from the Jes2 Intro, ABCs of System Programming also contains some info. Better yet .. google 'JES2 Bootcamp' .. HTH Jim -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, December 23, 2014 8:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 C/I Data (re: PARMDD issue) Steve Thompson wrote: It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Which of C/B or C/I (in your subject) are you refering? It is also interesting that the manuals keep referring to a JES2 Customization manual, but it doesn't exist in this set of manuals. However that topic/chapter is in the JES2 Introduction. I see your point. I immediately looked at 'Tailoring your JES2 system' amongst other places in 'JES2 Introduction' book, but must also missed something... Could that book be a RedBook or a Share presentation? 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5577 / Virus Database: 4257/8792 - Release Date: 12/23/14 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 C/I Data (re: PARMDD issue)
On Tue, 23 Dec 2014 08:53:16 -0500, Steve Thompson ste...@copper.net wrote: It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Could someone give me a clue as to where converter text is defined? Regards, Steve Thompson I believe what you are looking for is not in any JES2 Macros, but in Macros IEFTXTFT and IEFVKEYS in SYS1.MODGEN. -- Dale R. Smith -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 C/I Data (re: PARMDD issue)
And maybe everyone knows this, but for a quick look you can submit a job on hold and use INPUT ON in SDSF with SE to see the $INTTEXT in hex. Dale R. Smith wrote: On Tue, 23 Dec 2014 08:53:16 -0500, Steve Thompson ste...@copper.net wrote: It has been a long time since I've done any JES2 stuff where I was looking in JES C/Bs. Could someone give me a clue as to where converter text is defined? Regards, Steve Thompson I believe what you are looking for is not in any JES2 Macros, but in Macros IEFTXTFT and IEFVKEYS in SYS1.MODGEN. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 C/I Data (re: PARMDD issue)
Data Areas PDFs can be found here: http://www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r1pdf/#HAS -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
Jol has had * IF statements for Symbolic Variables and Return Codes, * Symbolic Variable Replacement in Card Image Files, * Nested Procedures, * Data Card Image files in Procs * Simplified JCL Syntax * 3270 CUA Compliant Full Screen Panel instruction and much for over 30 years. A few years ago, Long Parms were added too. The other day, the Windows beta version was released, and the Linux version is running. Try it - see what else is possible. Clement Clarke www.Oscar-jol.com. Download Jol ZOS or Win http://start.oscar-jol.com/download-store. Paul Gilmartin wrote: And Peter Relson mentioned it as a concern when he originated the thread. It's interesting how many features coming in z/OS 2.1 were mentioned in that thread: o Long PARMs (of course). o A load module attribute indicating a program's willingness to accept long PARMs. o PARM generated from a data set (e.g. PARMDD). o Instream data sets in PROCs o Symbol substitution in instream data sets. o System symbol substitution in batch JCL. -- gil --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet
Ok, I'm back to working on this aspect of a problem. So, I tried something interesting to try to figure this one out. The following JCL does NOT expand the string (the JOB after this does): //SXT7279T JOB (T,,MC),'TEST PARMDD ',CLASS=I, // TIME=(,05), //* TYPRUN=SCAN, // MSGCLASS=X,NOTIFY=SYSUID //* $ACFJ219 ACF2 ACTIVE HUMANA //* //* //FOCUCC EXEC FOCUCCDUAL COMPILE //* //* // SET CMB=SXT7278.CID.MBDUAL.CRDS.CID // SET CCT=SXT7278.CMPL.CNTL(RELCID) //* // SET HDY='.' //* // SET HDT='.' //* // SET SQP=Y //* // SET RNO='.' //* // SET VX='.' //* // SET NAP=NEWAPPL(BCMP) //* // EXPORT SYMLIST=* //PARMDD EXEC PGM=IEBGENER //*-+1+2+3+4+5+6+7+8 //SYSUT1 DD *,SYMBOLS=(CNVTSYS,PARMLST) ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP /* //SYSUT2 DD DSN=PARMDD,DISP=(,PASS),UNIT=3390, // DCB=(RECFM=VB,LRECL=4096,BLKSIZE=0), // SPACE=(TRK,1) //PARMLST DD SYSOUT=* //SYSINDD DUMMY //SYSPRINT DD SYSOUT=* //* //* //MASSCMPL EXEC PGM=IKJEFT1B,PARMDD=PARMDD //*PARM='ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP' //PARMDD DD DSN=PARMDD,DISP=OLD /* //* //*** EXECUTE BACKGROUND CLIST TO CREATE ** //* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //SYSTSPRT DD SYSOUT=* //*** DUMMY PANEL LIBRARY ** //ISPPLIB DD DSN=ISPPLIB, JES shows this in the PARMLST DD of the gener step: SYSUT1 : RECORD 1 BEFORE SUBSTITUTION SYSUT1 : ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP SYSUT1 : RECORD 1 AFTER SUBSTITUTION SYSUT1 : ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP THIS JOB WORKS for the expansion, but not in the execution!!: //SXT7278T JOB (T,,MC),'TEST OF PARMDD',CLASS=I, //*TYPRUN=SCAN, // TIME=(0,10), // MSGCLASS=X,NOTIFY=SYSUID //*+JTS HOLD_UNTIL NOW //* $ACFJ219 ACF2 ACTIVE HUMANA //* //* // EXPORT SYMLIST=* //* //* //*OCUCC EXEC FOCUCC //* //* // SET HDY='TODAY' //* // SET HDT='10:00' //* // SET SQP='YES' //* // SET RNO='.' //* // SET VX='.' //* // SET CCT=SXT7278.CMPL.CNTL(RELCID) //* // SET CMB=TESTAEN.CID.MBB.CRDS.CID //* // SET NAP=NEWAPPL(BCMP) //* //* //PARMDD EXEC PGM=IEBGENER //*-+1+2+3+4+5+6+7+8 //SYSUT1 DD *,SYMBOLS=(CNVTSYS,PARMLST) ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP /* //SYSUT2 DD DSN=PARMDD,DISP=(,PASS),UNIT=3390, // DCB=(RECFM=VB,LRECL=4096,BLKSIZE=0), // SPACE=(TRK,1) //PARMLST DD SYSOUT=* //SYSINDD DUMMY //SYSPRINT DD SYSOUT=* //* //MASSCMPL EXEC PGM=IKJEFT1B,PARMDD=PARMLST //*PARM='ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP' //PARMLST DD DSN=PARMDD,DISP=(OLD,DELETE) //* //*** EXECUTE BACKGROUND CLIST TO CREATE ** //* //SYSPRINT DD SYSOUT=* //SYSTSIN DD DUMMY //SYSTSPRT DD SYSOUT=* //*** DUMMY PANEL LIBRARY ** //ISPPLIB DD DSN=ISPPLIB, JES shows this in the PARMLST DD of the Gener step: SYSUT1 : RECORD 1 BEFORE SUBSTITUTION SYSUT1 : ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP SYSUT1 : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80) SYSUT1 : ISPSTART CMD(%NCMPL TODAY 10:00 YES . . SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP) SYSUT1 : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80) SYSUT1 : ISPSTART CMD(%NCMPL TODAY 10:00 YES . . SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP) SYSUT1 : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80) SYSUT1 : ISPSTART CMD(%NCMPL TODAY 10:00 YES . . SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP) SYSUT1 : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80) SYSUT1 : ISPSTART CMD(%NCMPL TODAY 10:00 YES . . SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP) SYSUT1 : RECORD 1 AFTER SUBSTITUTION (TRUNCATED AT 80) SYSUT1 : ISPSTART CMD(%NCMPL TODAY 10:00 YES . . SXT7278.CMPL.CNTL(RELCID) TESTAEN.CID.MBB.CRDS.CID) NEWAPPL(BCMP) The next step does not work, because SYSUT2 had an I/O error. Apparently it doesn't like the SYSUT1 for writing to SYSUT2 for SYSOUT=*. Well, after more testing, I found that you really can't copy or do a refer-back to pick it up. Now, why does it work for the one and not the other? It appears it is the special utility program that FOCUCC invokes: U11RMS Regards, Steve Thompson Tech Architect The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet
On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson sthompso...@humana.com wrote: Ok, I'm back to working on this aspect of a problem. So, I tried something interesting to try to figure this one out. The following JCL does NOT expand the string (the JOB after this does): //SXT7279T JOB (T,,MC),'TEST PARMDD ',CLASS=I, // TIME=(,05), //* TYPRUN=SCAN, // MSGCLASS=X,NOTIFY=SYSUID //* $ACFJ219 ACF2 ACTIVE HUMANA //* //* //FOCUCC EXEC FOCUCCDUAL COMPILE //* //* // SET CMB=SXT7278.CID.MBDUAL.CRDS.CID // SET CCT=SXT7278.CMPL.CNTL(RELCID) //* // SET HDY='.' //* // SET HDT='.' //* // SET SQP=Y //* // SET RNO='.' //* // SET VX='.' //* // SET NAP=NEWAPPL(BCMP) //* // EXPORT SYMLIST=* The EXPORT has to be coded BEFORE the SET statements, as documented in the first paragraph describing the EXPORT statement. Symbols must be set to a value subsequent to the EXPORT statement for the symbol value to be exported. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet
On 12/12/2014 02:35 PM, Tom Marchant wrote: On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson sthompso...@humana.com wrote: SNIPPAGE The EXPORT has to be coded BEFORE the SET statements, as documented in the first paragraph describing the EXPORT statement. Symbols must be set to a value subsequent to the EXPORT statement for the symbol value to be exported. For all -- I got interrupted a few times while writing the email that Tom was responding to. My purpose was to get back and explain what I found (this morning my time). To answer Tom specifically: If that utility (U11RMS) is not executed, the symbols get expanded, and the REXX exec works. And, in the JOB that worked, I had moved the EXPORT statement to immediately follow the JOB card and to immediately precede the step in question. Made no difference. When it worked, it worked. Have that utility step execute and PARMDD does not work. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet
On 12/12/2014 03:02 PM, Steve Thompson wrote: On 12/12/2014 02:35 PM, Tom Marchant wrote: On Fri, 12 Dec 2014 18:36:21 +, Steve Thompson sthompso...@humana.com wrote: SNIPPAGE The EXPORT has to be coded BEFORE the SET statements, as documented in the first paragraph describing the EXPORT statement. Symbols must be set to a value subsequent to the EXPORT statement for the symbol value to be exported. SNIPPAGE To answer Tom specifically: SNIPPAGE And, in the JOB that worked, I had moved the EXPORT statement to immediately follow the JOB card and to immediately precede the step in question. Made no difference. When it worked, it worked. snippage Tom is correct. I had not noticed that I did a copy and not a move when I had done the one test. Once I saw the two EXPORT statements, I realized my mistake So I re-ran my tests and proved what Tom said is valid. Which also proved the manual I am so glad it is Friday and not that far from beer-30. Have a good weekend all, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet
It's wrong to quietly ignore an unsupported construct. Logging-DDname in a SYSIN data set mentioned in PARMDD should result in a JCL syntax error and failure of the job before execution. Your opinions are always welcome. They are not always agreed with. For this case, I probably agree that a JCL syntax error could have been better. For many other cases I do not agree that it's wrong to quietly ignore. Might it be more readily be reported in JESYSMSG? It would seem that since allocation messages appear there that data set is writeable at the needed time (whether it's in scope for the initiator is a different question) I'll plead ignorance here. That makes sense to me (but I don't know if record length could be a stumbling point). If a request is submitted, it would be useful to mention how necessary it is to show each substituted line in its entirety (possibly spanning multiple messages) or whether the first n characters might satisfy. I have not looked at all into just what is logged if logging is done (for the non-PARMDD case). I suppose normally I'd expect to see, for any line that changed due to substitution, the complete old and the complete new. quote Note that logging-DDname is ignored if it is specified on the DD statement which describes a data set that is the target on the PARMDD keyword (see PARMDD parameter). /quote what I read from the reference url is that EXEC ...,PARMDD=MYLOGDD along with SYMBOLS=(...,MYLOGDD) should fail. Ignored (usually, and in this case) means ignored. It does not mean rejected. Here it really means ignored. In this case it does not even mean not processed and we told you about that with an informational message. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet
...ignored...! WTF!? Time for a Requirement? Either the substitution result should be logged in logging-DDname or it should appear in an informative message after the EXEC statement. You are always encouraged to submit requirements. Logging might well be rejected. It is a chicken-and-egg thing. At the time that PARMDD is (and has to be) processed (under the initiator task), various i/o operations are not supported (apparently including those needed to write to a the intended log). Changing that could be very costly, thus requiring significant justification. I fear that I am not allowed to do that. I can only post snippets of it as I believe I have already done. If you are not allowed to post the actual symbol values, can you post the length of each symbol values (and if there is some funky character that you can get in there, what such characters might be, just in case parsing is the issue)? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet
On Mon, 8 Dec 2014 07:59:53 -0500, Peter Relson wrote: ... At the time that PARMDD is (and has to be) processed (under the initiator task), various i/o operations are not supported (apparently including those needed to write to a the intended log). Changing that could be very costly, thus requiring significant justification. Might it be more readily be reported in JESYSMSG? It would seem that since allocation messages appear there that data set is writeable at the needed time (whether it's in scope for the initiator is a different question). Treatment of PARMDD that refers to a SYSIN with SYMBOLS= is so more complicated than EXEC ...,PARM= that reporting is correspondingly more valuable. It's wrong to quietly ignore an unsupported construct. Logging-DDname in a SYSIN data set mentioned in PARMDD should result in a JCL syntax error and failure of the job before execution. And another idiosyncrasy I suspect. From: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_parm_string_requirements_parmdd.htm z/OS 2.1.0z/OS MVSz/OS MVS JCL ReferenceEXEC statementPARMDD parameterParameter string requirements z/OS MVS JCL Reference SA23-1385-00 After concatenation, the parameter string that is passed to the job step program is examined for double ampersand character (amp;) sequences. Double ampersands are converted to single ampersands in the same way that double ampersands are converted to single ampersands by PARM= processing. I guess (I haven't tested) that if I code: // SET TWOAMP='amp;' // EXPORT TWOAMP //STEP EXEC PGM=WOMBAT,PARM='TWOAMP' ... the parm passed to WOMBAT is two ampersands (there is no rescan). However, in: // SET TWOAMP='amp;' // EXPORT TWOAMP //STEP EXEC PGM=WOMBAT,PARMDD=P //P DD *,SYMBOLS=JCLONLY TWOAMP ... PARMDD processing converts the two ampersand to a single ampersand which is passed to WOMBAT. Ouch! FSVO ... in the same way The effect of passing a symbol via PARM= may differ unexpectedly from passing it via PARMDD=. I suspect that when the LONGPARM Requirement was submitted the requestor expected processing consistent with that of PARM=, but with the 100-character limit relaxed (substitution of system symbols would be an added value). What was provided was significantly different. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
Caveat: insert Daily Digest delay here... (you folx've probably already hashed this out and are onto other 'stuffs'.) quote Note that logging-DDname is ignored if it is specified on the DD statement which describes a data set that is the target on the PARMDD keyword (see PARMDD parameter). /quote Gil: What I read from the reference url is that EXEC ...,PARMDD=MYLOGDD along with SYMBOLS=(...,MYLOGDD) should fail. In other/my words, you can't pipe the logging results into the program via the Parm DD. Ex: failure (JCL error?) // EXEC PGM=,PARMDD=MYLOGDD //SYMBDDDD DATA,SYMBOLS=(...,MYLOGDD) //MYLOGDD DD ps. z/OS v1.12 not v2.1 here signature = 6 lines follows Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 -Original Message- From: Paul Gilmartin [mailto:paulgboul...@aim.com] Sent: December 7, 2014 12:16 Subject: Re: PARMDD -- any one use yet? On Sun, 7 Dec 2014 11:20:40 -0500, Peter Relson wrote: I might well be thinking of something else, but for whatever reason I was thinking that something might show what substitution is done for PARMDD Found it in: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_Syntax66.htm z/OS 2.1.0z/OS MVSz/OS MVS JCL ReferenceDD statementSYMBOLS parameterSyntax But: ...logging-DDname Start of change Optional parameter that indicates a valid DD name for the data set to use for logging results of the symbol substitution. Rules for DD names are described in DDNAME parameter. Note that logging-DDname is ignored if it is specified on the DD statement which describes a data set that is the target on the PARMDD keyword (see PARMDD parameter). End of change ...ignored...! WTF!? Time for a Requirement? Either the substitution result should be logged in logging-DDname or it should appear in an informative message after the EXEC statement. I suppose one might add an IEBGENER step to show in logging-DDname the results of substitution in SYSUT1, followed by an other step using the passed SYSUT2 as PARMDD. No! No! No! Are there any constraints on attributes, etc. of logging-DDname? This was mentioned in a thread here, SYSIN Symbol Resolution vs. LRECL circa 2013-10-10. (I confess; I cloned the topic.) The Search facility in Knowledge Center sucks and/or I don't know how to use it. I found this only by searching a downloaded PDF of the JCL Reference for PARMDD. Could I have done better? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
We would still need to explain why JOB A works while JOB B, based on JOB A, isn't working. Perhaps you could consider starting this thread over again, this time providing the complete information. I might have missed it, but I do not think you showed what the symbol values were, and you did not show the job log. I might well be thinking of something else, but for whatever reason I was thinking that something might show what substitution is done for PARMDD Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: PARMDD -- any one use yet?
On 12/07/2014 02:23 AM, Peter Hunkeler wrote:
SNIPPAGE
SYMBOLS parameter
Parameter type
Keyword, optional
Purpose
Use the SYMBOLS parameter to request JES to perform symbol substitution within
in-stream data.
Syntax
SYMBOLS=({JCLONLY|EXECSYS|CNVTSYS} [,logging-DDname])
Valid values: Specify one of three SYMBOLS= values:
JCLONLY [snip]
EXECSYS [snip]
CNVTSYS [snip]
logging-DDname
Optional parameter that indicates a valid DD name for the data set to use for
logging results of the symbol substitution. Rules for DD names are described in
?DDNAME parameter? on page 150. Note that logging-DDname is ignored if it is
specified on the DD statement which describes a data set that is the target on
the PARMDD keyword (see ?PARMDD parameter? on page 354).
Note the last sentence!
I appreciate the possibility of substituting symbols in instream data. However, I cannot
understand how one (IBM) can desing so many surprise, surprise effects into
such functionality in the 21st century. Paul listed many of them in an earlier post.
This is just one more one cannot readily understand.
SNIPPAGE
Perhaps a few of us should submit a RCF asking for an example to
contain the logging DDname and its use?
I think it would be rather instructive.
Regards,
Steve Thompson
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: PARMDD -- any one use yet?
On 12/07/2014 02:24 AM, Peter Hunkeler wrote: We would still need to explain why JOB A works while JOB B, based on JOB A, isn't working. How about posting the two JCLs? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN I fear that I am not allowed to do that. I can only post snippets of it as I believe I have already done. Please note, even though I use my personal email for IBM-main the vast majority of the time, I have had management talking to me about what I say w/ or w/o a disclaimer (and not just on IBM-main, but other forums as well). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
On Sun, 7 Dec 2014 11:20:40 -0500, Peter Relson wrote: I might well be thinking of something else, but for whatever reason I was thinking that something might show what substitution is done for PARMDD Found it in: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab600/iea3b6_Syntax66.htm z/OS 2.1.0z/OS MVSz/OS MVS JCL ReferenceDD statementSYMBOLS parameterSyntax But: ...logging-DDname Start of change Optional parameter that indicates a valid DD name for the data set to use for logging results of the symbol substitution. Rules for DD names are described in DDNAME parameter. Note that logging-DDname is ignored if it is specified on the DD statement which describes a data set that is the target on the PARMDD keyword (see PARMDD parameter). End of change ...ignored...! WTF!? Time for a Requirement? Either the substitution result should be logged in logging-DDname or it should appear in an informative message after the EXEC statement. I suppose one might add an IEBGENER step to show in logging-DDname the results of substitution in SYSUT1, followed by an other step using the passed SYSUT2 as PARMDD. No! No! No! Are there any constraints on attributes, etc. of logging-DDname? This was mentioned in a thread here, SYSIN Symbol Resolution vs. LRECL circa 2013-10-10. (I confess; I cloned the topic.) The Search facility in Knowledge Center sucks and/or I don't know how to use it. I found this only by searching a downloaded PDF of the JCL Reference for PARMDD. Could I have done better? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
In 5483d3f5.9040...@copper.net, on 12/06/2014 at 11:13 PM, Steve Thompson ste...@copper.net said: I know of NOTHING using cores today. Well, then you only know about machines designed in the last few decades. But you can find some 1960's (1950's?) vintage machines in museums. How about identifying. RCA 3301 for one. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
In 5483d485.5010...@copper.net, on 12/06/2014 at 11:16 PM, Steve Thompson ste...@copper.net said: We would still need to explain why JOB A works while JOB B, based on JOB A, isn't working. Obviously, because they are different. It may take some experimenting to determine which differences are relevant. After all, this isn't MFT, or DOS R26. It is an ec12 running z/OS 2.1. Which means that everything is more complicated and there are more opportunities to shoot ourself in the foot. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
In 5480ca98.3040...@copper.net, on 12/04/2014 at 03:56 PM, Steve Thompson ste...@copper.net said: On 12/04/2014 03:04 PM, Paul Gilmartin wrote: On 2014-12-04 12:35, Steve Thompson wrote: SNIP Like, what's the most efficient way to clear a register? -- gil SNIP Well, mine is to pull the power plug. Works for all machines. No. However, it will probably work for anything designed in the last few decades. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
In 5480d9dd.6000...@copper.net, on 12/04/2014
at 05:02 PM, Steve Thompson ste...@copper.net said:
The one that does not work does pass to IKJEFT1B ISPSTART
cmd(%NCMPL and that's it. The rest of the parm string is NOT
passed.
What happedns if you surround the parameter with apostrophes, e.g.,
ISPSTART cmd('%NCMPL foo') ?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
On 12/06/2014 06:20 PM, Shmuel Metz (Seymour J.) wrote: In 5480ca98.3040...@copper.net, on 12/04/2014 at 03:56 PM, Steve Thompson ste...@copper.net said: On 12/04/2014 03:04 PM, Paul Gilmartin wrote: On 2014-12-04 12:35, Steve Thompson wrote: SNIP Like, what's the most efficient way to clear a register? -- gil SNIP Well, mine is to pull the power plug. Works for all machines. No. However, it will probably work for anything designed in the last few decades. I know of NOTHING using cores today. But if you know of a machine that you pull the plug on it and it has registers that have something in them after POST or IML/IMPL/POR... How about identifying. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
On 12/06/2014 06:22 PM, Shmuel Metz (Seymour J.) wrote:
In 5480d9dd.6000...@copper.net, on 12/04/2014
at 05:02 PM, Steve Thompson ste...@copper.net said:
The one that does not work does pass to IKJEFT1B ISPSTART
cmd(%NCMPL and that's it. The rest of the parm string is NOT
passed.
What happedns if you surround the parameter with apostrophes, e.g.,
ISPSTART cmd('%NCMPL foo') ?
We would still need to explain why JOB A works while JOB B, based
on JOB A, isn't working.
After all, this isn't MFT, or DOS R26. It is an ec12 running z/OS
2.1.
Regards,
Steve Thompson
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: PARMDD -- any one use yet?
A suggestion then: Specify a SYMBOLS logging DD, as I did in my example. It
*should* tell you what substitutions were actually made. I believe I've
read of such; I don't readily find it in the JCL Reference.
The JCL reference explains the SYMBOLS parameter as:
SYMBOLS parameter
Parameter type
Keyword, optional
Purpose
Use the SYMBOLS parameter to request JES to perform symbol substitution within
in-stream data.
Syntax
SYMBOLS=({JCLONLY|EXECSYS|CNVTSYS} [,logging-DDname])
Valid values: Specify one of three SYMBOLS= values:
JCLONLY [snip]
EXECSYS [snip]
CNVTSYS [snip]
logging-DDname
Optional parameter that indicates a valid DD name for the data set to use for
logging results of the symbol substitution. Rules for DD names are described in
?DDNAME parameter? on page 150. Note that logging-DDname is ignored if it is
specified on the DD statement which describes a data set that is the target on
the PARMDD keyword (see ?PARMDD parameter? on page 354).
Note the last sentence!
I appreciate the possibility of substituting symbols in instream data. However,
I cannot understand how one (IBM) can desing so many surprise, surprise
effects into such functionality in the 21st century. Paul listed many of them
in an earlier post. This is just one more one cannot readily understand.
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: PARMDD -- any one use yet?
We would still need to explain why JOB A works while JOB B, based on JOB A, isn't working. How about posting the two JCLs? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
Might one conclude that the substitution works just fine, but that the application to which you are sending the data can't handle longer data? It is the user's responsibility to provide to the application only what it can handle. The system will not prevent it (except for authorized cases where providing too much data can be a system integrity exposure for incorrectly written programs). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
On 12/05/2014 07:23 AM, Peter Relson wrote: Might one conclude that the substitution works just fine, but that the application to which you are sending the data can't handle longer data? It is the user's responsibility to provide to the application only what it can handle. The system will not prevent it (except for authorized cases where providing too much data can be a system integrity exposure for incorrectly written programs). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Peter, I will use your post to give an update on this strangeness. The two JOBs in question are using IKJEFT1B. Once I got this working for the one JOB, I did a copy and paste to the second JOB. For these two JOBs the step in question is using IKJEFT1B, and ISPSTART is used to run a REXX. The second JOB fails. And the Logging DD doesn't get written to. I'm dropping this problem (PARMDD) for now, to focus on the REXX logic issue (submitting compiles with wrong compile options) that was the catalyst for this. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
On Thu, 4 Dec 2014 17:08:30 -0500, Farley, Peter x23353 wrote: A suggestion then: Specify a SYMBOLS logging DD, as I did in my example. It *should* tell you what substitutions were actually made. I believe I've read of such; I don't readily find it in the JCL Reference. Paul Gilmartin had a thread about this a while back (not sure if here or TSO-REXX or where), from which my example was taken and subsequently modified. The problem that can happen is I/O errors when the LRECL is exceeded after symbol substitution (due, we think, to LRECL limitations, maybe in JES for DD * datasets? Don't remember ATM). Symbol substitution is performed only for DD * (or DD DATA) data sets. o There appears to be no practical global limitation on LRECL for instream data sets (perhaps thousands). o It seems that the I/O error is reported when substitution causes the length of a line to exceed not any universal limit, but LRECL for the individual instream data set, whether it be 80 or 1000 or ... o The JCL reference doesn't explain how LRECL is determined for an instream data set. I submitted an RCF on this. Accepted as clarification. I requested a preview, pending publication. Pubs said they'd consult the developer and get back to me with the information. They haven't. Empirically, the rules seem different between JES2 and JES3. o The LRECL= parameter is now permitted on instream data set DD statements. Empirically, specifying it has no effect (on JES2, at least). In any case, the log may help. On Fri, 5 Dec 2014 10:19:10 -0500, Steve Thompson wrote: On 12/05/2014 07:23 AM, Peter Relson wrote: Might one conclude that the substitution works just fine, but that theåç application to which you are sending the data can't handle longer data? It is the user's responsibility to provide to the application only what it can handle. The system will not prevent it (except for authorized cases where providing too much data can be a system integrity exposure for incorrectly written programs). Good point. I believe the capability for an authorized program to accept PARM100 is specified as an attribute on the load module. I don't know what it's called; I don't know whether AMBLIST or Binder SYSPRINT reports it. Thanks. Peter, I will use your post to give an update on this strangeness. The two JOBs in question are using IKJEFT1B. I suspect IKJEFT1B is APF-authorized. I don't know whether it's linked as long PARM tolerant. I would not recommend simply re-linking it to change the attribute. Once I got this working for the one JOB, I did a copy and paste to the second JOB. For these two JOBs the step in question is using IKJEFT1B, and ISPSTART is used to run a REXX. The second JOB fails. And the Logging DD doesn't get written to. If the encountered I/O error precludes logging, it's a bad design. But the I/O ABEND should be reported in the job log. I'm dropping this problem (PARMDD) for now, to focus on the REXX logic issue (submitting compiles with wrong compile options) that was the catalyst for this. This is too damn complicated. IBM should have simply relaxed the syntactic limit on the length of the PARM= operand on the EXEC statement. Symbol substitution in instream data sets is a separate feature, having it's own value. Irritating. The TSO CALL command still enforces the now-obsolete 100-character PARM limit. Will anyone bet me that there will be an enhancement in the next release? The integrity concerns have been removed by the availability of the PARM length enforcement for APF authorized programs (provided that's enforced globally by ATTACH/LINK, not only by the initiator, bypassing enforcement for TSO CALL. That would be a wrong design, but too charactistic of IBM.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
You may have put the EXPORT statement at the wrong point in the JCL. Try putting it right after the JOB statement. On Thu, 4 Dec 2014 18:40:03 +, Steve Thompson sthompso...@humana.com wrote: I've run into a situation where we have a parm that expands to more than 100 characters (sound like a familiar problem?). So, I've tried to use the PARMDD EXEC Keyword. And sure enough it points over to the specified DDName. So I have it coded like this: // EXPORT SYMLIST=* : : //PARMLST DD *,SYMBOLS=CNVTSYS (HDY HDT SQP RNO VX CCT CMB) NAP /* And that failed - NONE of the variables were expanded. So I tried this: //PARMLST DD *,SYMBOLS=CNVTSYS ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP /* Only the ISPSTART CMD(NCMPL gets passed and used (because I got the SAYs out of the REXX code). (yes, I am using IKJEFT01, IKJEFT1B, IRXJCL as the PGM=, and this ain't happing). So, has anyone tried this? Have you had any success? Did I read the various wonderful manuals? Yes, all of them z/OS 2.1 (JCL REF, TSO Customization, etc.). I thought, from reading the manuals, that those variables were to be interpreted for this particular DD because of the SYSMBOLS keyword. What am I missing? Regards, Steve Thompson The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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: PARMDD -- any one use yet?
Date: Thu, 4 Dec 2014 12:56:53 -0600 From: Peter X. DeFabritus pxdef...@gmail.com You may have put the EXPORT statement at the wrong point in the JCL. Try putting it right after the JOB statement. SNIPPAGE Sorry, it behaved the same whether it was just after the JOB card or just before the EXEC PGM= I've tried moving the EXPORT. And I tried various SYMBOLS= values. However, it is now working. And I'm not sure what I did that fixed the problem. I guess getting impatient and frustrated at the same time, I should stick to only making one change at a time But I can tell you that the little comment about concatenating the lines together (in the JCL REF) -- using simple concat -- They ain't joking. So, if you need to your parm line (string), think about how you do the split. Because the next line read is concatenated to the prior line ignoring the right side spaces (at least that's what I have experienced). If you need a space between strings, you may need to do some interesting things to effect that. Ok, I now return you to your regularly scheduled fun and games Regards, Steve Thompson The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
On 2014-12-04 12:35, Steve Thompson wrote: So, if you need to your parm line (string), think about how you do the split. Because the next line read is concatenated to the prior line ignoring the right side spaces (at least that's what I have experienced). If you need a space between strings, you may need to do some interesting things to effect that. Put them at the left of the following line. That may be interesting or not. And substitution will expand/shrink internal spaces attempting to preserve column alignment. ISPF tradition. Possibly undesirable if your application demands delimiting by a single space. And two consecutive ampersands suppress substitution, but are not converted to a single ampersand. Intentional behavior for compatibility with Assembler source code, wherein double ampersands abound. And expanding a line beyond record length (which may not be what you expect) results in an execution I/O error. And it's impossible to supply in PARMDD a PARM ending with a space. Ok, I now return you to your regularly scheduled fun and games Like, what's the most efficient way to clear a register? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
On 12/04/2014 03:04 PM, Paul Gilmartin wrote: On 2014-12-04 12:35, Steve Thompson wrote: SNIP Like, what's the most efficient way to clear a register? -- gil SNIP Well, mine is to pull the power plug. I don't have to write code, I don't have to deal with MAKE, BINDER, or anything else. Clears ALL of 'em. And when you power on, they are set to the specified default for POR (or POST as you prefer). Works for all machines. Some have more issues with this than others. HTH. Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
The following definitely works, tested on V2.1 system today. HTH. //YOURJOBX JOB (0,0). . . == Supply your own //* //* DOC: EXPERIMENT WITH INSTREAM SYMBOL SUBSTITUTION. //* // EXPORT SYMLIST=* // SET X='THIS IS A LONG SYMBOL VALUE.' //* //*.+|+|+|+|+|+|+|+| //SYMPARM EXEC PGM=IEFBR14, // PARM='LONG PARM VALUE TO FILL UP TO 100 CHARACTERS AND THEN A SYMBOL* // X' //* //PARMDD EXEC PGM=SHOWPARM,PARMDD=MYPARMDD //STEPLIB DD DISP=SHR,DSN=PDX01.PNSPNS.C0279916.LOAD1 //SYSOUTDD SYSOUT=* //CEEMSGDD SYSOUT=* //CEEDUMP DD SYSOUT=* //LOGSYMS DD SYSOUT=* //MYPARMDD DD *,SYMBOLS=(CNVTSYS,LOGSYMS) LONG PARM VALUE TO FILL UP TO 100 CHARACTERS AND THEN A SYMBOLX LOTS OF DATA TO FILL UP A LINE, FOLLOWED BY A LONG SYMBOL TO SEE X. X ALONE //* //SYMTEST EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT2DD SYSOUT=* //LOGSYMS DD SYSOUT=* //SYSUT1DD *,SYMBOLS=(CNVTSYS,LOGSYMS) LOTS OF DATA TO FILL UP A LINE, FOLLOWED BY A LONG: X X ALONE //* //*.+|+|+|+|+|+|+|+| //* -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: Thursday, December 04, 2014 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PARMDD -- any one use yet? I've run into a situation where we have a parm that expands to more than 100 characters (sound like a familiar problem?). So, I've tried to use the PARMDD EXEC Keyword. And sure enough it points over to the specified DDName. So I have it coded like this: // EXPORT SYMLIST=* : : //PARMLST DD *,SYMBOLS=CNVTSYS (HDY HDT SQP RNO VX CCT CMB) NAP /* And that failed - NONE of the variables were expanded. So I tried this: //PARMLST DD *,SYMBOLS=CNVTSYS ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP /* Only the ISPSTART CMD(NCMPL gets passed and used (because I got the SAYs out of the REXX code). (yes, I am using IKJEFT01, IKJEFT1B, IRXJCL as the PGM=, and this ain't happing). So, has anyone tried this? Have you had any success? Did I read the various wonderful manuals? Yes, all of them z/OS 2.1 (JCL REF, TSO Customization, etc.). I thought, from reading the manuals, that those variables were to be interpreted for this particular DD because of the SYSMBOLS keyword. What am I missing? Regards, Steve Thompson The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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
Re: PARMDD -- any one use yet?
And I should have mentioned that SHOWPARM is just a local utility to display the PARM as a WTO. Any equivalent local program will do. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353 Sent: Thursday, December 04, 2014 4:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD -- any one use yet? The following definitely works, tested on V2.1 system today. HTH. //YOURJOBX JOB (0,0). . . == Supply your own //* //* DOC: EXPERIMENT WITH INSTREAM SYMBOL SUBSTITUTION. //* // EXPORT SYMLIST=* // SET X='THIS IS A LONG SYMBOL VALUE.' //* //*.+|+|+|+|+|+|+|+| //SYMPARM EXEC PGM=IEFBR14, // PARM='LONG PARM VALUE TO FILL UP TO 100 CHARACTERS AND THEN A SYMBOL* // X' //* //PARMDD EXEC PGM=SHOWPARM,PARMDD=MYPARMDD //STEPLIB DD DISP=SHR,DSN=PDX01.PNSPNS.C0279916.LOAD1 //SYSOUTDD SYSOUT=* //CEEMSGDD SYSOUT=* //CEEDUMP DD SYSOUT=* //LOGSYMS DD SYSOUT=* //MYPARMDD DD *,SYMBOLS=(CNVTSYS,LOGSYMS) LONG PARM VALUE TO FILL UP TO 100 CHARACTERS AND THEN A SYMBOLX LOTS OF DATA TO FILL UP A LINE, FOLLOWED BY A LONG SYMBOL TO SEE X. X ALONE //* //SYMTEST EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT2DD SYSOUT=* //LOGSYMS DD SYSOUT=* //SYSUT1DD *,SYMBOLS=(CNVTSYS,LOGSYMS) LOTS OF DATA TO FILL UP A LINE, FOLLOWED BY A LONG: X X ALONE //* //*.+|+|+|+|+|+|+|+| //* -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: Thursday, December 04, 2014 1:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PARMDD -- any one use yet? I've run into a situation where we have a parm that expands to more than 100 characters (sound like a familiar problem?). So, I've tried to use the PARMDD EXEC Keyword. And sure enough it points over to the specified DDName. So I have it coded like this: // EXPORT SYMLIST=* : : //PARMLST DD *,SYMBOLS=CNVTSYS (HDY HDT SQP RNO VX CCT CMB) NAP /* And that failed - NONE of the variables were expanded. So I tried this: //PARMLST DD *,SYMBOLS=CNVTSYS ISPSTART CMD(%NCMPL HDY HDT SQP RNO VX CCT CMB) NAP /* Only the ISPSTART CMD(NCMPL gets passed and used (because I got the SAYs out of the REXX code). (yes, I am using IKJEFT01, IKJEFT1B, IRXJCL as the PGM=, and this ain't happing). So, has anyone tried this? Have you had any success? Did I read the various wonderful manuals? Yes, all of them z/OS 2.1 (JCL REF, TSO Customization, etc.). I thought, from reading the manuals, that those variables were to be interpreted for this particular DD because of the SYSMBOLS keyword. What am I missing? Regards, Steve Thompson The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only
Re: PARMDD -- any one use yet?
On 12/04/2014 04:15 PM, Farley, Peter x23353 wrote: The following definitely works, tested on V2.1 system today. HTH. SNIPPAGE Yeah I'm having a Rod Serling afternoon. I have two JOBs now where I am using this. One works, the other does not. The one that does not work does pass to IKJEFT1B ISPSTART cmd(%NCMPL and that's it. The rest of the parm string is NOT passed. In the ISPLOG file, I can see what ISPF started with, and there is nothing after %NCMPL. In the one that does work, the whole string is there, and it extends beyond 100 characters. I've gone to the JES INIT TUNE to see if you can do strangeness with INITs for this. PDF search did not return anything for it (wouldn't be the first time I mangled a keyword or three). I've been using IEBEYEBALL -4 (because I wear bifocals now) and I just do not see it. I think it is time to reset the registers. No NO, not on the z/FRAME. The windoze laptop... Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD -- any one use yet?
A suggestion then: Specify a SYMBOLS logging DD, as I did in my example. It *should* tell you what substitutions were actually made. Paul Gilmartin had a thread about this a while back (not sure if here or TSO-REXX or where), from which my example was taken and subsequently modified. The problem that can happen is I/O errors when the LRECL is exceeded after symbol substitution (due, we think, to LRECL limitations, maybe in JES for DD * datasets? Don't remember ATM). In any case, the log may help. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Thompson Sent: Thursday, December 04, 2014 5:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARMDD -- any one use yet? On 12/04/2014 04:15 PM, Farley, Peter x23353 wrote: The following definitely works, tested on V2.1 system today. HTH. SNIPPAGE Yeah I'm having a Rod Serling afternoon. I have two JOBs now where I am using this. One works, the other does not. The one that does not work does pass to IKJEFT1B ISPSTART cmd(%NCMPL and that's it. The rest of the parm string is NOT passed. In the ISPLOG file, I can see what ISPF started with, and there is nothing after %NCMPL. In the one that does work, the whole string is there, and it extends beyond 100 characters. I've gone to the JES INIT TUNE to see if you can do strangeness with INITs for this. PDF search did not return anything for it (wouldn't be the first time I mangled a keyword or three). I've been using IEBEYEBALL -4 (because I wear bifocals now) and I just do not see it. I think it is time to reset the registers. No NO, not on the z/FRAME. The windoze laptop... Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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: PARMDD?
In 515866be.3010...@t-online.de, on 03/31/2013 at 06:39 PM, Bernd Oppolzer bernd.oppol...@t-online.de said: Of course, if the called program is PL/1, things get complicated again, because PL/1 needs descriptors (called dope vectors in earlier releases), The dope vectors contained addresses; a descriptor does not. The equivalent of a dope vector is a locator/descriptor, not a descriptor in isolation. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
This is a very philosophical point of view, but: the traditional EXEC PGM= parameter linkage can in fact be seen as a special case of the traditional CALL/ATTACH/XCTL interface, where the reg1 address list contains the address of only 1 parameter, which is a character varying. Two more things, which are special about this case of parameter transfer: the CHAR VAR is limited to 100 bytes (in the traditional PARM= situation), and it is read-only. I was always very impressed about this design, because the normal linkage convention is kind of extended to cover this special case, too. Of course, if the called program is PL/1, things get complicated again, because PL/1 needs descriptors (called dope vectors in earlier releases), so the PL/1 runtime has to cope with this. But for ASSEMBLER and other languages, the PARM= interface works perfectly. Kind regards Bernd Am 31.03.2013 16:54, schrieb Peter Relson: You seem to be contradicting yourself here. Or is there a (new?) way for the initiator to run programs other than the traditional CALL/EXEC/ATTACH/XCTL interface, but transparent to the program which is run? I thought that by mentioning CALL, ATTACH, and XCTLinterface you were referring to the interface to the target routine, where the traditional parameter list format is register 1 pointing to a parameter list each entry of which contained the address of a parameter (or perhaps argument is the proper term here). The interface to an EXEC PGM= target is not that traditional form, of course. The batch initiator does of course still use ATTACH for the jobstep program. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Bernd Oppolzer --- *Oppolzer-Informatik * Dipl. Inf. Bernd Oppolzer Bärenhofstraße 23 70771 Leinfelden-Echterdingen --- Tel.: +49 711 2272522 priv.: +49 711 7949590 eMail: bernd.oppol...@t-online.de mailto:bernd.oppol...@t-online.de --- Für Umsatzsteuerzwecke: SteuerNr.: 97 076 / 29921 USt-ID-Nr.: DE 147 700 393 --- Jubiläumsjahr 2013: 30 Jahre Oppolzer-Informatik -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
Yes, and Bernd's point can be extended. CICS also copes not just with single-parameter but with multi-parameter main programs, options(main) PL/I procedures, too. Peter Relson's distinction is valid and appropriate in one, in many environments the most common, 'standard' context, invalid in others. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
On Sat, 30 Mar 2013 09:15:31 -0400, Peter Relson wrote: PARMDD does not use the traditional CALL/EXEC/ATTACH/XCTL interface. I ??? thought that had been made clear. The use of PARMDD requires no change to programs that can handle any length in the 0-32760 range other than the new binder attribute for AC=1 programs from APF-authorized libraries. You seem to be contradicting yourself here. Or is there a (new?) way for the initiator to run programs other than the traditional CALL/EXEC/ATTACH/XCTL interface, but transparent to the program which is run? I could imagine that the initiator ATTACHes an intermediary which performs PARMDD processing then XCTLs the PGM= program after verifying the AC and LONGPARM attributes. I could also imagine an internals geek's inspecting control blocks and discovering that his program was not directly ATTACHed by the initiator. Such a person might care; I wouldn't. It is true that if the use of PARMDD resulted in passing a halfword length of 0 there would be no threat but there also would be no chance of things working without code changes in the target module. That would greatly inhibit exploitation. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
On Tue, 26 Mar 2013 23:09:16 -0500, Ed Gould wrote: Paul: I think you are reading too much into John's presentation. After thinking about it I would guess that the exec statement and parm will remain essentially the same and if you want to pass a longer parm then you would code the exec pgm=a,parmdd= .. if an old program would look it would get a 0 then however IBM sees fit to pass the new string that would be the rule for long fields. Let me provide a refutation to that reasoning. Circuitous, but one which I find persuasive: If when PARMDD appeared on the EXEC statement an old program simply received R1 - fullword - H'0' ... there'd be no integrity threat in passing PARMDD to old authorized programs. They are all prepared nowadays to handle PARM=''. However, IBM saw fit to provide the LONGPARM attribute on load modules for authorized programs, implying that IBM perceived such a threat, and PARMDD uses the traditional CALL/EXEC/ATTACH/XCTL interface. On Mar 26, 2013, at 10:15 PM, Paul Gilmartin wrote: On Tue, 26 Mar 2013 17:40:24 -0500, Ed Gould wrote: I am *GUESSING* that the new statement is a nod to compatibility. There are just too many programs that accept the current limit and would be broken if the parameter passing was changed. I am OK with it myself. Since any *NEW* program would have to be programmed to accept the parameter list that IBM comes up with. I certainly don't object as it maintain compatibility at no cost. Nope. I got a peek at John Eels's February SHARE SF presentation: � New PARMDD EXEC keyword support longer parameter strings �Mutually exclusive with PARM keyword �No other changes required for unauthorized programs So users will be able to call any old existing program with a long PARM. I hope you don't have too much trouble dealing with it. Me, I'm delighted. You, I suppose you could code a JCL exit to prohibit PARMDD. What do you do today about users who use LINK or ATTACH to supply long PARMS? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
On Tue, 26 Mar 2013 22:15:44 -0500, Paul Gilmartin wrote: Since PARMDD and PARM are mutually exclusive, I should be able to EXEC an existing library PROC, overriding with PARMDD.stepname=MYPARM and expect the PARM coded in the PROC to be nullified, right? I would expect that you would have to code PARM.stepname=,PARMDD.stepname=MYPARM thus nullifying the PARM. But I don't know. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
On Tue, 26 Mar 2013 23:09:16 -0500, Ed Gould wrote: I think you are reading too much into John's presentation. I don't think he is. After thinking about it I would guess that the exec statement and parm will remain essentially the same and if you want to pass a longer parm then you would code the exec pgm=a,parmdd= .. That's what it says. No need to guess. if an old program would look it would get a 0 then however IBM sees fit to pass the new string that would be the rule for long fields. How do you get that impression from reading what is in John's presentation? No other changes required for unauthorized programs -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
On Tue, 26 Mar 2013 16:24:49 -0600, Paul Gilmartin wrote: When long PARMS have been discussed here previously, the reactionaries and IBM loyalists have objected, Oh, no! We can't have that! Suddenly programs that clearly failed on JCL errors will instead program check on buffer overruns and our help desk bandwidth will be strained. Really? I don't remember anyone saying that. What I remember seeing is that any program that accepts a PARM should be coded so that it can be called from a program that might pass a longer PARM. Indeed, when I started as an application programmer in 1970, that was the standard that my code was expected to follow. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
Tom Marchant wrote begin extract Indeed, when I started as an application programmer in 1970, that was the standard that my code was expected to follow. /end extract and that is what I have always recommended and, on occasion, embodied in programming standards. This notion is also embedded in the PL/I convention, as in | appprog: procedure(parm) options(main) reorder ; | | declare parm character(*) varying ; | . . . | declare parml signed binary fixed(15,0), length builtin ; | . . . | parml = length(parm) ; | . . . | | end appprog ; in which parm, like all strings declared to be varying, is here a character string prefixed by a current-length signed-halfword value, 0 = L = 32767. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
On Wed, 27 Mar 2013 07:06:58 -0500, Tom Marchant wrote: When long PARMS have been discussed here previously, the reactionaries and IBM loyalists have objected, Oh, no! We can't have that! Suddenly programs that clearly failed on JCL errors will instead program check on buffer overruns and our help desk bandwidth will be strained. Really? I don't remember anyone saying that. What I remember seeing is that any program that accepts a PARM should be coded so that it can be called from a program that might pass a longer PARM. Non-zero, but not as many as I thought I remembered. Searching the archives for May, 2005, I find, e.g.: On Fri, 13 May 2005 15:56:50 -0400, Arthur T. wrote: ... There *must* be a method to make sure the system does not pass more than 100 bytes to a program which isn't prepared to receive them. Merely expanding PARM= or changing to ZPARM= does not provide that protection. ... And Peter Relson mentioned it as a concern when he originated the thread. It's interesting how many features coming in z/OS 2.1 were mentioned in that thread: o Long PARMs (of course). o A load module attribute indicating a program's willingness to accept long PARMs. o PARM generated from a data set (e.g. PARMDD). o Instream data sets in PROCs o Symbol substitution in instream data sets. o System symbol substitution in batch JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
Ed Jaffe wrote: On 3/26/2013 3:24 PM, Paul Gilmartin wrote: From: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=anappname=iSourcesupplier=877letternum=ENUSZP13-0013 oSupport for passing parameter lists up to 32,760 bytes in length to a program from JCL. A new PARMDD DD statement keyword is ... Typo. It should have said EXEC statement. Obviously. Indeed! EXEC is correct. -- John Eells z/OS Technical Marketing 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: PARMDD?
Paul: I am *GUESSING* that the new statement is a nod to compatibility. There are just too many programs that accept the current limit and would be broken if the parameter passing was changed. I am OK with it myself. Since any *NEW* program would have to be programmed to accept the parameter list that IBM comes up with. I certainly don't object as it maintain compatibility at no cost. Ed On Mar 26, 2013, at 5:24 PM, Paul Gilmartin wrote: From: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias? subtype=cainfotype=anappname=iSourcesupplier=877letternum=ENUSZP13 -0013 oSupport for passing parameter lists up to 32,760 bytes in length to a program from JCL. A new PARMDD DD statement keyword is ... ??? A keyword on the DD statement? How will that work? I might more easily understand a keyword on the EXEC statement. Will whatever DD statement in the job step that asserts PARMDD be taken as the PARM for the step? ... planned to allow more than 100 characters to be passed to any program in JCL. A new LONGPARM binder attribute is planned to enable APF-authorized programs to use this new function. ... (Often discussed here as a security requirement.) A binder attribute seems a much more orderly way to control it than YA PARMLIB member. ... No changes are planned to be needed for unauthorized programs. This new support is intended to make it easier to pass a large number of parameters to a program without writing intermediate programs. When long PARMS have been discussed here previously, the reactionaries and IBM loyalists have objected, Oh, no! We can't have that! Suddenly programs that clearly failed on JCL errors will instead program check on buffer overruns and our help desk bandwidth will be strained. Well, if they're true IBM loyalists, now that IBM is blessing it they'll welcome it. How will the more skeptical customers react? -- 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: PARMDD?
On Tue, 26 Mar 2013 17:40:24 -0500, Ed Gould wrote: I am *GUESSING* that the new statement is a nod to compatibility. There are just too many programs that accept the current limit and would be broken if the parameter passing was changed. I am OK with it myself. Since any *NEW* program would have to be programmed to accept the parameter list that IBM comes up with. I certainly don't object as it maintain compatibility at no cost. That's not the way I read it: http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=cainfotype=anappname=iSourcesupplier=877letternum=ENUSZP13-0013 ... No changes are planned to be needed for unauthorized programs. This new support is intended to make it easier to pass a large number of parameters to a program without writing intermediate programs. Admittedly, I infer in there, ... to exploit this new support. And the JCL, but not the load module will need to be changed to mention PARMDD. I assume that R1 will continue to point to a halfword length, now from 0 to 32760, followed by so many characters of the parameter. Do you see it otherwise? When long PARMS have been discussed here previously, the reactionaries and IBM loyalists have objected, Oh, no! We can't have that! Suddenly programs that clearly failed on JCL errors will instead program check on buffer overruns and our help desk bandwidth will be strained. Well, if they're true IBM loyalists, now that IBM is blessing it they'll welcome it. How will the more skeptical customers react? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
On Tue, 26 Mar 2013 17:40:24 -0500, Ed Gould wrote: I am *GUESSING* that the new statement is a nod to compatibility. There are just too many programs that accept the current limit and would be broken if the parameter passing was changed. I am OK with it myself. Since any *NEW* program would have to be programmed to accept the parameter list that IBM comes up with. I certainly don't object as it maintain compatibility at no cost. Nope. I got a peek at John Eels's February SHARE SF presentation: • New PARMDD EXEC keyword support longer parameter strings • Mutually exclusive with PARM keyword • No other changes required for unauthorized programs So users will be able to call any old existing program with a long PARM. I hope you don't have too much trouble dealing with it. Me, I'm delighted. You, I suppose you could code a JCL exit to prohibit PARMDD. What do you do today about users who use LINK or ATTACH to supply long PARMS? The consipcuous concession to compatibility I see is in making the DDNAME selectable. This provides programmers the facility to work around any DDNAME conflicts that might have arisen if IBM had chosen a fixed DDNAME such as SYSPARM. Since PARMDD and PARM are mutually exclusive, I should be able to EXEC an existing library PROC, overriding with PARMDD.stepname=MYPARM and expect the PARM coded in the PROC to be nullified, right? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PARMDD?
Paul: I think you are reading too much into John's presentation. After thinking about it I would guess that the exec statement and parm will remain essentially the same and if you want to pass a longer parm then you would code the exec pgm=a,parmdd= .. if an old program would look it would get a 0 then however IBM sees fit to pass the new string that would be the rule for long fields. Ed On Mar 26, 2013, at 10:15 PM, Paul Gilmartin wrote: On Tue, 26 Mar 2013 17:40:24 -0500, Ed Gould wrote: I am *GUESSING* that the new statement is a nod to compatibility. There are just too many programs that accept the current limit and would be broken if the parameter passing was changed. I am OK with it myself. Since any *NEW* program would have to be programmed to accept the parameter list that IBM comes up with. I certainly don't object as it maintain compatibility at no cost. Nope. I got a peek at John Eels's February SHARE SF presentation: • New PARMDD EXEC keyword support longer parameter strings • Mutually exclusive with PARM keyword • No other changes required for unauthorized programs So users will be able to call any old existing program with a long PARM. I hope you don't have too much trouble dealing with it. Me, I'm delighted. You, I suppose you could code a JCL exit to prohibit PARMDD. What do you do today about users who use LINK or ATTACH to supply long PARMS? The consipcuous concession to compatibility I see is in making the DDNAME selectable. This provides programmers the facility to work around any DDNAME conflicts that might have arisen if IBM had chosen a fixed DDNAME such as SYSPARM. Since PARMDD and PARM are mutually exclusive, I should be able to EXEC an existing library PROC, overriding with PARMDD.stepname=MYPARM and expect the PARM coded in the PROC to be nullified, right? -- 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
