As a small, really small, system supporter, I think a PARMLIB driven option with a "fail by JCL error" (YES/NO) option if execution system is different than "resolving" system would permit most of the requested function (It's almost always time/date in dataset names) without introducing the feared expansion to sysplex problems that aren't likely to happen here or to many other small systems.
But, then, Shane's and other exits do this already, why should IBM bother? Most schedulers can also do the most often requested substitutions. > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris > Sent: Wednesday, April 19, 2006 8:16 PM > To: [email protected] > Subject: Re: Static Symbols in JCL > > Ed Gould writes; > > John Eells wrote: > > > -----------------------SNIP----------------------------------- > > > There have been formal requests, all of which have been rejected. > > > Feel free to submit another one, of course. > > > > Indeed there have been and like you said rejected. I am not > sure there > > was a reason for the rejection. If SHARE was doing their job they > > should have sent it back requesting a reason, IMO. > > There was a sound technical reason and it has been repeated > and discussed endlessly. IBM is saying "we can't make this > work reliably and/or predictably, so we will not open a > pandora's box for our customers by supplying a function that > could result in unexpected behavior." > > More than a few people have disagreed with the reasons given, > but on the face of it the IBM position has merit. Would it be > possible to deliver that functionality with limitations and > caveats? Sure. Would typical customers read and understand > those? Not a prayer. > > > I think a well written request with a parmlib option might get > > somewhere though. I will stand by my original guess is that > IBM does > > have a sound reason they just don't want to say. > > They have said why. Many times. There is no mystery at all > about the reasons for rejecting this request. None whatsoever. > > > It my open an > > integrity loophole (example only and a guess ONLY). Still, it would > > have been nice *IF* that was the case to say so and I do think the > > matter would be dropped. > > It would not introduce an integrity exposure in the classic > sense, but it would certainly open the possibility (near > certainty) of unpredictable behavior when symbols are > resolved on systems other than the system where the job will > actually run. It is easy to see how that could result in loss > of, or damage to customer data - and in those cases, it might > never be obvious to the customer that damage had occurred, > let alone when or how. > > Submit a job on one system and by luck of the draw and > checkpoint timing it gets converted and runs successfully. A > moment later you submit the same job and it craps out, or > worse, it runs but does something completely unexpected. > That's more like roulette and most customers would want. > > If IBM actually had delivered core functionality that had > such unreliable characteristics, you would rightly be all > over their case. Be careful of what you wish for lest you get > what you want. > > CC > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
