Did you look at all of the error messages? On my test:
//*                     
//PROC1 PROC            
//PROC2 PROC            
//STEP1 EXEC PGM=IEFBR14
//DD1    DD  *          
THIS IS JUST WRONG      
/*                      
//PROC2 PEND            
//PROC1 PEND            
//*                     
//STEP EXEC PROC=PROC1  

I got this:3 //PROC1 PROC                                                       
   
  //PROC2 PROC                                                          
  //STEP1 EXEC PGM=IEFBR14                                              
  //DD1    DD  *                                                        
  //PROC2 PEND                                                          
4 //PROC1 PEND                                                          
  //*                                                                   
5 //STEP EXEC PROC=PROC1                                                
6 ++PROC1 PROC                                                          
7 ++PROC2 PROC                                                          
8 ++STEP1 EXEC PGM=IEFBR14                                              
9 ++DD1    DD  *                                                        
. MESSAGE                                                               
4 IEFC019I MISPLACED PEND STATEMENT                                     
5 IEFC001I PROCEDURE PROC1 WAS EXPANDED USING INSTREAM PROCEDURE 
DEFINIT
7 IEFC658I PROC VERB STATEMENT OUT OF SEQUENCE                          
9 IEFC601I INVALID JCL STATEMENT                                        


It complains about the second PEND because you can not nest PROCs inside 
each other, it does complain about the second PROC, and it complains about 
instream data (DD *) inside a PROC. Looks normal to me.

Isn't a proc defined as something that has steps? Meaning, not a stream of 
nested procs. What you can do is invoke a proc from a proc. Don't recall 
today's limit, believe 8 is the still right number.

//PROC1 PROC                  
//STEP1 EXEC PGM=IEFBR14      
//DD1    DD  DDNAME=OTHERDD   
//PROC1 PEND                  
//*                           
//PROC2 PROC                  
//STEP1 EXEC PROC=PROC1       
//PROC2 PEND                  
//*                           
//STEP EXEC PROC=PROC1        
++PROC1 PROC                  
++STEP1 EXEC PGM=IEFBR14      
++DD1    DD  DDNAME=OTHERDD   
//OTHERDD DD  *               
some data
/*


On Wed, 2 May 2007 14:20:51 -0500, McKown, John 
<[EMAIL PROTECTED]> wrote:

>Just "for fun", I'm testing weird JCL things. A couple of things that
>I've found that are weird are:
>
>1) If you do something like:
>       //OPROC PROC
>       //IPROC PROC
>       //STEP2 EXEC PGM=IEFBR14
>       // PEND
>       // PEND
>       //XSTEP EXEC PROC=OPROC
>       //RSTEP EXEC PGM=IEFBR14
>
>You will get a JCL error. But the JCL error is on the second PEND
>statement. Nothing is said about not having a PROC defined within a PROC
>in this case. But if you then remove the one of the PEND statements, the
>error is when OPROC is expanded with a message "PROC VERB STATEMENT 
OUT
>OF SEQUENCE"? If you don't expand OPROC, then you get no error message
>at all!
>
>2) You can do this:
>       //MYPROC PROC
>       //STEP1 EXEC PGM=IEFBR14
>       //SYSIN DD *
>       XXX
>       // PEND
>       //OSTEP EXEC PROC=MYPROC
>
>The JCL error occurs in the expansion on the OSTEP step with "IEFC601I
>INVALID JCL STATEMENT". Again, if you don't try to expand MYPROC, then
>you don't get an error.
>
>Somehow, this just seems wrong to me. Of course, I don't know the
>history of the JCL converter / interpreter either.
>
>This all came up in my testing of my JCL parsing routine. Yes, I'm still
>doing it despite some rather negative comments from others about it. In
>the 0.0000000001% chance that anybody cares, I have gotten all the JCL
>so that each logical JCL statement has been composed from the physical
>statements (i.e. concatenated the information from multiple
>continuations and removed all comments). Not too bad, considering the
>amount of time that I've worked on it.
>
>--
>John McKown
>Senior Systems Programmer
>HealthMarkets
>Keeping the Promise of Affordable Coverage
>Administrative Services Group
>Information Technology

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to