MVSFORUMS.com

[Hanul]

Hi,

I have 2 stupid questions
I think the answer is simple, but I can't find it out...

1. I'm using an INCLUDE in my JCL and it works (it includes allright hehe), but in the included part every '//' in the beginning of a line is replaced by 'XX' resulting in a JCL error on every line (I'm using TYPRUN=SCAN to check). Lines without '//' in the beginning are included OK and don't generate JCL errors... Any idea what is causing this and what the solution might be??

2. Is there a JCL statement that I can use in a member which enables me to start a JCL that is in another member??

Thanks!!

Greetings!

[Cogito-Ergo-Sum]

Hanul,
I do not know about the first.

For the second question, do you want to submit a JCL from within another JCL? If yes, you can try the following:

[Hanul]

Thanks, Cogito-Ergo-Sum
Meanwhile I found the answer to my second stupid question myself, I used SYSOUT=(X,INTRDR).

Now only the first stupid question remains

Hanul

[Bill Dennis]

The XX in the included JCL is just the system's method of showing that the statements were copied from somewhere else. That alone is not causing your JCL error. There must be something else. Please post the actual listing, if possible.

Bill

[Hanul]

Here's (part of) my job report. The included part didn't cause an error when I used to run it as a stand-alone job. But now that it's part of the include, it starts giving those errors...

[Dibakar]

Hanul,

JCL manual says Include statement cannot have DD * statements.

Question: Can someone explain why not?

Diba.

[Hanul]

Right, now I noticed...

But you're right, why not??

Hanul

[slade]

Hi Hanul,

I'd guess that INCLUDEs are considered similar to PROCs where in-stream data is not allowed.

You could probably use DD DDNAME=anyname instead of DD *, then code in the jobstream after the INCLUDE:

//anyname DD *
instream data
.
.
.

But you'd have to take the sysin data out of the include.

Regards, Jack.

[Dibakar]

Slade,

Still the question remains why procs and includes would have this restriction.

Maybe it would be bad practice to have in-stream data in procs but otherwise I don't see any reason.

Diba.

[CaptBill]

Dibakar,

When you play any game, you have to follow the rules for that game. If you do not follow the rules, you get thrown out of the game.

When you use JCL, you have to follow the rules for JCL. Someone at sometime made the rule that there is no instream data allowed in a PROC. You may disagree with the rule, but it is still the rule and you have to follow it or you will be in violation and not get to run your job.

[Bill Dennis]

The whole purpose of the SYSIN file is to provide input to the program that is changeable. Therefore, it would seem silly to have it be part of an included member or proc where everyone gets the same values.

Put the data into a PDS (maybe with a symbolic member name) or put it in your JOB stream as suggested by slade.

Bill

[slade]

Hi Dibakar,

It probably all boils down to the fact that things are done in a given sequence. In this case I'd imagine the JCL being read and when the in-stream data is detected it id put into a special dataset for later use by the appplication. The pros and includes are then expanded and placed into the JCJ, the symbolics are resolved, yada yada yada.

When PROCs and INCLUDEs were first introduced to the industry, the process was probably reviewed and someone at IBM said, "What happens if someone puts in-stream data into a PROC/INCLUDE ?" The answer was "tell them they can't do that, we'd have to turn the process upside down to accommodate it".

Regards, Jack.

[Dibakar]

Thanks everybody,

I often get these questions because manuals often talk about rules but not why they were made.

Regards,
Diba.