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
