and this is JCL ERROR ?
//SETV SET VERSION=B
//STEPNULL EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//IF1 IF STEPNULL.RC= 0 AND &VERSION=A THEN
//VERSIONA EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//ENDIF1 ENDIF
//IF1 IF STEPNULL.RC= 0 AND &VERSION=B THEN
//VERSIONB EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//ENDIF1 ENDIF
//IF1 IF STEPNULL.RC= 0 AND &VERSION=C THEN
//VERSIONC EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//ENDIF1 ENDIF
STMT NO. MESSAGE
5 IEFC013I ERROR IN IF STATEMENT: B NOT VALID
9 IEFC013I ERROR IN IF STATEMENT: B NOT VALID
13 IEFC013I ERROR IN IF STATEMENT: B NOT
VALID
The example that works use valid return code values (0-4095) and
therefore is seen as a value rather a symbol (I think).
Birger Heede
IBM DK
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
This doesn't directly address the special case where two numeric values
(after substitution) are being compared - in fact nowhere is it stated
that comparison of two values where neither is a keyword is a legal
syntax, although we know from empirical evidence it works with two
numerics.
The manual does imply rather strongly that the JCL IF/THEN/ELSE
relational operators work with numeric values only, not character
strings; and this interpretation is re-enforced by the lack of a syntax
for defining a character string constant.
Since string constants are not supported for these statements, the JCL
interpreter would attempt to parse "A", "B", or "C" operands to a
relational operator as a keyword and fail. So Birger is technically
correct in referring to this as an unacceptable "keyword", although this
explanation is confusing since the user obviously intended these to be
interpreted as string constants.
The inclusion of the always-true "STEPNULL.RC= 0 AND" portion of the
statements is irrelevant as to whether the statement is acceptable.
JC Ewing
--
Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org
I want to know if someone of you have faced some similar problem and its
solution or explanation.
OS/390 2.9
.-remove member SYS1.PROCLIB(JOBA).
.-from console "S JOBA"
.-the JOBA job is being started
.-IPL
.-from console "S JOBA"
.-Now the JOBA is NOT being started.
Another test
.-Remove the SYS1.PROCLIB library
.-S JOBA
.-The JOBA is being started and any job from the SYS1.PROCLIB can be
started too.
.-IPL
.-Now the SYS1.PROCLIB is not found.
Why i must IPL to take the SYS1.PARMLIB changes?
Is there some JES2 parameter to avoid this situation or PTF?
Best regards and thanks for helping me.
Enrique
I would try submitting a job that opens a different PROCLIB in JES2 and then reopen the SYS1.PROCLIB dataset, see if it is gone then.
Other - more drastic option is to bounce JES2.
Lizette
Birger Heede
IBM DK
----------------------------------------------------------------------
>More explicitly, the JCL reference manual states:
>"Use comparison operators in a relational-expression to compare a
>keyword with a numeric value."
>
>This doesn't directly address the special case where two numeric values
>(after substitution) are being compared - in fact nowhere is it stated
>that comparison of two values where neither is a keyword is a legal
>syntax, although we know from empirical evidence it works with two
>numerics.
>
This is dreadful! If the comparison doesn't work as expected,
IBM's out is to say you broke the rules, but they provide no
error message.
And nearby:
17.1.4.5 "z/OS V1R11.0 MVS JCL Reference"
17.1.4.5 Relational-Expression Keywords
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.
And elsewhere nearby:
17.1.9 Considerations when Using the IF/THEN/ELSE/ENDIF Construct
* You can specify symbolic parameters on IF/THEN/ELSE/ENDIF statements provided that
they resolve to one of the supported relational-expression keywords listed in the
preceding topic (that is, RC, ABEND, ...). Any other symbolic parameters, even if
accepted by the system, are not intended or supported.
So,
// SET X='STEP.RC'
// IF (&X=4) THEN
is apparently supported, but:
// SET Y=4
// IF (STEP.RC=&Y) THEN
is unsupported.
Both the JCL parser and the doc should mutually be revised so that
all constructs "accepted by the system" are described as "supported"
and/or constructs not described as "supported" such as the OP
attempted result in JCL errors.
A BNF syntax diagram would be useful here.
-- gil
I will check both options.
Bye,
Enrique
Well, I need the STEPNULL step because if the JOB has ONLY this
//SETV SET VERSION=8
//IF1 IF &VERSION=7 THEN
//VERSION7 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//ENDIF1 ENDIF
//IF1 IF &VERSION=8 THEN
//VERSION8 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//ENDIF1 ENDIF
//IF1 IF &VERSION=9 THEN
//VERSION9 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//ENDIF1 ENDIF
I get STEP VERSION7 (and VERSION8) executed
JOBNAME- --STEP-- -PSTEP-- CCODE
IEFBR14 VERSION7 0
IEFBR14 VERSION8 0
IEFBR14 VERSION9 FLUSH
>> - Mostrar texto de la cita -
>
> Well, I need the STEPNULL step because if the JOB has ONLY this
> //SETV SET VERSION=8
> //IF1 IF &VERSION=7 THEN
> //VERSION7 EXEC PGM=IEFBR14
> //SYSPRINT DD SYSOUT=*
> //ENDIF1 ENDIF
> //IF1 IF &VERSION=8 THEN
> //VERSION8 EXEC PGM=IEFBR14
> //SYSPRINT DD SYSOUT=*
> //ENDIF1 ENDIF
> //IF1 IF &VERSION=9 THEN
> //VERSION9 EXEC PGM=IEFBR14
> //SYSPRINT DD SYSOUT=*
> //ENDIF1 ENDIF
>
> I get STEP VERSION7 (and VERSION8) executed
> JOBNAME- --STEP-- -PSTEP-- CCODE
> IEFBR14 VERSION7 0
> IEFBR14 VERSION8 0
> IEFBR14 VERSION9 FLUSH
I didn't say you didn't need the STEPNULL step, only that testing its RC
in your IF statements was unnecessary.
You DO need the STEPNULL job step in this case, because the first step
of any job is unconditionally executed and cannot be skipped by
conditional logic. It seems like a petty restriction, but probably
related to the requirement that each job be guaranteed to have at least
one job step that is actually executed.
--
Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
>I didn't say you didn't need the STEPNULL step, only that testing its RC
>in your IF statements was unnecessary.
>
>You DO need the STEPNULL job step in this case, because the first step
>of any job is unconditionally executed and cannot be skipped by
>conditional logic. It seems like a petty restriction, but probably
>related to the requirement that each job be guaranteed to have at least
>one job step that is actually executed.
>
>--
>Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org
Not entirely true.
This works fine on my z/OS 1.9 system:
//H224$TST JOB (0200),'BSquare',CLASS=X,MSGCLASS=X,NOTIFY=&SYSUID
//*
// EXEC PGM=IEFBR14,COND=ONLY
//*
// IF (U0100 = U0140) THEN
//IGNORED EXEC PGM=IEFBR14
// ENDIF
producing:
-STEPNAME PROCSTEP RC EXCP CONN TCB
- FLUSH 0 0 .00
-YES1 FLUSH 0 0 .00
-NO1 FLUSH 0 0 .00
IEF404I H224$TST - ENDED - TIME=07.33.23
Thus the first step is not executed, skipped by conditional logic (although
neither via the IF statement, nor by RC).
NOTE the IF works fine. If there was an ELSE clause, it would have been
executed (yes, I tried it). I left it off so NONE of the steps would be executed.
>//H224$TST JOB (0200),'BSquare',CLASS=X,MSGCLASS=X,NOTIFY=&SYSUID
>//*
>// EXEC PGM=IEFBR14,COND=ONLY
>//*
>// IF (U0100 = U0140) THEN
>//IGNORED EXEC PGM=IEFBR14
>// ENDIF
>
Sorry, wrong output. This is the output from that run:
-STEPNAME PROCSTEP RC EXCP CONN
- FLUSH 0 0
-IGNORED FLUSH 0 0
>I want to know if someone of you have faced some similar problem and its
>solution or explanation.
Read Lizette's message. Keep in mind that if you have multiple Converter
tasks then you need to force all of them to close the proclib
concatenations that they have open, so you will need to submit multiple
jobs with PROC=xx concurrently.
--
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)