S222 abends and Reason Codes
Lizette Koehler
They are researching an internal S222 abend. It came with a reason code.
Now, I have seen S222 due to OPER Cancel commands, but I am not familiar with S222 abends that are issued internally and with a reason code.
Would I be correct in assuming that I need the person that wrote that code to tell me why they did an internal S222 abend and what their reason code means? This is not something I would think would be an IBM process.
Lizette
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Lizette Koehler
> Sent: Thursday, July 02, 2009 10:54 AM
> To: IBM-...@bama.ua.edu
> Subject: S222 abends and Reason Codes
>
> Someone asked this and I did not know where to look.
>
> They are researching an internal S222 abend. It came with a
> reason code.
>
> Now, I have seen S222 due to OPER Cancel commands, but I am
> not familiar with S222 abends that are issued internally and
> with a reason code.
>
> Would I be correct in assuming that I need the person that
> wrote that code to tell me why they did an internal S222
> abend and what their reason code means? This is not
> something I would think would be an IBM process.
>
> Lizette
You are correct. It is possible for user code to issue an S222 abend internally. Perhaps via an "F jobname,ABEND" or some such thing. You need the code and hope that it is documented.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Mark Zelden
wrote:
>> -----Original Message-----
>> From: IBM Mainframe Discussion List
>> [mailto:IBM-...@bama.ua.edu] On Behalf Of Lizette Koehler
>> Sent: Thursday, July 02, 2009 10:54 AM
>> To: IBM-...@bama.ua.edu
>> Subject: S222 abends and Reason Codes
>>
>> Someone asked this and I did not know where to look.
>>
>> They are researching an internal S222 abend. It came with a
>> reason code.
>>
>> Now, I have seen S222 due to OPER Cancel commands, but I am
>> not familiar with S222 abends that are issued internally and
>> with a reason code.
>>
>> Would I be correct in assuming that I need the person that
>> wrote that code to tell me why they did an internal S222
>> abend and what their reason code means? This is not
>> something I would think would be an IBM process.
>>
>> Lizette
>
>You are correct. It is possible for user code to issue an S222 abend
internally. Perhaps via an "F jobname,ABEND" or some such thing. You need
the code and hope that it is documented.
>
>--
>John McKown
>Systems Engineer IV
>IT
>
I have also seen user 222 abends (poor choice of a number IMHO).
I see these in the syslog from time to time (from AFOPER I think). They
also show up in the syslog starting in column 1 without the standard
routecode, sysid, date/time prefixes:
!OMG4042 ABEND U222 OCCURRED, TEXT=MATCH CANCELLED
!OMG4043 DUMP SUBSYS=O340 0340 MODULE=AOTSKVEC(AOTSKMGR)+X/000650/ CODE=U222
!OMG4026 A SVC DUMP WAS SUPPRESSED (ABEND TABLE/USER ABEND)
!OMG4044 ------------- ABEND ANALYSIS ----------------
!OMG4044 SUBSYS = O340 0340 MODULE = AOTSKVEC
!OMG4044 DATE = 2009.183 TIME = 0.41.12
!OMG4044 ABEND U222 AT AOTSKVEC (AOTSKMGR) + X/000650/
!OMG4044 FAILING INSTRUCTION WAS 0A0D
!OMG4044 PSW = 078C1000 80055712 ILC = 2 IC =0D
!OMG4044 ASID = 0022 (HOME) 0022 (PRIM) 0022 (SCND)
!OMG4044 R0 = 0000000C 000000DE 00155038 171CF000
!OMG4044 R4 = 00000007 0000001C 00155038 00000000
!OMG4044 R8 = 0007B048 19B8905C 000560C0 000233E0
!OMG4044 R12 = 000550C0 000089C0 0006E9D0 00000000
!OMG4044 AR0 = 00000000 00000000 00000000 00000000
!OMG4044 AR4 = 00000000 00000000 00000000 00000000
!OMG4044 AR8 = 00000000 00000000 00000000 00000000
!OMG4044 AR12 = 00000000 00000000 00000000 00000002
!OMG4044 ---------------------------------------------
!OMG4053 RECOVERY IN PROGRESS
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Roach, Dennis , N-GHG
application the check the vender documentation and then call the vendor.
If it is an in-house application, turn it over to the application
programming team.
Dennis Roach
GHG Corporation
Lockheed Martin Mission Services
Facilities Design and Operations Contract
NASA/JSC
Address:
2100 Space Park Drive
LM-15-4BH
Houston, Texas 77058
Mail:
P.O. Box 58487
Mail Code H4C
Houston, Texas 77258
Phone:
Voice: (281)336-5027
Cell: (713)591-1059
Fax: (281)336-5410
E-Mail: Dennis...@LMCo.COM
All opinions expressed by me are mine and may not agree with my employer
or any person, company, or thing, living or dead, on or near this or any
other planet, moon, asteroid, or other spatial object, natural or
manufactured, since the beginning of time.
Mark Zelden
<dennis...@LMCO.COM> wrote:
>This is not an S222, it is a U222. Major difference.
<snip>
Of course I knew that. I've worked on this platform for a little
while. :-) Read what I wrote again:
> "I have also seen user 222 abends (poor choice of a number IMHO)."
>(display of that abend followed)
Regards,
Mark
Elardus Engelbrecht
>They are researching an internal S222 abend. It came with a reason code.
>Now, I have seen S222 due to OPER Cancel commands, but I am not familiar
with S222 abends that are issued internally and with a reason code.
>Would I be correct in assuming that I need the person that wrote that code
to tell me why they did an internal S222 abend and what their reason code
means? This is not something I would think would be an IBM process.
Ask them if their Assembler source code contains this ABEND macro coded
more or less like this example:
ABEND 222,REASON=<reason code>,,,<either USER or SYSTEM>
HTH!
Groete / Greetings
Elardus Engelbrecht
Skip Robinson
'legitimate') to code an S222 on an abend macro in any program. Just
because an application takes a deliberate dive, that doesn't make the abend
'user'. The code gets reported according to how the macro is coded, not on
circumstances surrounding the crash. Likewise a reason code may be coded as
well. Or not.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
JO.Skip....@sce.com
Elardus
Engelbrecht
<elardus.engelbre To
c...@SITA.CO.ZA> IBM-...@bama.ua.edu
Sent by: IBM cc
Mainframe
Discussion List Subject
<IBM-...@bama.ua Re: S222 abends and Reason Codes
.edu>
07/02/2009 10:49
AM
Please respond to
IBM Mainframe
Discussion List
<IBM-...@bama.ua
.edu>
Tom Marchant
>
>Ask them if their Assembler source code contains this ABEND macro coded
>more or less like this example:
>
>ABEND 222,REASON=<reason code>,,,<either USER or SYSTEM>
For an S222, that would be
ABEND X'222',REASON=<reason code>,,,SYSTEM
or
ABEND 546,REASON=<reason code>,,,SYSTEM
--
Tom Marchant
Nomen Nescio
completion code specified. It's confusing, as demonstrated here.
FYI and in response to this post, causing an S222 is not the same as issuing
one.
Peter Relson
to issue an IBM-documented system abend code.
And that certainly includes 222 which has many ramifications that go with
its being a "cancel'.
As we all know, the "official" S222 has no reason codes.
Peter Relson
z/OS Core Technology Design
Len Rugen
got what I asked for....
Rick Fochtman
I can think of no case where it is accepted or supported for non-IBM
code to issue an IBM-documented system abend code.
And that certainly includes 222 which has many ramifications that go
with its being a "cancel'.
As we all know, the "official" S222 has no reason codes.
----------------------------------<unsnip>--------------------------------
I can certainly agree with these statements.
The use of System ABEND codes by applications is something to be
discouraged, in the interest of keeping these codes UNAMBIGUOUS. If an
application has a problem, let it issue a message, with a unique message
number, so that automation can pick it up and take appropriate action.
Rick
Ed Gould
> I can think of no case where it is
> accepted or supported for non-IBM code
> to issue an IBM-documented system abend code.
>
> And that certainly includes 222 which has many
> ramifications that go with
> its being a "cancel'.
>
> As we all know, the "official" S222 has no reason codes.
>
> z/OS Core Technology Design
Peter,
ALONG time ago and far far away (when MVS first came out) an applications type figured out how to turn a u0222 into a s0222. The dump arrived on my desk it was a hectic morning and I had dumps on my desk at least 4 feet deep (in those days dumps were printed on paper). I had been shooting this rather nasty system bug and it was wearing thin. Finally around 11:30 AM I got around to the dump and IIRC it took me all of 1 minute to figure out it was a user abend. I was really miffed at getting the dump I took the dump up to the VP of the programming department and put it down on the secretaries desk with a note saying it was a user problem and for the user to figure out what the problems was.
The user came down incensed saying it was a system abend so it wasn't his problem. I was about to throw him and the dump out of the front door but stopped and said "OK follow me on this dump" and I showed him step by step where it came from his program. I asked him to get the compile listing and went over it with him. After about 5 minutes he turned white and said "OH, NOW I REMEMBER". He tried to leave but I asked him to please follow me he resisted a little so I took him up to his VP's office and asked to see the VP.
It was the end of the day and he was free so I got him to go in with me. I told the VP that the programmer had something to tell him. The programmer was pale with fright. He hemmed and hawed and finally got out the sentence it was his fault and it was his code. The VP looked at me and I had a very annoyed look on my face (I WAS ANNOYED) and the VP said well this won't happen again. I was courteous and said thank you and walked out.
The programmer was asked to leave but I got very annoyed as he got a consultants job at a large insurance company here in Chicago and a very nice pay raise.
There is no justice in the world.
Ed
John McKown
<snip>
> There is no justice in the world.
>
> Ed
Agreed. In my first job, I had one programmer who got an S0C7 abend. I
told him it was a data problem, look in his program to determine which
variable was bad. His response: "System abend - system problem - you fix
it."
--
Trying to write with a pencil that is dull is pointless.
Maranatha!
John McKown
Ted MacNEIL
Same story everywhere.
When I started, we knew that S0C* abends were caused by application programmer issues.
Now, if it starts with "S", it has to be a system problem.
Maybe it's a good thing that LE converts them to U*** abends. (8-{]}
User abend - user problem - they fix it!
-
Too busy driving to stop for gas!
Don Leahy
SNIP
>
> The programmer was asked to leave but I got very annoyed as he got a consultants job at a large insurance company here in Chicago and a very nice pay raise.
>
> There is no justice in the world.
>
lucky you didn't suffer the same fate; VPs don't like having to
intervene in petty (to them) technical disputes. :-)
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of John McKown
>
> On Sat, 4 Jul 2009, Ed Gould wrote:
>
> <snip>
> > There is no justice in the world.
> >
> > Ed
>
> Agreed. In my first job, I had one programmer who got an S0C7 abend. I
> told him it was a data problem, look in his program to determine which
> variable was bad. His response: "System abend - system problem - you
fix
> it."
Write an ESPIE to change it to a U0C7 and "toss" it back. :-)
-jc-
John McKown
>
> Write an ESPIE to change it to a U0C7 and "toss" it back. :-)
>
> -jc-
>
No such thing. User abends are decimal in nature, whereas system abends
are 3 character hex.
--
Trying to write with a pencil that is dull is pointless.
Maranatha!
John McKown
----------------------------------------------------------------------
Chase, John
> From: IBM Mainframe Discussion List On Behalf Of John McKown
>
>
> >
> > Write an ESPIE to change it to a U0C7 and "toss" it back. :-)
> >
> > -jc-
> >
>
> No such thing. User abends are decimal in nature, whereas system
abends
> are 3 character hex.
U0199.
-jc-
Rick Fochtman
>>-----Original Message-----
>>From: IBM Mainframe Discussion List On Behalf Of John McKown
>>
>>On Sat, 4 Jul 2009, Ed Gould wrote:
>>
>><snip>
>>
>>
>>>There is no justice in the world.
>>>
>>>Ed
>>>
>>>
>>Agreed. In my first job, I had one programmer who got an S0C7 abend. I
>>told him it was a data problem, look in his program to determine which
>>variable was bad. His response: "System abend - system problem - you
>>
>>
>fix
>
>
>>it."
>>
>>
>
>Write an ESPIE to change it to a U0C7 and "toss" it back. :-)
>
> -jc-
>
>
Or grind his nose into the SYSTEM CODES manual until he learns to READ IT!
I used to keep Systems Messages and System Codes in a single LARGE
three-ring binder. The first time someone asked about a system message
or code, we'd look it up together; the second time, I just handed it to
him. The third time, I dropped it on his feet and the fourth time, I
threw it at him. People around me learned fast, most of them anyway. And
I always made sure that current copies were available to averyone, at
all times. Sometimes, cruelty has a positive effect. Sometimes.
Rick