We have experienced a number of spool-full conditions in the recent past, always caused by runaway batch jobs that produce tens of millions of lines of garbage until the entire MAS grinds to a halt. So we're experimenting with JES2-defined limits. In researching the options, we came across the doc below. We're focused on batch, but this passage may be telling. If only we could understand it. May you be granted more insight that us.
"Considerations for started tasks and TSO LOGONs "Output limits for TSO/E transmits can be set by TSO/E using the TSO/E OUTLIM= parameter. JES2 also sets a limit internally. When SYSOUT is transmitted in the foreground for started tasks and TSO/E LOGONs, the member uses the lower of these two limits. JES2 sets the following output limits for started tasks and TSO LOGONs: "999,999 for lines, cards, and pages 2,147,483 (in 1000s of bytes) for spool utilization. An installation can change the limits for started tasks or TSO LOGONs by using JES2 Exit 20 to change the limit for each particular started task or TSO LOGONs The limit for TSO/E transmits which are specified thorough the OUTLIM parameter, should not be greater than the limit JES2 sets for punches or a X'722' abend will occur. See z/OS TSO/E Customization for information about limiting the TSO/E TRANSMIT command." . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, June 08, 2017 4:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Does the JES2 ESTBYTE parm limit STC or just batch output? The EST Byte, Line, Page can be dynamically changed. The simplest way to avoid an IPL (and JES2 just stops when spool is full - but will respond to commands like PURGE) Is to cycle the STC, add another spool volume, or see what is really going on. If the STC is filling up spool, it needs to be determined why. We have automated the HASP050 / HASP375 message to send emails and alerts when some of the JES2 functions are impacted (BERT, SPOOL, JNUM, etc.) My understanding is the IEFUSO exit can cancel an STC if it exceeds its limits. You can code the STCCLASS statement in JES2 and allow the IEFUSO to do its job. You can also use automation tools to monitor for HASP375, HASP050 or other You can use products like z/OSEM or EASYEXIT (DTS Software) to control your jobs names (STC, TSU, or JOB) for determining final action. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of George Henke > Sent: Thursday, June 08, 2017 1:59 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Does the JES2 ESTBYTE parm limit STC or just batch output? > > Just averted a near disaster, a mid-day IPL of 4 LPARs, with a STC > filling up the spool with 10B bytes of data because the ESTBYTE limit > was not turned on for termination, OPT=1. > > But would it have done anything anyway for a STC or does it just apply > to batch and APPC. > > The manual is silently ambiguous on this. > > If anyone has had success limiting STC output so, please let me know, > else it will probably be JES2 Exit 20. > > -- > 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
