Discussion:
Wacko S722 abend
(too old to reply)
Jesse 1 Robinson
2017-06-13 16:45:31 UTC
Permalink
Raw Message
I'm posting this here because I was asked too. It's beyond crazy. As I indicated earlier, we are trying to reduce spool full conditions by limiting job output via ESTLNCT. Yesterday we set the limit on one system like this:

ESTLNCT NUM=20000,INT=20000,OPT=1

We changed NUM from the old value, but added OPT=1 to cancel the job with no dump. On this system only, a particular job started getting S722 for no apparent reason. It produces hardly any output at all. We looked at older executions-including yesterday before the JES change-and it appears that this job has *always* produced the output exceeded message but with no abend because of OPT=0. The output message appears in the job log even before the first step executes!

We ran the job in a different class with a different job name. Always the same message. Does this make sense to anyone?!?

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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Elardus Engelbrecht
2017-06-13 17:04:21 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
ESTLNCT NUM=20000,INT=20000,OPT=1
We changed NUM from the old value, but added OPT=1 to cancel the job with no dump.
What were the old values of NUM and INT?
Post by Jesse 1 Robinson
On this system only, a particular job started getting S722 for no apparent reason. It produces hardly any output at all. We looked at older executions-including yesterday before the JES change-and it appears that this job has *always* produced the output exceeded message but with no abend because of OPT=0. The output message appears in the job log even before the first step executes!
Check if you have any wacko JES2 exit(s)... Any limiting statements in that job itself?
Post by Jesse 1 Robinson
We ran the job in a different class with a different job name. Always the same message.
You said you changed it on one system. What happens on the other system(s)?
Post by Jesse 1 Robinson
Does this make sense to anyone?!?
No. My users will certainly jump up and down if that happens to their jobs...

Groete / Greetings
Elardus Engelbrecht

We have now an extreme cold front in South Africa, it is so extremely cold, when I tried to get money from an ATM, the bank said my account is Frozen!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-06-13 17:19:50 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
ESTLNCT NUM=20000,INT=20000,OPT=1
We changed NUM from the old value, but added OPT=1 to cancel the job with
no dump. On this system only, a particular job started getting S722 for no
apparent reason. It produces hardly any output at all. We looked at older
executions-including yesterday before the JES change-and it appears that
this job has *always* produced the output exceeded message but with no
abend because of OPT=0.
Is it possible the job is printing a bazillion lines with no paper advance,
or even just very short lines? In other words lots of lines occupying
little actual space?
Post by Jesse 1 Robinson
The output message appears in the job log even before the first step
executes!
Now *that* is bizarre (and shoots down my theory, I think).

Tony H.

----------------------------------------------------------------------
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-13 17:40:38 UTC
Permalink
Raw Message
I don't want to turn this into a debugging session. We plan to open an SR with IBM. Just to verify what I've said, here are some lines from the job log. The first step is vanilla CA11. That's where the job dies. We completely removed the CA11 step; same result. I was just looking for any 'me too' responses.

---- TUESDAY, 13 JUN 2017 ----
ICH70001I UCC7 LAST ACCESS AT 03:39:19 ON TUESDAY, JUNE 13, 2017
$HASP375 TEDD071 ESTIMATED LINES EXCEEDED
$HASP373 TEDD071 STARTED - INIT 17 - CLASS K - SYS D0
SCEUJI02I JOB TEDD071 STARTED 03.39.19 13 JUN 17
IEF403I TEDD071 - STARTED - TIME=03.39.19
IEF450I TEDD071 ***@30 RMS - ABEND=S722 U0000 REASON=00000000 841
TIME=03.39.19

.
.
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 Tony Harminc
Sent: Tuesday, June 13, 2017 10:21 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Wacko S722 abend
Post by Jesse 1 Robinson
ESTLNCT NUM=20000,INT=20000,OPT=1
We changed NUM from the old value, but added OPT=1 to cancel the job
with no dump. On this system only, a particular job started getting
S722 for no apparent reason. It produces hardly any output at all. We
looked at older executions-including yesterday before the JES
change-and it appears that this job has *always* produced the output
exceeded message but with no abend because of OPT=0.
Is it possible the job is printing a bazillion lines with no paper advance, or even just very short lines? In other words lots of lines occupying little actual space?
Post by Jesse 1 Robinson
The output message appears in the job log even before the first step
executes!
Now *that* is bizarre (and shoots down my theory, I think).

Tony H.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-06-13 17:48:20 UTC
Permalink
Raw Message
Post by Jesse 1 Robinson
I don't want to turn this into a debugging session. We plan to open an SR
with IBM. Just to verify what I've said, here are some lines from the job
log. The first step is vanilla CA11. That's where the job dies. We
completely removed the CA11 step; same result. I was just looking for any
'me too' responses.
---- TUESDAY, 13 JUN 2017 ----
ICH70001I UCC7 LAST ACCESS AT 03:39:19 ON TUESDAY, JUNE 13, 2017
$HASP375 TEDD071 ESTIMATED LINES EXCEEDED
$HASP373 TEDD071 STARTED - INIT 17 - CLASS K - SYS D0
SCEUJI02I JOB TEDD071 STARTED 03.39.19 13 JUN 17
IEF403I TEDD071 - STARTED - TIME=03.39.19
TIME=03.39.19
.
.
J.O.Skip Robinson
​Well, just to interject a likely stupid idea, can you access the job
output in SDSF? If so, I would put a question mark in front of the job to
display all the sysout entries. Then see which one has all the output lines
in it. Example:

