> 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
