Re: Strangeness in PROC-land
- From: JackOfAllTrades@xxxxxxxxxxxx (Kenneth E Tomiak)
- Date: 3 May 2007 15:53:27 -0700
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
<John.Mckown@xxxxxxxxxxxxxxxxx> wrote:
Just "for fun", I'm testing weird JCL things. A couple of things thatOUT
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
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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Prev by Date: Re: How difficult would it be for a SYSPROG ? (was RE: Mainframe Data Center Permanant Shutdown Procedure Needed)
- Next by Date: Re: Systems Programmer job posting
- Previous by thread: Strangeness in PROC-land
- Next by thread: JCL to copy all versions from a GDG base to another GDG base
- Index(es):
Relevant Pages
|
