Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[Charles Mills]

Barbara, Peter says "the JOB and EXEC statements are built by the START
command processor."

If we could solve your problem we could also solve mine presumably.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of ibmmain
Sent: Sunday, December 21, 2014 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: //STARTING JOB ... was: Re: JCLLIB in started proc?

>  The START command processor needs to build and "initiate" some JCL to
start what was requested. The JCL will be sent to a subsystem that is able
to process that JCL. The Master Subsystem (MSTR) and the Job Entry
Subsystems 2 (JES2) and 3 (JES3) are the ones I know. 
> The first operand of the START command is shown as "membername" in the
System Command reference. For brevity, I name it "MEMBER" hereafter.
> In order to build the JCL, the START command processor performs the
following steps: 
> 1) Search for MEMBER in the data sets allocated under IEFJOBS in the
master scheduler JCL. If found, this member *must* contain a job, i.e. it
must start with a JOB statement. 
> 1a) If it does, this JCL is used in step 4) below. Continue with step 4).
> 1b) If it does not, an error is returned and processing ends. 
> 2) Search for MEMBER in the data sets allocated under IEFPDSI in the
master scheduler JCL.
> 2a) If found and if the member contains a job, i.e. it starts with a JOB
statement, this JCL is used in step 4) below. Continue with step 4).
> 2b) If found but the member does *not* start with a JOB statement, it is
ignored. Continue with step 3).
> 3) Build a job to invoke MEMBER as JCL procedure, i.e. build a JOB
statement and an EXEC PROC=MEMBER statement. Continue with step 4).
> 4) Send the JCL found or built in steps 1) - 3) to the subsystem for
processing. The subsystem is the primary JES by default, or the one named on
SUB=, if specified. Exception: If MEMBER is the name of a subsystem
(IEFSSNxx), then the default subsystem is MSTR.
> 5) START command processing ends.
> 
> After this point, the *subsystem* has to process the JCL. If that requires
the resolution of JCL procedures or JCL INCLUDEs, the only source for this
is the "procedure library" of the subsystem. 
> - If the subsystem is the Master Subsystem, then the only "procedure
library" is the set of data sets allocated under IEFPDSI in the master
scheduler JCL. 
> - If the subsystem is one of the JESs, then the only "procedure library"
is the set of data sets allocated under the PROCnn (nn is the set assigned
to STC jobclass in JES). 

Nice summary, Peter. Do you happen to know who puts in //STARTING JOB ...
when MEMBER is only contained in the JES2 proclib concatenation and not in
MSTJCL? I have a MEMBER that starts with a JOB statement in a proclib. As
long as that proclib is in both MSTJCL and JES2 proclib concat, all is well.
As soon as I remove the proclib containing MEMBER from MSTJCL, I get a
//STARTING JOB ... in my JCL and of course a JCL error because my JCL
already contains a JOB statement. MEMBER is started task JCL and gets
started either using ASCRE or a regular START command.

I am assuming that it is JES2 that puts these extraneous two lines in. I was
unable to find any parameter that I could tweak to NOT put them in. I didn't
even find the place where this behaviour is described. Happens on both z/OS
1.13 and 2.1.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[Charles Mills]

Briefly, I would like to add a JCLLIB/INCLUDE to a proc in the PROCLIB
concatenation. I have to go with my hat in my hand to the powers that be to
edit the PROCLIB. (No approval needed for the specific changes; just to make
any change.) If I could include (SET) statements from my own PDS my life
would be easier. I cannot because of the restrictions we have discussed
here.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Tuesday, December 23, 2014 4:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

> If we could solve your problem we could also solve mine presumably. 
 
Sorry, Charles, I've lost track of what you initial problem was. Would you
like to reiterate?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[John McKown]

On Wed, Dec 24, 2014 at 6:55 AM, Charles Mills  wrote:

> Briefly, I would like to add a JCLLIB/INCLUDE to a proc in the PROCLIB
> concatenation. I have to go with my hat in my hand to the powers that be to
> edit the PROCLIB. (No approval needed for the specific changes; just to
> make
> any change.) If I could include (SET) statements from my own PDS my life
> would be easier. I cannot because of the restrictions we have discussed
> here.
>
> Charles


