On 04/18/2012 10:51 AM, Paul Gilmartin wrote:
On Wed, 18 Apr 2012 09:47:05 -0500, Joel C. Ewing wrote:
On 04/18/2012 08:46 AM, Paul Gilmartin wrote:
On Wed, 18 Apr 2012 09:30:59 -0400, Veilleux, Jon L wrote:
According to the JCL manual that won't work:
The following keywords are the only keywords supported by IBM and recommended
for use in relational-expressions. Any other keywords, even if accepted by the
system, are not intended or supported keywords.
The syntax as "formally" described in the JCL Reference (z/OS 1.12) is
demonstrably incomplete just based on the supplied examples. Something like
// IF (&SYM = value) THEN
is clearly valid by the manual's description if&SYM has a numeric value
and "value" is also some numeric constant ...
No. In:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6b0/17.1.4.2
17.1.4.2 Comparison Operators
Use comparison operators in a relational-expression to compare a keyword
with a numeric value.
...
There is no mention of using a comparison operator to compare two numeric
values.
The "keywords" are listed in:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6b0/17.1.4.5
Note that "TRUE" and "FALSE" are not themselves keywords nor constant
values; they appear only (and superfluously) in complex tokens such as
"ABEND=TRUE" (which means exactly the same as "ABEND". Quine would
shudder).
I think I'll submit another RCF.
But, in their own examples IBM uses as valid constant values things
like "Unnn", "Snnn", "TRUE", "FALSE", none of which are described as
These are not used as constant values, but as lexical parts of "keywords".
keywords and which clearly are not numeric in the normal sense of the
word! Obviously some special alphanumeric constants are acceptable,
which begs the question why other arbitrary alphanumeric constants that
can't be confused with keywords should not be explicitly allowed as
operands as well. (Maybe they work even though undocumented, but usage
in that case would be risky!)
If the relational expressions directly supported by JCL are found too
restrictive, one could always write a fairly trivial utility ...
JCL tailoring with ISPF skeletons?
-- gil
ISPF skeletons would only be an alternative if dynamically submitting
another batch job is acceptable.
The referenced 17.1.4.2 section is very definitely in conflict with the
actual IF JCL implementation. I successfully used for years such forms as
IF (&OPT = 1) THEN
and
IF (&OPT = 0) THEN
where &OPT was set on a prior SET statement to have a value of "0" or
"1", to allow various job steps to be executed conditionally based on a
set of "option" statements at the start of the job stream. Much easier
than hunting for the job steps, and the expected results of "1 = 1" and
"0 = 0" being taken as TRUE and "1 = 0" and "0 = 1" being taken as FALSE
were as intuitively expected.
So does IBM change the docs to agree with the implementation (the
cheaper solution), or do they change the code to not conflict with the
docs (which may break existing usage)? In any event, the existing JCL
documentation should not be incomplete, confusing, and inconsistent with
the implementation. There is a lot to be said for more formal syntax
and semantic descriptions.
I confess to having less familiarity with ABENDCC keyword forms, never
having had a need to use one. So, "U001" in "ABENDCC=U001" is a
"lexical part" of a keyword? Good Lord, who invented this syntax? So
in the context of an "IF" statement relational expression, "=" is both a
relational operator and also a lexical part of such key words as the
above. A rational person familiar with practically any other
programming language (and with other JCL relational expressions) would
intuitively expect given "ABENDCC=U001" as valid, for "ABENDCC = U001",
"ABENDCC EQ U001", and "ABENDCC NE U001" to all be legal syntax, which
they apparently are not. It is a confusing and unnatural syntactic act
to permit the same special symbol to serve as both an operator and as
part of a keyword!
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
