PMJI, I think the problem is the way in which the START command is processed. In the MSTJCL, there an STCINRDR DD. The START command (in the CONSOLE address space?) creates a "job" which it "submits" to JES by doing a "put" to this DD. The code in the START command processor does not READ the JCL for the started task. JES does that using its normal JCL processing. Which means the JCL may or may not code from SYS1.PROCLIB. It can come from other PDSes. About which the START command processor knows absolutely __nothing__. Now, the START command processor has the DD sub-parameters "hard coded" in it, I would guess. So what it does when it sees one is generate the DD statement:
//IEFPROC.IEFRDER DD ..dd parms from the START command .. The START command also knows about some of the JOB keywords as well. For example, try S BUBBA,CLASS=A and you'll get: IEE401I START BUBBA , JOB STATEMENT KEYWORD CLASS IGNORED So it's not just DD parameters which are invalid in a START command. If the START command processor does not recognize the parameter, it __assumes__ it is to be passed to the STC on the EXEC for an STC or via // SET commands for a started JOB. This leads me to believe that it would be impossible for IBM to modify the START command processor so that it would not generate the //IEFPROC.IEFRDER DD when it sees a possible DD subparameter. There is simply no way for it to know if the parameter is used in the JCL or not. Now for a started JOB, one could argue that the START command processor should only use // SET parm=value generated cards. The thing is that the START command processor __does__ know the PDSes from which the started job's JCL is read because it read the JCL itself from the //IEFJOBS DD in the MSTRJCL. This is totally unlike a started TASK, whose JCL is read from the JES defined PROCLIB. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason > Sent: Monday, January 24, 2011 1:56 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Cataloged procedure misunderstanding > > Charles > > I'm trying here to keep up with something in which I only > dabbled some years > ago now. > > I was going to say the "curtailed post" to Paul until I > realised this is what you > meant in it's essence by > > > "declare a variable" inside your PROC > > Since this didn't jump out at me - not necessarily the > brightest knife in the > drawer! - straight away and there may be other "dullards", I > may as well use it > anyway, it having been typed already! > > <curtailed post> > > Shouldn't the "trick" which processing of the START command > needs to learn > be the appearance of the potentially clashing token as a > variable - introduced > with an "&" - in the body of the procedure? That could then elevate > the "explicit" use over the "implicit" use within the "scope" > of the procedure. > > </curtailed post> > > All we need now is a "requirement"! > > Chris Mason > > On Mon, 24 Jan 2011 09:35:29 -0800, Charles Mills <charl...@mcn.org> > wrote: > > >Gil's right. It's a scoping issue. Once you "declare a > variable" inside your > >PROC it should be yours forever no matter what else happens > outside of that > >scope. > > > >In sympathy to IBM, this stuff was set in stone back in > about 1964 when (a.) > >scoping was not so well-established a principle as it is > now; (b.) we were > >doing it all in assembler; and (c.) it had to be done in 44K. > > > >As Gil points out, IBM could now give us a warning. Or even > implement the > >scoping we describe. It would not break any existing PROCs > (hopefully -- > >well it WOULD break any that were depending on a declared > symbol being > >ineffective) to say "if you declare a symbol it's yours, no > matter what > >happens now or in the future in JCL." > > > >Charles > > > >-----Original Message----- > >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf > >Of Paul Gilmartin > >Sent: Monday, January 24, 2011 6:15 AM > >To: IBM-MAIN@bama.ua.edu > >Subject: Re: Cataloged procedure misunderstanding > > > >On Sun, 23 Jan 2011 19:05:32 -0600, Chris Mason wrote: > >> > >>> Poor design IMHO. > >> > >+1 > > > >>In other words - in principle - I agree. There is an excuse > in that the > >poor > >>developers have had constantly to try to deal with the fact > that there is a > >>continuum of JCL including procedure override capabilities > and started task > >>tricks which didn't have 40 years plus of thinking through > when the green > >>shoots appeared in the mid-60s. > >> > >Regardless, the explicit appearance of MODE on the PROC statement > >should override its implicit declaration as a posslble subparameter > >of a possible parameter of a putative DD statement. The excuse is > >insufficient. > > > >>> If you have a PROC with &FOO in it and IBM decides to add > FOO= to the > DD > >>statement then your PROC will break. There is no "safe" > PROC variable > >symbol. > >> > >>You are right that each JCL symbol you invent for your > procedure is a > >hostage > >>to fortune. I expect the only reliable way to deal with the > problem is to > >run > >>each locally-created procedure in a test environment for > each release > >change. > >>Also in principle, I would expect IBM-supplied procedures > to be kept free > >of > >>any clashes but I reserve the right not to have to put any > money on it! > >> > >At the very least, IBM should assist the customer by reporting a > >JCL error for the conflicting (ineffective explicit and effective > >implicit) declarations of MODE. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
