|
View previous topic :: View next topic
|
| Author |
Message |
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
The code:
| Code: |
//SOMEJOB JOB
//*
// IF (TRUE) THEN
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 1
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 2
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
executes STEP1 but not STEP2 as expected. However the code:
| Code: |
//SOMEJOB JOB
//*
// IF (FALSE) THEN
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 1
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 2
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
executes both STEP1 and STEP2.
One can substitute ¬ABEND and ABEND for TRUE and FALSE respectively and get the same results.
Adding a step such as:
| Code: |
| //DONOWT EXEC PGM=IEFBR14 |
before the IF causes the operation to be more intuitive, but I'm intrigued as to why the TRUE gives expected operation whilst FALSE does not. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Your job does not match the requirements for the IF statement in the manual:
| Quote: |
You can code the IF/THEN/ELSE/ENDIF statement construct anywhere in the job after the JOB statement. Code it as follows:
//[name] IF (relational expression) THEN
//STEPTRUE EXEC
//[name] ELSE
//STEPFALS EXEC
// ENDIF
The relational expression consists of:
* Comparison operators
* Logical operators
* Not (¬) operators
* Relational expression keywords.
Comparison operators compare a relational expression keyword to a numeric value. The comparison results in a true or false condition. |
Since you did not specify a comparison operator, I suspect that the results of your IF statement are unpredictable -- although I haven't found any manual statement positively stating so. The mere fact that you are not constructing a relational expression as given in the manual means you need to be cautious as you are outside the bounds of supported behavior and literally anything could happen. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Robert Sample wrote: |
| Your job does not match the requirements for the IF statement in the manual: |
Thank you for your reply.
However I must point out that my job DOES match the requirements in the manual since TRUE, FALSE, and ABEND are relational expression keywords.
In the list of keywords it specifies "ABEND=TRUE" and "ABEND=FALSE"
These keywords can be used without a comparison operator as shown in this example from the manual:
| Code: |
| //IFTEST6 IF ¬ABEND THEN |
and in my post I stated:
| Quote: |
| One can substitute ¬ABEND and ABEND for TRUE and FALSE respectively and get the same results. |
So my question still stands! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Please learn some rules of logic before you spout such nonsense again. IF (TRUE) is not the same as IF ¬ABEND -- there is an implied relational condition in the latter expression (you are actually saying IF ABEND=FALSE) that is not implied in the first expression since there is no variable to be tested. My answer stands because you have provided no documentation to refute my manual quote -- a relational expression in the JCL Language Reference manual requires a construct of the form variable <relational operator> expression whether the full relational is implicitly stated or explicitly coded.
Do not confuse JCL IF statements with any programming language IF statement. They are not the same and the JCL IF statement is extremely restricted and must match the manual requirements or unpredictable results can occur. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Did i miss something? I couldnt find anything about TRUE or FALSE in
z/OS V1R1.0 MVS JCL Reference.
Only the next supported keywords :
RC indicates a return code
ABEND indicates an abend condition occurred
¬ABEND indicates no abend condition occurred
ABENDCC indicates a system or user completion code
RUN indicates that the specified step started execution
¬RUN indicates that the specified step did not start execution |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Robert Sample wrote: |
| My answer stands because you have provided no documentation to refute my manual quote -- a relational expression in the JCL Language Reference manual requires a construct of the form variable <relational operator> expression whether the full relational is implicitly stated or explicitly coded. |
Please read my response again. I HAVE supplied documentation to refute your statement.
I posted (and repeated in my second post)
| Quote: |
| One can substitute ¬ABEND and ABEND for TRUE and FALSE respectively and get the same results. |
Since you cannot seem to grasp this I shall explain that this means that if you try:
| Code: |
//SOMEJOB JOB
//*
// IF (¬ABEND) THEN
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 1
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 2
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
it executes STEP1 but not STEP2 as expected (the same as using TRUE).
But if you try:
| Code: |
//SOMEJOB JOB
//*
// IF (ABEND) THEN
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 1
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 2
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
then it executes both STEP1 and STEP2 (the same as using FALSE).
I shall accept your implicit apology for suggesting that I do not understand the rules of logic.
The observation that I posted about TRUE and FALSE behaving in exactly the same way as ¬ABEND and ABEND was just that, an observation. I was very careful TWICE to state that the behaviour I was reporting happens whether one uses TRUE/FALSE or ¬ABEND/ABEND.
On the subject of logic, if a construct is shown as:
variable <relational operator> expression is required, it means that it is explicitly required, otherwise the syntax would be written as: variable [<relational operator> expression] to indicate that the latter part may be implied and is thus optional. However nowhere in the manual does it actually define a relational-expression as having a syntax of variable <relational operator> expression.
Now, if you've finished being rude and getting things wrong, do you have anything constructive to add to the actual query? |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| PeterHolland wrote: |
Did i miss something? I couldnt find anything about TRUE or FALSE in
z/OS V1R1.0 MVS JCL Reference. |
Hi Peter. I don't know about the V1R1.0 manual but there is mention of it in the R7.0 and R9.0 ones.
Here is a link to the R9.0 page:
publib.boulder.ibm.com/infocenter/zos/v1r9/topic/com.ibm.zos.r9.ieab600/iea2b670688.htm#wq1185
But as I have pointed out 3 times now, the issue is not about TRUE/FALSE (which by experiment appear to operate in exactly the same way as ¬ABEND/ABEND in that order), it is about the fact that when the relational-expression is logically TRUE, only the THEN portion executes, but if it is logically FALSE, both the THEN and the ELSE portions execute, unless a dummy step is placed to precede the expression. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
The point I make -- which you are totally ignoring -- is that IF (TRUE) and IF (FALSE) are not valid to use in JCL. They may not cause a syntax error, but the manual does not state that they are allowed -- so unpredictable results at best. So you get results with them -- who cares? They are not listed in the manual, so the results could vary by release of z/OS and what works now may not work next year.
I still think you do not understand the rules of logic -- if you think IF (TRUE) and IF (¬ABEND) are the same, then you do not understand the rules of logic. The first is not JCL and may produce any result -- the second if checking to see if any previous step in the job has abended and executing the THEN if none have.
The manual specifcally states that IF (TRUE) and IF (FALSE) are not supported:
| Quote: |
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.
Keyword Use
RC
indicates a return code
ABEND
indicates an abend condition occurred
¬ABEND
indicates no abend condition occurred
ABENDCC
indicates a system or user completion code
RUN
indicates that the specified step started execution
¬RUN
indicates that the specified step did not start execution |
Furthermore, since you have not actually generated an abend in a previous step, who knows what the system will do? If you stated that you had your IF statements in a job, had a step abend, and both parts of the IF statement executed -- THEN I would recommend opening a PMR with IBM for the defect. But since this is not what you've done, there's no way to state that the behavior you are seeing is even wrong. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Placing an execution of IEFBR14 after the JOB statement and before the IF statement causes only one of the two steps to execute for your code
| Code: |
//SOMEJOB JOB
//*
// IF (ABEND) THEN
//STEP1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 1
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 2
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
so the anomaly of both steps executing whenever there is no previous step needs to be reported to IBM, but once the JCL has a step before the IF statement, the behavior of the IF statement is correct. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
And I am stating that the TRUE/FALSE bit is NOT THE POINT!
If an ABEND has NOT happened previous to the IF, then according to the manual, only the ELSE portion should execute. This is because the relational-expression is logically false.
If an abend has not happened then ABEND should be logically FALSE and this should result in only the ELSE part executing.
When an abend has not happened ¬ABEND is true and this is correctly causing only the THEN part to execute, but the reverse is not happening.
The manual quite clearly says:
| Quote: |
//[name] IF [(]relational-expression[)] THEN [comments]
.
. action when relational-expression is true
.
//[name] ELSE [comments]
.
. action when relational-expression is false
.
//[name] ENDIF [comments] |
but this is not what is happening.
Nowhere in the manual can I find it stating that "when relational-expression is false, both the THEN and ELSE part will execute".
Your statement "since you have not actually generated an abend in a previous step, who knows what the system will do?" seems to suggest a complete lack of understanding of how IF/THEN/ELSE constructs are supposed to operate.
FALSE is the opposite of TRUE. So to test an IF/THEN/ELSE construct, one has to first have the relational-expression to be logically TRUE and then to have it logically FALSE (or vice-versa).
When using the ABEND keyword, this can be achieved by using the NOT operator ¬ in front of the keyword.
When this is done the construct works as suggested in the manual. When testing with a logically FALSE relational-expression, the outcome is not as documented.
I really cannot see why you are finding this so difficult to comprehend! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
This JCL:
| Code: |
//STEP0 EXEC PGM=IEFBR14
// IF (¬ABEND ) THEN
//STEP1 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
produces
| Code: |
JOBNAME STEPNAME PROCSTEP RC
RS0CCTST STEP0 00
RS0CCTST STEP1 00
RS0CCTST STEP2 FLUSH |
Hence your statement
| Quote: |
| When this is done the construct works as suggested in the manual. When testing with a logically FALSE relational-expression, the outcome is not as documented. |
is proven to be false -- the manual documents the behavior shown in my job. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Robert Sample wrote: |
| Placing an execution of IEFBR14 after the JOB statement and before the IF statement causes only one of the two steps to execute for your code, so the anomaly of both steps executing whenever there is no previous step needs to be reported to IBM, but once the JCL has a step before the IF statement, the behavior of the IF statement is correct. |
And this is what I have been saying since the first post. It has taken you an awful long time and an awful lot of rudeness to finally understand what was quite clearly stated in the very first post.
You seem to have carelessly omitted an explicit apology from this post. I shall once again assume an implicit one and generously excuse you. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Robert Sample wrote: |
This JCL:
| Code: |
//STEP0 EXEC PGM=IEFBR14
// IF (¬ABEND ) THEN
//STEP1 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
produces
| Code: |
JOBNAME STEPNAME PROCSTEP RC
RS0CCTST STEP0 00
RS0CCTST STEP1 00
RS0CCTST STEP2 FLUSH |
Hence your statement
| Quote: |
| When this is done the construct works as suggested in the manual. When testing with a logically FALSE relational-expression, the outcome is not as documented. |
is proven to be false -- the manual documents the behavior shown in my job. |
You really do have a problem with logic don't you.
If there is no abend, then ABEND is logically FALSE and then ¬ABEND is logically TRUE (since NOT FALSE = TRUE)
and since my statement is related to a "logically FALSE" relational-expression, showing test results for a "logically TRUE" one has no bearing on my statement.
Please go away and brush up on your Boolean Algebra before posting again. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Code: |
//STEP0 EXEC PGM=IEFBR14
// IF ( ABEND ) THEN
//STEP1 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 1
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 2
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
produces
| Code: |
JOBNAME STEPNAME PROCSTEP RC
RS0CCTST STEP0 00
RS0CCTST STEP1 FLUSH
RS0CCTST STEP2 00 |
Either way your statement is not true -- no matter how you twist semantics to support yourself. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| I hope when this finally resolves you guys can go out and have a virtual beer together. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
Mr Captain,
I think you have missed the most important point:
Robert Sample wrote:
| Quote: |
Placing an execution of IEFBR14 after the JOB statement and before the IF statement causes only one of the two steps to execute for your code
|
You can not put your IF statment before the First step and expect predictable results.
The manual says:
| Quote: |
ABEND=FALSE or |ABEND - a lack of an abend condition in any prior
job step
|
|
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| Robert Sample wrote: |
| Code: |
//STEP0 EXEC PGM=IEFBR14
// IF ( ABEND ) THEN
//STEP1 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 1
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ELSE
//STEP2 EXEC PGM=IEBGENER,COND=EVEN
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD *
STEP 2
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
// ENDIF |
produces
| Code: |
JOBNAME STEPNAME PROCSTEP RC
RS0CCTST STEP0 00
RS0CCTST STEP1 FLUSH
RS0CCTST STEP2 00 |
Either way your statement is not true -- no matter how you twist semantics to support yourself. |
Sheesh! Please read my first post in this thread!!!!
I stated quite clearly that the strange and inconsistent behaviour ONLY OCCURRED if the IF was the first thing in the JOB.
I stated QUITE CLEARLY that:
Adding a step such as:
//DONOWT EXEC PGM=IEFBR14
cause the behaviour to be correct. My statement is QUITE CLEARLY made about the condition when the IF is the first statement in the job.
Your results are when there is a job step BEFORE the IF and I have in my very first post QUITE CLEARLY STATED that the behaviour is correct then.
I'm sure it is not your fault that you quite obviously lack the intelligence to read properly nor interpret logic correctly. But even taking that into account you are needlessly rude. |
|
| Back to top |
|
|
mtaylor
Active User
Joined: 20 Feb 2009
Posts: 108
Location: Kansas City
|
|
|
|
Thanks for uncovering this nice little tid bit. I don't recall if I coded my JCL parser to accept an IF as the first statement in a job or not, I'll have to check. Although now that I think about it, there may be verbage in the manual to specify IF may not be first in a job.
Note; I also prefer the OS 390 JCL manual over any of the Z/OS ones. They rewrote and obfuscated a lot of relavent information in the newer manuals. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
The Captain said:
| Quote: |
I'm sure it is not your fault that you quite obviously lack the intelligence to read properly nor interpret logic correctly. But even taking that into account you are needlessly rude.
|
Please tell me what I said you felt was needlessly rude?
Did I personally attack your intelligence as you did with me? Now If I did, then that would be rude.
With regard to my intelligence, I will have you know:
I can walk and chew gum at the same time.
I can drive a manual transmission automobile.
I can read a newpaper, listen to my wife, and agree with her all at the same time.
I can solve a rubix cube.
I know the capitals of all 50 US states (and most European countries)
So before you are needlessly rude and attack my intelligence, please ask me if I can perform the above tasks.
Back to the topic though, so this all started, when you coded your JCL in a way not supported in the manual, and pondered why the results are unpredicatble.
Does that sum it up? |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| daveporcelan wrote: |
Mr Captain,
I think you have missed the most important point:
Robert Sample wrote:
| Quote: |
Placing an execution of IEFBR14 after the JOB statement and before the IF statement causes only one of the two steps to execute for your code
|
You can not put your IF statment before the First step and expect predictable results.
The manual says:
| Quote: |
ABEND=FALSE or |ABEND - a lack of an abend condition in any prior
job step
|
|
Robert Sample may have written
| Quote: |
Placing an execution of IEFBR14 after the JOB statement and before the IF statement causes only one of the two steps to execute for your code
|
But I wrote that in the very first post in this thread. Thus it was not me who missed this important point, it was me who MADE this point! It is Robert who missed the point until quite late on in the "discussion" and even when he brought it up he did not manage to work out that my statements which he said were false specifically surrounded whether this JOB step was present or not. |
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| mtaylor wrote: |
Thanks for uncovering this nice little tid bit. I don't recall if I coded my JCL parser to accept an IF as the first statement in a job or not, I'll have to check. Although now that I think about it, there may be verbage in the manual to specify IF may not be first in a job.
Note; I also prefer the OS 390 JCL manual over any of the Z/OS ones. They rewrote and obfuscated a lot of relavent information in the newer manuals. |
I am just writing some feedback for the manual since, as pointed out by other posters in this thread, the list of what may be in a relational-expression is not compete. It states
| Quote: |
A relational-expression consists of:- Comparison operators
- Logical operators
- NOT (¬) operators
- Relational-expression keywords.
|
But it does not state that it may also contain:
- Integer constants (e.g. 04, 08)
- Boolean constants (TRUE, FALSE)
which it quite plainly does. |
|
| Back to top |
|
|
nil_mf
New User
Joined: 06 Jun 2005
Posts: 29
|
|
| Back to top |
|
|
Captain Paralytic
Warnings : 1
New User
Joined: 21 Apr 2010
Posts: 40
Location: UK
|
|
|
|
| nil_mf wrote: |
"An IF statement specified before the first EXEC statement in a job is not evaluated before the first step executes. If the IF statement applies to later steps in the job, the statement will be evaluated when the system decides whether to process the later steps.
|
Yes, but as we have seen, this statement is not correct! The IF statement DOES get evaluated when the relational-expression is true.
I would expect consistency. Either the statement is NOT evaluated so that both the THEN and ELSE part are always executed, regardless of the logical value of the relational-expression, or it is always evaluated.
What we are seeing is that the relational-expression is evaluated and if its result is TRUE, then the IF statement operates in the normal way for an IF statement, but if the result is FALSE, the steps are executed as if the IF statement is not there. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
The IF statement is not evaluated, hence STEP1 executes.
The IF evaluation is done to determine whether or not to perform STEP2 -- per the manual statement nil_mf quoted. If the evaluation is such that the ELSE condition is selected, STEP2 executes. If the ELSE condition is not selected, STEP2 does not execute. So either the first step or both steps will be executed, depending upon the IF condition.
The manual statement from nil_mf, applied to your example, has predictable and understandable results. |
|
| Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia
|
|
|
|
| So - you guys gonna have that beer now? |
|
| Back to top |
|
|
|
|
