The way JCL processing deals with multiple assignments of values to the same
symbolic
parameter in a JCL PROC is inconsistent with the way the same construct is
dealt with
for SET statements.
IBM publication "z/OS MVS JCL Reference" (SA22-7597-13) is clear about
the handling of SET statements:
In <4c332ecc.90...@acm.org>, on 07/06/2010
at 08:25 AM, "Joel C. Ewing" said:
>This would be a semantic error (dealing with meaning),
No, it would be a syntax error that is easier to catch with a semantic
constraint than with classical parsing techniques. Do not confuse
"grammar" with, e.g.,
In <45e5f2f45d7878458ee5ca6796973355213...@usdaexch01.kbm1.loc>, on
07/06/2010
at 08:22 AM, "Staller, Allan" said:
>Again, what is syntactically incorrect?
Duplicate keywords.
>Everything after PROC=A# is a parameter or nullification (V=) passed
>to the procedure.
"SP1=3000" is not passed t
In <45e5f2f45d7878458ee5ca6796973355213...@usdaexch01.kbm1.loc>, on
07/06/2010
at 07:27 AM, "Staller, Allan" said:
>Why? What is syntactically incorrect with the below?
The duplicate keywords.
>Without observing the procedure being called, it is impossible to
>determine if a syntax error is
>I might at first say "see you next Tuesday at 10" and a little later say "I
>might be
running late, so make it between 10 and 11."
>You would not ignore the latter value because I had already provided an
>earlier value.
I might if I didn't check my e-mail regularily.
Also, relating programmin
ssage-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Vernooij, CP - SPLXM
Sent: Tuesday, July 06, 2010 7:33 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Amusing JCL Oddity
"Paul Gilmartin" wrote in message
news:...
> It's a prevalent habit of co
"Paul Gilmartin" wrote in message
news:...
> On Tue, 6 Jul 2010 06:54:54 -0700, Charles Mills wrote:
>
> >It seems to me that it is JCL's "job" to catch the error because the
writer
> >of the PROC has no opportunity to do so. It's an obvious opportunity
for a
> >"dumb user" error -- and it's the
On Tue, 6 Jul 2010 06:54:54 -0700, Charles Mills wrote:
>It seems to me that it is JCL's "job" to catch the error because the writer
>of the PROC has no opportunity to do so. It's an obvious opportunity for a
>"dumb user" error -- and it's the job of the "system" (broadly defined to
>include JCL,
rror at the macro invocation level.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Staller, Allan
Sent: Tuesday, July 06, 2010 5:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Amusing JCL Oddity
Why? What is syntactically incorrect wi
John,
Actually, it is documented to work that way.
According to the JCL reference, if the same symbolic keyword is present
multiple time, the value used is that provided by the first occurrence.
Checking back through some old manuals, this has been the case since at
least OS/360 r21.7.
John P.
This would be a semantic error (dealing with meaning), not a syntax
error (the physical ordering of symbols).
I believe the point is that the semantic error of repeating the same
keyword parameter is detected as an error in some cases (like on a DD
statement), so it is inconsistent that the same q
Again, what is syntactically incorrect?
Everything after PROC=A# is a parameter or nullification (V=) passed to
the procedure.
:
>Why? What is syntactically incorrect with the below?
>Without observing the procedure being called, it is impossible to
>determine if a syntax error is in place.
>
>/
On Tue, 6 Jul 2010 07:27:01 -0500, Staller, Allan wrote:
>Why? What is syntactically incorrect with the below?
>Without observing the procedure being called, it is impossible to
>determine if a syntax error is in place.
>
>//ALLOC EXEC PROC=A#,SP1=100,SP2=100,
>// HLVL=USS,MLVL=SMPNT
Why? What is syntactically incorrect with the below?
Without observing the procedure being called, it is impossible to
determine if a syntax error is in place.
The converter/interpreter will find syntax errors in JCL. The "classic"
JCL error.
Job Failed due to file not found,. GDG BASE not found,
14 matches
Mail list logo
