|
View previous topic :: View next topic
|
| Author |
Message |
vinay19
New User
Joined: 31 May 2007
Posts: 24
Location: Bangalore
|
|
|
|
Hello,
I have a cataloged procedure whose skeleton is as mentioned below.
//TESTPROC PROC
//PSTEPA EXEC SAS
-----------------------
-----------------------
// IF PSTEPA.SAS.RC = 0 THEN
//PSTEPB ....
//PSTEPC ....
As you can see I am validating return code of the sas program executed in PSTEPA.
Now I execute this proc from my JCL. This setup works perfectly fine for me if am invoking the above proc only once from my JCL.
e.g JCL1:
//STEP1 EXEC TESTPROC,PARM=1
Whereas I have a problem if I am invoking the proc multiple times, starting from second time onwards.
When I scan my JCL (JCL2), it says "STATEMENT NAMED "PSTEPA " IS A DUPLICATE"
e.g JCL2:
//STEP1 EXEC TESTPROC,PARM=1
//STEP2 EXEC TESTPROC,PARM=2
Also return code PSTEPA.SAS.RC will be retained to what value it gets set when the proc executes for first time.
I need to execute the proc multiple times for different parameters. Although I have found a work around, I wanted to know the reason for this behavior.
Thanks |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| vinay19 wrote: |
| Also return code PSTEPA.SAS.RC will be retained to what value it gets set when the proc executes for first time. |
I vaguely recall that is correct. As for the reason - you will need to ask IBM for that one. |
|
| Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA
|
|
|
|
I think it's been stated enough times here how it's never a good idea to use nested procs, so I won't comment on that.
As far as ...
| vinay19 wrote: |
| Also return code PSTEPA.SAS.RC will be retained to what value it gets set when the proc executes for first time. |
I'm going to have to see if that is a true statement since it doesn't make logical sense to me why it would act that way. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
when one uses cond codes
- as apposed to IF/THEN - which is so flexible
you don't have the problem....... |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
Of course, if the person who used the IF statement in the proc had coded the JCL correctly, there would never be a problem, no matter how many nested levels are used.
Something I found out the fun way by trying to correct the errors of another, and always code my procs properly if I use IF/THEN/ELSE/ENDIF statements  |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
this is not a nested proc problem!
this is the same proc invoked repeatedly by the job,
something that is done often,
such as compiling many modules, with a parm for module name for each invocation of the proc.
as expat says, if the rookie had coded the IF/THEN properly, there would be no problem. |
|
| Back to top |
|
|
vinay19
New User
Joined: 31 May 2007
Posts: 24
Location: Bangalore
|
|
|
|
| Same is the problem with use of COND CODES. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Vinay wrote: |
Same is the problem with use of COND CODES.
|
| dbz wrote: |
| as expat says, if the rookie had coded the IF/THEN properly, there would be no problem |
same applies..... |
|
| Back to top |
|
|
|
|
