Discussion:
Does the JES2 ESTBYTE parm limit STC or just batch output?
Add Reply
George Henke
2017-06-08 20:57:37 UTC
Reply
Permalink
Raw Message
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2017-06-08 23:08:26 UTC
Reply
Permalink
Raw Message
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-----
Behalf Of George Henke
Sent: Thursday, June 08, 2017 1:59 PM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-06-09 04:02:57 UTC
Reply
Permalink
Raw Message
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Thursday, June 08, 2017 4:09 PM
To: IBM-***@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-----
On Behalf Of George Henke
Sent: Thursday, June 08, 2017 1:59 PM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Allan Staller
2017-06-09 13:36:12 UTC
Reply
Permalink
Raw Message
Aside from the ESTBYTE change, ensure the applicable JES2 JOBCLASS definitions specifications do not specify TIME=1440.
If TIME=1440 is specified at any point, I believe the whole thing will fail.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, June 8, 2017 11:04 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Does the JES2 ESTBYTE parm limit STC or just batch output?

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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Thursday, June 08, 2017 4:09 PM
To: IBM-***@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-----
On Behalf Of George Henke
Sent: Thursday, June 08, 2017 1:59 PM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
George Henke
2017-06-09 18:15:29 UTC
Reply
Permalink
Raw Message
Yes, Jesse, it was exactly this excerpt you quote which inspired my post.

It is very vague wrt ESTBYTE, whether it applies just to batch and APPC or
also STCs.

Are the internal JES2 limits it cites set just for TSO XMITs or do they
apply also to STCs in lieu of the ESTBYTE parm.

If so, it would be nice to have an option like the OPT=0,1,2 ESTBYTE
subparm when the limit is triggered than to have to install the JES2 EXIT
20 just to cancel the task.

Just wondering if anyone has been able to get ESTBYTE working for STCs and
not just batch, APPC, and would not want to fill the spool and hang the MAS
just to find out.
Post by Jesse 1 Robinson
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
"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
-----Original Message-----
Behalf Of Lizette Koehler
Sent: Thursday, June 08, 2017 4:09 PM
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-----
On Behalf Of George Henke
Sent: Thursday, June 08, 2017 1:59 PM
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,
--
George Henke
(C) 845 401 5614

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-06-09 20:25:47 UTC
Reply
Permalink
Raw Message
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.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of George Henke
Sent: Friday, June 09, 2017 11:16 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Does the JES2 ESTBYTE parm limit STC or just batch output?

Yes, Jesse, it was exactly this excerpt you quote which inspired my post.

It is very vague wrt ESTBYTE, whether it applies just to batch and APPC or also STCs.

Are the internal JES2 limits it cites set just for TSO XMITs or do they apply also to STCs in lieu of the ESTBYTE parm.

If so, it would be nice to have an option like the OPT=0,1,2 ESTBYTE subparm when the limit is triggered than to have to install the JES2 EXIT
20 just to cancel the task.

Just wondering if anyone has been able to get ESTBYTE working for STCs and not just batch, APPC, and would not want to fill the spool and hang the MAS just to find out.
Post by Jesse 1 Robinson
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
"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
-----Original Message-----
On Behalf Of Lizette Koehler
Sent: Thursday, June 08, 2017 4:09 PM
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
Sent: Thursday, June 08, 2017 1:59 PM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Brennan
2017-06-10 19:32:25 UTC
Reply
Permalink
Raw Message
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.

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.
Post by Jesse 1 Robinson
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
George Henke
2017-06-10 21:25:50 UTC
Reply
Permalink
Raw Message
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.
Post by Tom Brennan
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
Post by Tom Brennan
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.
Post by Tom Brennan
Post by Jesse 1 Robinson
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.
Post by Tom Brennan
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
George Henke
(C) 845 401 5614

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-06-10 01:12:31 UTC
Reply
Permalink
Raw Message
I reran the job I used earlier, this time with TIME=NOLIMIT. Still got S722. This is with system wide ESTLINE parm, not a jobclass value.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Allan Staller
Sent: Friday, June 09, 2017 6:37 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Does the JES2 ESTBYTE parm limit STC or just batch output?

Aside from the ESTBYTE change, ensure the applicable JES2 JOBCLASS definitions specifications do not specify TIME=1440.
If TIME=1440 is specified at any point, I believe the whole thing will fail.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, June 8, 2017 11:04 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Does the JES2 ESTBYTE parm limit STC or just batch output?

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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Thursday, June 08, 2017 4:09 PM
To: IBM-***@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-----
On Behalf Of George Henke
Sent: Thursday, June 08, 2017 1:59 PM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Allan Staller
2017-06-12 12:52:36 UTC
Reply
Permalink
Raw Message
Cool. I learned something today. Maybe JOBCLASS(xxx) is a better place that ESTBYTE?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Friday, June 9, 2017 8:13 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Does the JES2 ESTBYTE parm limit STC or just batch output?

I reran the job I used earlier, this time with TIME=NOLIMIT. Still got S722. This is with system wide ESTLINE parm, not a jobclass value.

.
.
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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Allan Staller
Sent: Friday, June 09, 2017 6:37 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Does the JES2 ESTBYTE parm limit STC or just batch output?

Aside from the ESTBYTE change, ensure the applicable JES2 JOBCLASS definitions specifications do not specify TIME=1440.
If TIME=1440 is specified at any point, I believe the whole thing will fail.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, June 8, 2017 11:04 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Does the JES2 ESTBYTE parm limit STC or just batch output?

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
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
Sent: Thursday, June 08, 2017 4:09 PM
To: IBM-***@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-----
On Behalf Of George Henke
Sent: Thursday, June 08, 2017 1:59 PM
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...