In a message dated 3/29/2007 3:45:39 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: >Some jobs are real problems. Which is, or was long ago, a very good reason to define and rigorously enforce job classes. I worked on a massive local mod to JES2 in 1977 that determined many resources needed by a job, such as max number of tape drives in any step, max number of mountable DASD volumes (yes, there were still mountable DASDs in 1977) in any step, max region size, total CPU time, phase of the moon, etc. These metrics were then used in a table lookup to create a job class value which was forced onto the job. Any job that would not fit into any known class was handled as a special case by operations, or maybe failed (can't remember now). The initiator job class assignments were set up so that there would never be an allocation hang caused by some job that wanted more tape drives than existed, e.g. It was a kluge, much of it is now obsolete, but it was sure fun coding/debugging that sucker. Bill Fairchild Plainfield, IL
************************************** See what's free at http://www.aol.com. ---------------------------------------------------------------------- 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