LIH1 JOB DATA SET DISPLAY - JOB MAGI930D (JOB60835) LINE 1-6 (6)
COMMAND INPUT ===> SCROLL ===>
CSR
PREFIX=* DEST=(ALL) OWNER=* SYSNAME=*
NP DDNAME StepName ProcStep DSID Owner C Dest Rec-Cnt
Page-Cnt Byte-Cnt CC
JESMSGLG JES2 2 MDOFLI N 4
1
JESJCL JES2 3 MDOFLI N 60
4,395 1
JESYSMSG JES2 4 MDOFLI N 3
246 1
RMSRPT CA07RMS ***@2X 101 MDOFLI N 8
1 577 1
SYSPRINT JS010 PS010 103 MDOFLI N 0
1
DSSMSGDD JS010 PS010 105 MDOFLI N 0
1​
--
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Allan Staller
2017-06-13 17:51:55 UTC
Permalink
Raw Message
Any OUTLIM coded in JCL?

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Tuesday, June 13, 2017 12:49 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: Wacko S722 abend
Post by Jesse 1 Robinson
I don't want to turn this into a debugging session. We plan to open an
SR with IBM. Just to verify what I've said, here are some lines from
the job log. The first step is vanilla CA11. That's where the job
dies. We completely removed the CA11 step; same result. I was just
looking for any 'me too' responses.
---- TUESDAY, 13 JUN 2017 ----
ICH70001I UCC7 LAST ACCESS AT 03:39:19 ON TUESDAY, JUNE 13, 2017
$HASP375 TEDD071 ESTIMATED LINES EXCEEDED
$HASP373 TEDD071 STARTED - INIT 17 - CLASS K - SYS D0
SCEUJI02I JOB TEDD071 STARTED 03.39.19 13 JUN 17
- ABEND=S722 U0000 REASON=00000000 841
TIME=03.39.19
.
.
J.O.Skip Robinson
​Well, just to interject a likely stupid idea, can you access the job output in SDSF? If so, I would put a question mark in front of the job to display all the sysout entries. Then see which one has all the output lines in it. Example:

LIH1 JOB DATA SET DISPLAY - JOB MAGI930D (JOB60835) LINE 1-6 (6)
COMMAND INPUT ===> SCROLL ===>
CSR
PREFIX=* DEST=(ALL) OWNER=* SYSNAME=*
NP DDNAME StepName ProcStep DSID Owner C Dest Rec-Cnt
Page-Cnt Byte-Cnt CC
JESMSGLG JES2 2 MDOFLI N 4
1
JESJCL JES2 3 MDOFLI N 60
4,395 1
JESYSMSG JES2 4 MDOFLI N 3
246 1
RMSRPT CA07RMS ***@2X 101 MDOFLI N 8
1 577 1
SYSPRINT JS010 PS010 103 MDOFLI N 0
1
DSSMSGDD JS010 PS010 105 MDOFLI N 0
1​


--
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

----------------------------------------------------------------------
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
Peter Hunkeler
2017-06-13 18:42:04 UTC
Permalink
Raw Message
Can you post the JCL?


--
Peter Hunkeler






----------------------------------------------------------------------
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-13 19:15:55 UTC
Permalink
Raw Message
Problem solved thanks to a colleague who put the right keywords on a Google search and found a past IBM-MAIN thread that provided the answer. This from the job card:

JOB (TE000MEJIC,DK6D,,0),...

In all my years I never learned about the 'other positional sub-parameters' of the accounting field. As spelled out in the JCL doc, the fourth sub-parameter means 'lines':

(pano,room,time,lines,cards,forms,copies,log,linect)

This job (as well as well a few others we discovered) were created by the same guy many years ago. Do not know what prompted him to add other sub-parameters, but that was the cause. As long as OPT=0 was in effect at the system level, we got the mysterious warning but no failure. When we set OPT=1, kaboom.

Thanks to all who chimed in.

.

.
.
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 Peter Hunkeler
Sent: Tuesday, June 13, 2017 11:43 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):AW: Re: Wacko S722 abend

Can you post the JCL?


--
Peter Hunkeler


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Hunkeler
2017-06-13 19:39:24 UTC
Permalink
Raw Message
This from the job card:>>JOB (TE000MEJIC,DK6D,,0),...
Exactly the reason I asked to see the JCL. I was just too lazy to lookup the format of the accounting parameter, and thought I would recognize once I see it.
Glad you found it.

I always found it somewhat strange design that JES is trying to interpret the accounting field, and silently jumps over stuff that does not fit.

--Peter Hunkeler





----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Edward Gould
2017-06-13 23:52:52 UTC
Permalink
Raw Message
One reason people will code 0 linecount/cardcount in the jobcard is that it can affect the jes input queue priority. On systems where queuing is frequent this is one way to get your job bumped to the top or at least higher on the food chain.
Ken:

Bingo we have a winner… A long time ago memory popped up with this. The programmers found out about it and started using it. We started getting calls about test turn around. After a bit of digging we figured out the issue.
We got busy and wrote some minor JES2 code to disregard the number of lines when it came time to figure out priority.

Complaints dropped dramatically when we implemented it.

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