Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Strange results from IF THEN ELSE
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Wed Sep 22, 2010 8:39 pm    Post subject: Strange results from IF THEN ELSE
Reply with quote

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
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Wed Sep 22, 2010 8:55 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 2:35 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Sep 23, 2010 4:46 pm    Post subject:
Reply with quote

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
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Thu Sep 23, 2010 4:48 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 5:14 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 5:21 pm    Post subject:
Reply with quote

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:
http://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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Sep 23, 2010 5:39 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Sep 23, 2010 5:48 pm    Post subject:
Reply with 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
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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 5:58 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Sep 23, 2010 6:03 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 6:05 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 6:11 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Sep 23, 2010 6:25 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Phrzby Phil

Active Member


Joined: 31 Oct 2006
Posts: 961
Location: Richmond, Virginia

PostPosted: Thu Sep 23, 2010 6:25 pm    Post subject:
Reply with quote

I hope when this finally resolves you guys can go out and have a virtual beer together.
Back to top
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Thu Sep 23, 2010 6:29 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 6:34 pm    Post subject:
Reply with quote

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
View user's profile Send private message
mtaylor

Active User


Joined: 20 Feb 2009
Posts: 108
Location: Kansas City

PostPosted: Thu Sep 23, 2010 6:40 pm    Post subject:
Reply with quote

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
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Thu Sep 23, 2010 6:53 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Captain Paralytic
Warnings : 1

New User


Joined: 21 Apr 2010
Posts: 40
Location: UK

PostPosted: Thu Sep 23, 2010 7:15 pm    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Low values Results from VARCHAR FORMAT balaji81_k DB2 10 Thu Oct 20, 2016 1:18 am
No new posts Strange EXEC function call in z/VM Willy Jensen CLIST & REXX 3 Wed Oct 05, 2016 2:07 pm
No new posts Strange Results with ICETOOL Rohit Umarjikar DFSORT/ICETOOL 4 Tue Dec 22, 2015 4:12 am
No new posts Weird test results when Xpediter is t... Crunch Compuware & Other Tools 6 Tue Oct 06, 2015 7:48 pm
No new posts SORT CAPACITY EXCEEDED Different results abhijit.nayak01 DFSORT/ICETOOL 17 Tue Jun 16, 2015 4:07 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us