Thank you all. Jesse answered the question.
It looks like STCs are agnostic to ESTBYTE. Regardless of the line count, if a STC takes 25% of the spool, it needs to be cancelled, either by Exit 20, Netview, or as a last resort the operator. Oh well, back to the drawing board, Exit 20, and Netview. On Sat, Jun 10, 2017 at 4:00 PM, Edward Gould <edgould1...@comcast.net> wrote: > > On Jun 10, 2017, at 2:33 PM, Tom Brennan <t...@tombrennansoftware.com> > wrote: > > > > I should probably relay my old story about estimated line counts: Back > around 1984 a spool shortage occurred that slowed or stopped all processing > enough that the manager response was "Put in some limits". So someone > implemented a JES2 exit that 722'd when the estimated line count was > exceeded. Managers were happy I guess. > > Indeed we had field in the accounting field that specified the max number > of lines (25K was the max). > We were somewhat lucky as a full spool almost never happened (in the > 80’s). We liked to think that was way. But it did work. > > Ed > > > > The result, however, was that virtually all of the 722's were folks who > simply needed to increase their estimated line count, often after a > complaining phone call to my desk. So basically all the exit did was cause > reruns and additional CPU usage - very expensive in those days. I ended up > removing the exit and concentrated on actions to handle spool problems on > the back-end (notification and automation, including spool offload if > necessary). Those back-end methods have their own issues, but at least the > complaning calls stopped. > > > > Jesse 1 Robinson wrote: > >> In light of our spool problems, we have undertaken to set a limit. > Trying to make everyone put output limits in their jobs would be out of the > question. So we dug into TFM and found system wide ESTLNCT. There are > related parms for byte count and page count, but we went with lines for > simplicity. It's a 'basic' parm not associated with job class. We set > ESTLNCT to a value that we calculated would represent around 20% of the > spool. Fortunately we have a sandbox system where we can play with this > sort of thing. Good news for us: a large output job gets S722 when our > experimental limit is exceeded. Bad news for OP: I set up a started task to > do the same thing; it ran to completion regardless of output count. So it > appears that STCs are not subject to the ESTLNCT value. I’m 99% sure that > the TSO OUTLIM value specified in IKJTSOxx affects only TSO; in fact, only > the TSO TRANSMIT command, not TSO output in general. Before discovering > ESTLNCT, we set out to get automation (SA) to analyze the 'output exceeded' > message and cancel a job when it reaches 20% of the spool; that value is > included in the message. I imagine that the same strategy could be used to > limit STCs, but it would require more work. It just occurred to me that if > you're concerned about a specific STC, you might try putting a JOB card on > it. I have not tried that. > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