​I understand what you want and why. However, your real problem is not
technical but managerial. In effect, management has said "no changes
without authorization" and you _appear to me_ to be trying to figure out a
way to effectively bypass this rule. Naughty, naughty! You will find some
pseudo-coal in your stocking in the morning (Santa is doing his part to
address "climate change" by substituting black coal-like rocks for real
"evil" coal, due to pressure from environmental groups and the a threat of
an EPA lawsuit. ).​


 --
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[Walt Farrell]

On Wed, 24 Dec 2014 04:55:19 -0800, Charles Mills  wrote:

>Briefly, I would like to add a JCLLIB/INCLUDE to a proc in the PROCLIB
>concatenation. I have to go with my hat in my hand to the powers that be to
>edit the PROCLIB. (No approval needed for the specific changes; just to make
>any change.) If I could include (SET) statements from my own PDS my life
>would be easier. I cannot because of the restrictions we have discussed
>here.

Yes, your life would be easier. And your system security would suffer.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[Charles Mills]

Agreed.

Peter's question was "why?" -- not "is it a good idea?" LOL

Seriously, no one cited security as a "why" for this restriction. And in my 
particular case, no one checks the change I make to the PROC, just that I am 
making one, so in this particular case there would be no real impact on 
security. (This is NOT a production machine. No salaries, no AR, no AP, no 
Credit Cards.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Wednesday, December 24, 2014 5:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

On Wed, 24 Dec 2014 04:55:19 -0800, Charles Mills  wrote:

>Briefly, I would like to add a JCLLIB/INCLUDE to a proc in the PROCLIB 
>concatenation. I have to go with my hat in my hand to the powers that 
>be to edit the PROCLIB. (No approval needed for the specific changes; 
>just to make any change.) If I could include (SET) statements from my 
>own PDS my life would be easier. I cannot because of the restrictions 
>we have discussed here.

Yes, your life would be easier. And your system security would suffer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[Shmuel Metz (Seymour J.)]

In <20141221173446.fd8ed08264703ad3452c5...@gmx.net>, on 12/21/2014
   at 05:34 PM, ibmmain  said:

>Nice summary, Peter. Do you happen to know who puts in //STARTING JOB
>... when MEMBER is only contained in the JES2 proclib concatenation
>and not in MSTJCL?

Presumably IEEVSTAR for START, but the processing is similar for,
e.g., LOGON, MOUNT. 

>I have a MEMBER that starts with a JOB statement in a proclib. As
>long as that proclib is in both MSTJCL and JES2 proclib concat, all
>is well.

So it works when you follow the rules.

>As soon as I remove the proclib containing MEMBER from MSTJCL, I get
>a //STARTING JOB ... in my JCL and of course a JCL error because my
>JCL already contains a JOB statement.

And it doesn't work when you don't follow the rules.

>I am assuming that it is JES2 that puts these extraneous two lines
>in.

No. The lines that *you* added were extraneous; a JES2 or JES3 proclib
concatenation is supposed to contain cataloged procedures, not jobs.

>I didn't even find the place where this behaviour is described.

What do the JE2 and JES3 initialization manusls say about proclib
concatenations?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[Peter Hunkeler]

> If we could solve your problem we could also solve mine presumably.

Sorry, Charles, I've lost track of what you initial problem was. Would you like 
to reiterate?


--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: Re: //STARTING JOB ... was: Re: JCLLIB in started proc?

[Peter Hunkeler]

>Seriously, no one cited security as a "why" for this restriction.


Part of a proper system setup anc change management is to limit who can use the 
START command, possibly what he/she can START and for sure who can apply 
changes to JCL the JCL (procedure) libraries in discussion. If this JCL could 
be modified by content of personal libryries, this would undermine the above.


What hinders you to ask for the JCL (procedure) library to be added to IEFPDSI? 
Ask for it, expain your case.




--
Peter Hunkeler



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN