Mark Zelden wrote: > Seems like a good idea. Has a requirement ever been submitted? > If not, someone should.
Yes. Many times. The issue was dealt with (that is, dispensed with) in the GUIDE "JES Job Scheduling and Control" Task Force report. Unfortunately, that was a long time ago, and memories are old and lost and involved faces and personalities are now greatly changed. Only Ed Gould remains. But the issue remains and (just like the classic question of why the data set [name] ENQ cannot include the VOLSER) keeps getting raised here from time to time. in response to what Walt Farrell wrote: > It seems like it would be a reasonable enhancement. Like most > enhancements, it would help to have customers request it of the > JESes. in response to what Edward Jaffe wrote: >Doesn't it seem that JES should natively perform this checking > -- without the use of a user exit? in response to what Robert S. Hansel wrote: > ... a sample JES Exit 6 in Appendix G for controlling the use > of JES input class. It uses profiles in the FACILITY class of > the format JOBCLASS.x, where 'x' is the class designator. Well, no. A bad idea is a bad idea. The worst are the ones that seem, without much thinking and critical analysis, to be a good idea. Historically, this is how we got a lot of poorly thought- out things in MVS out of IBM. (Well, it seemed like a good idea or requirement. Oh, well. You have it now. Deal with it. Submit another requirement. Making a list of your favorite examples is an exercise I leave for the reader.) And so we open this can of worms again. As before, binding time and scope are the questions. When (i.e., where) and under which circumstances would folks want the authorization to occur? At JOB conversion time (this is what is now implied by "Exit 6")? Before (so you get any errors early, before the job is sent to some other member)? At interpretation time (which is different for JES2 and JES3), so that, for JES2 the check is done on the system where the job will execute? What about operator commands that change the JOB's CLASS? Would that be checked? Where? On which system? The system where the command was entered? The ESM rules that control this MIGHT be different on different JES2 members or JES3 LOCALs. What about SDSF (or IOF) commands and actions? Check on the system where the TSO user is executing? A final check before the JOB actually begins execution? What would happen if it failed then? Would the system need to keep a history of JOB CLASS changes and unwind the commands' effects back to the point where the JOB's CLASS was valid (on some eligible member)? The JOB's CLASS might have been (validly) changed by an operator at 10:30 PM, but when some INIT on some potentially reconfigured MVS image finally selected the JOB for execution at 3:45 AM, on another shift, it's a no-go, and the operators on that shift are now confused. The operational problem with doing this is that you can create a set of ESM profiles/permits/rules that would allow a succession of CLASS= specifications on the original JOB card and subsequent user/operator commands that, at that time, would be pronounced acceptable, but in the end (at least if done in a manner that would please the most a-r security administrators and auditors) would fail the JOB as ineligible for execution in that CLASS on the member (system) which had the unfortunate experience to have an INIT that ended up selecting it for execution, to the surprise, no doubt, of the original submitter. There are far too many variables (meaning ways that customers, in their infinite, creative, "this is obviously the correct way" wisdom "know" to be right) for any simple-minded implementation to satisfy even a significant plurality of shops. Almost any way that IBM would do this would be sure to irritate more customers (that wanted to use it) than it would please. An attempt to fit almost any general solution would require a set of additional, associated options or parameters to specify the answers to the questions I asked just above. And I've probably left out another dozen or so that I forgot about from previous discussions on the subject. The noble effort to deliver "something useful" would have turned something seemingly simple into something complex. This is one of the most perfect examples, IMHO, of a function that SHOULD NOT be implemented by IBM as a native JES / ESM facility, but left to the creative thinking and goal-specific inventiveness of each individual installation. The question of binding time is one that is difficult to pin down here. There are many simultaneously correct and incorrect answers. Before anybody responds with "well, just do it _this_ way or do it _here_ [at this point in the MVS / JES code] and that would be perfect" think first about the situation outside of you own little (or big) boxes and discover how your solution might not meet the needs or requirements of some other shop. I know you think your way would please a majority of shops. While it might please nearly all of the bright folks who do pay attention to this list (other than Ed Gould, who is hard to please) I bet it would not actually work out well for the vast silent majority. The last point is that the idea that IBM might do something like this just leads to _this_ sort of thinking (courtesy of C.P. Vernooy): > Well, if we do this, let's do it good and ask Jes2 to check > on all its 'resources', like Sysoutclass, RJE station, > Execution NJE node, printing Node, Building, Name, Estmated > Lines, Estimates time, Sysaff and the dozens other parameters > a user can request and we would like to restrict and have > written exits for. I trust you can see where _that_ sort of thing would lead. I assume, C.P. Vernooy, that you had your tongue planted firmly in cheek when you wrote that. -- WB ---------------------------------------------------------------------- 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
