ASRA ABEND
vikas puri
next sequential instruction to the statment which caused abend. Dump is
written in 24bit address mode.I calculated the offset by subtracting entry
point of program from Second full word of PSW(40 to 63bits). I also
compiled the program amode=24,rmode=24 etc.
But I am not getting the address of offset in the compile listing. This
happened many times.
Please tell me is it right procedure to find out the statement which is
causing abend?
Eagerly waiting for response.
Regards,
Vikas Puri
MGS INC.
PHILADELPHIA
215-209-2240(WORK)
Chase, John
onto the beginning of your load module? I.e., subtract another x'28' from
your calculated offset and that should give you the correct offset into your
listing.
-jc-
vikas puri
But I am subtracting but entry point of that programnot the load point from
psw . I suppose if you use load point only then you need to subtract x'28'.
But even i tried with subtracting x'28', stiil i am not getting the
abending statement.
I am using cics0212 and os/vs cobol.
Thanks,
vikas puri
Kurt Brewner
> Sent: Monday, December 28, 1998 11:05 PM
> To: CIC...@VM.MARIST.EDU
> Subject: Re: ASRA ABEND
Chase, John
remember correctly the entry point address will be that of DFHECI, which is
x'20' bytes in front of your program's code. I'm also assuming that your
listing includes a PMAP, and that is what you're using to find the offending
statement. I don't know of any way to directly correlate a load module
offset with a COBOL statement number without a PMAP.
If the x'20' difference is still not correct, you'll need a link-edit map of
the load module to find exactly where the "preliminaries" end and your
program's code begins. Once you get the correct "adjustment", the
instruction at which you arrive will be the instruction that was scheduled
next to be executed; you then have to "back up" by the ILC (Instruction
Length Code) value to see the instruction that caused the interrupt.
What is the INTC (Interrupt Code) shown near the PSW in your dump? I'm
guessing "7" (most common) which is Data Exception, or "4" which is
Protection Exception, aka "storage violation" (those are "fun" to diagnose).
Richard V.
the entry point of the program you think this is in ...
Richard
VTA Software Inc.
William Lynch
>
> I am analysing cics dump for abend code asra. I calculated the offset of
> next sequential instruction to the statment which caused abend. Dump is
> written in 24bit address mode.I calculated the offset by subtracting entry
> point of program from Second full word of PSW(40 to 63bits). I also
> compiled the program amode=24,rmode=24 etc.
> But I am not getting the address of offset in the compile listing. This
> happened many times.
>
> Please tell me is it right procedure to find out the statement which is
> causing abend?
Does the OS/VS COBOL program in question CALL any other modules? The
ASRA may be in a CALLed program. If so, you'll need to work from the
link edit/Binder map.
HTH,
Bill Lynch
Irwin, Gerry (CORP)
is the amode(31) indicator.
Gerry Irwin
GE IDS
> ----------
> From: vikas puri[SMTP:vikas...@METAMORGS.COM]
> Reply To: CICS List
> Sent: Tuesday, December 29, 1998 1:35 AM
> To: CIC...@UGA.CC.UGA.EDU
> Subject: Re: ASRA ABEND
>
> John,
> I am sending you full details.
> Please see what I am doing that s right?
> Thanks for concern.
>
> TRIMS1 --- CICS TRANSACTION DUMP --- CODE=ASRA TASK=PA1
> SYMPTOMS= AB/UASRA PIDS/566540301 FLDS/F000KC RIDS/YD3360
>
> CICS/VS LEVEL = 0212
>
> PSW 078D2000 89B3B414 00000004 00000000
> REGS 14-4 00269830 00000000 00269850 00269958 0C5B2DB8
> REGS 5-11 002B3850 302B3F40 0C384FF8 002B2850 002B1850
>
> ENTRY LOAD NAME
> POINT POINT
> 09B27160 09B27118 YD1475
> 09B2E678 09B2E630 YD3295
> 09B39F18 09B39ED0 YD3360
>
> Beacuse 32nd bit is 0(24 BIT ADDRESS MODE DUMP). so I am taking
> interuption point as B3B414 AND ENTRY POINT AS B39F18. OFFSET CALCULATED
> IS 14FC.
>
> SOME OF TRACE TABLE ENTRIES RELATED TO MY TASK
>
> REG 14 REQD TASK FIELD A FIELD B CHARS RESOURCE TRACE TYPE
> 5087C6D2 0004 89307 0020DFA0 89200058 ........ SCP RELEASED RSA
> STORAG
> 808EF914 4004 89307 0020DE90 0124FD44 ........ SCP FREEMAIN
>
> 5087C6D2 0004 89307 0020DE90 8C000108 ........ SCP RELEASED USER
> STORAGE
> 89B3B0CC 00F4 89307 00000000 00000E02 ........ EIP LINK RESPONSE
>
> 4083B80E CC04 89307 000000A0 0124FD44 ........ SCP GETMAIN
> INITIMG
> 5087C696 0004 89307 0020DE90 8C0000A8 ........ SCP ACQUIRED USER
> STORAGE
> 9083B890 6004 89307 C1E2D9C1 00000000 ASRA.... PCP ABEND
>
> 5086A732 FE04 89307 00000000 C1E2D9C1 ....ASRA DCP TRANSACTION
>
> compile listing
>
>
> *** M O D U L E M A P ***
>
>
>
>
> ---------------
>
> CLASS B_TEXT LENGTH = 5F48 ATTRIBUTES = CAT, LOAD,
> RMODE= 24
> ---------------
>
>
>
>
> SECTION CLASS ------- SOURCE
> --------
> OFFSET OFFSET NAME TYPE LENGTH DDNAME SEQ MEMBER
>
>
>
>
> 0 DFHECI CSECT 48 SYSLIB 01 DFHECI
>
> 8 8 DFHEI1 LABEL
>
> 8 8 DLZEI01 LABEL
>
> 8 8 DLZEI02 LABEL
>
> 8 8 DLZEI03 LABEL
>
> 8 8 DLZEI04 LABEL
>
> 26 26 DFHCBLI LABEL
>
>
>
>
> 48 YD3360 CSECT 5AB8 SYSLIN 02
> **NULL**
>
>
>
> 5B00 DATBAS CSECT 248 DATABASE 01
> DATBASCX
>
> C R O S S - R E F E R E N C E T A
> B L E
>
> _________________________________________
>
>
>
> TEXT CLASS = B_TEXT
>
>
>
>
> --------------- R E F E R E N C E -------------------------- T A R G E
> T ---
> CLASS ELEMENT |
>
> OFFSET SECTION (ABBREV) OFFSET TYPE | SYMBOL(ABBREV) SECTION
> (ABB
> |
>
> B4 YD3360 6C V-CON | IGZEBST IGZEBST
> 114 YD3360 CC V-CON | DFHEI1 DFHECI
> 118 YD3360 D0 V-CON | DATBAS DATBAS
> 5CE0 DATBAS 1E0 V-CON | DFHEAI0 DFHEAI0
> 5CE4 DATBAS 1E4 V-CON | DFHEI1 DFHECI
> 5F38 IGZEBST 1D0 V-CON | IGZETUN $UNRESOLVED(
> 5F3C IGZEBST 1D4 V-CON | IGZEOPT $UNRESOLVED(
> *** E N D O F C R O S S R E F E
> R E N
> >> >> I am analysing cics dump for abend code asra. I calculated the
> offset
> >> of
> >> >> next sequential instruction to the statment which caused abend. Dump
> is
> >> >> written in 24bit address mode.I calculated the offset by subtracting
>
> >> entry
> >> >> point of program from Second full word of PSW(40 to 63bits). I also
> >> >> compiled the program amode=24,rmode=24 etc.
> >> >> But I am not getting the address of offset in the compile listing.
> This
> >> >> happened many times.
> >> >>
> >> >> Please tell me is it right procedure to find out the statement which
> is
> >> >> causing abend?
> >> >>
Gray, Larry - Larry A
entry point for YD3360 is a 31-bit address. I believe the problem is a
S0C4. If the program is supposed to be running in 24-bit mode, my guess
is that something happened to R6. The first nibble has a 3 while the
rest of the address looks alot like most of the rest of the registers.
You need the cross-reference from the code line to the offset in the
program to determine the line that caused the error. I did not see this
in the listing below.
Larry Alan Gray Phone: 336-658-7944
Technical Support Fax: 336-658-2124
Lowe's Companies Inc. Email: Larry....@lowes.com
vikas puri
Now I have compiled the program in 31 bit amode. Please tell me what is the
offset value of NSI.
Thanks
Gray, Larry - Larry A
mode. I believe your NSI of 14FC is correct.
Thomas Dunlap
> John,
> I am sending you full details.
> Please see what I am doing that s right?
> Thanks for concern.
>
> CICS/VS LEVEL = 0212
>
> PSW 078D2000 89B3B414 00000004 00000000
PSW NSI address (2nd word) looks to be a 31-bit address, X'80' is on
> ENTRY LOAD NAME
> POINT POINT
> 09B27160 09B27118 YD1475
> 09B2E678 09B2E630 YD3295
> 09B39F18 09B39ED0 YD3360
>
> Beacuse 32nd bit is 0(24 BIT ADDRESS MODE DUMP). so I am taking interuption
point as B3B414 AND ENTRY POINT AS B39F18. OFFSET CALCULATED IS 14FC.
This is where the problem lies. You need to treat the addresses as 31-bit since
PSW indicates that is the current mode. Ensure that compile and
link-edit specifies AMODE(24) if you require 24-bit addressing.
> REG 14 REQD TASK FIELD A FIELD B CHARS RESOURCE TRACE TYPE
> 5087C6D2 0004 89307 0020DFA0 89200058 ........ SCP RELEASED RSA STORAG
> 808EF914 4004 89307 0020DE90 0124FD44 ........ SCP FREEMAIN
>
> 5087C6D2 0004 89307 0020DE90 8C000108 ........ SCP RELEASED USER STORAGE
> 89B3B0CC 00F4 89307 00000000 00000E02 ........ EIP LINK RESPONSE
>
REG14 address appears to be 31-bit address (x'80' bit on in first byte). Since
this is related to a LINK, maybe the RSA has been over-layed.
> CLASS B_TEXT LENGTH = 5F48 ATTRIBUTES = CAT, LOAD, RMODE= 24
>
RMODE is "resident mode" for the program, AMODE could still be 31. Check you
default compile and link options.
vikas puri,
I hope this helps out a little. It does appear that the program is AMODE(31)
and RMODE(ANY) based upon the load and entry point, plus PSW NSI.
Check to see if link-edit options match those of the compile, i.e. RMODE and
AMODE. Also check the setting of compile option DATA since this is
used to place working-storage within CICS.
--
Regards,
Thomas Dunlap Senior Systems Advisor to...@themisinc.com
Themis, Inc. http://www.themisinc.com 1 (800) 756-3000
"My opinions are my own, no one else is responsible.
No warrantees given (implicit or explicit)."
" Unite for Java! http://www.javalobby.org "
Chase, John
repeating what others have written...
> -----Original Message-----
> From: vikas puri [SMTP:vikas...@METAMORGS.COM]
> Sent: Tuesday, December 29, 1998 12:36 AM
> To: CIC...@UGA.CC.UGA.EDU
> Subject: Re: ASRA ABEND
>
> John,
> I am sending you full details.
> Please see what I am doing that s right?
> Thanks for concern.
>
> TRIMS1 --- CICS TRANSACTION DUMP --- CODE=ASRA TASK=PA1
> SYMPTOMS= AB/UASRA PIDS/566540301 FLDS/F000KC RIDS/YD3360
>
> CICS/VS LEVEL = 0212
>
> PSW 078D2000 89B3B414 00000004 00000000
>
Bit 0 of the address portion of the PSW is "on", which indicates 31-bit
addressing mode. That may or may not be relevant for the problem at hand.
The INTC is 4, which indicates S0C4 Protection Exception. I don't see an
ILC value.
Near the end of the dump you should find an area labelled "Program Storage".
Scan through that area until you find the line that contains address
x'09B3B414'; that's the line that most likely will contain the instruction
that "crashed" (might be the line before). If I remember correctly, storage
addresses are on the right side of the page, and offsets (from Load Point)
are on the left side.
> REGS 14-4 00269830 00000000 00269850 00269958 0C5B2DB8
> REGS 5-11 002B3850 302B3F40 0C384FF8 002B2850 002B1850
>
Register 6 looks "suspicious" regardless of AMODE. Also, you truncated regs
3, 4, 10 and 11 out of the REGS lines above; their contents may or may not
be relevant to the problem at hand.
> ENTRY LOAD NAME
> POINT POINT
> 09B27160 09B27118 YD1475
> 09B2E678 09B2E630 YD3295
> 09B39F18 09B39ED0 YD3360
>
> Beacuse 32nd bit is 0(24 BIT ADDRESS MODE DUMP). so I am taking
> interuption point as B3B414 AND ENTRY POINT AS B39F18. OFFSET CALCULATED
> IS 14FC.
>
Based on the information above, and the module map later on, it appears that
your calculated offset is correct from the entry point YD3360.
> SOME OF TRACE TABLE ENTRIES RELATED TO MY TASK
>
> REG 14 REQD TASK FIELD A FIELD B CHARS RESOURCE TRACE TYPE
> 5087C6D2 0004 89307 0020DFA0 89200058 ........ SCP RELEASED RSA
> STORAG
> 808EF914 4004 89307 0020DE90 0124FD44 ........ SCP FREEMAIN
>
> 5087C6D2 0004 89307 0020DE90 8C000108 ........ SCP RELEASED USER
> STORAGE
> 89B3B0CC 00F4 89307 00000000 00000E02 ........ EIP LINK RESPONSE
>
> 4083B80E CC04 89307 000000A0 0124FD44 ........ SCP GETMAIN
> INITIMG
> 5087C696 0004 89307 0020DE90 8C0000A8 ........ SCP ACQUIRED USER
> STORAGE
> 9083B890 6004 89307 C1E2D9C1 00000000 ASRA.... PCP ABEND
>
Though you really need a PMAP of your program to exactly correlate the PSW
offset with a specific COBOL statement, the trace shows that the abend
occurred "immediately" after returning from a CICS LINK command, so you
might look in your source code at what follows any CICS LINK commands. Also
check that the program to which you had linked is AMODE and RMODE compatible
with the program that issued the LINK. It is quite possible that the
linked-to program somehow generated a 24-bit address with a "flag byte",
that somewhere along the line got loaded into Register 6, and the current
Amode-31 program is attempting to reference the valid-looking 31-bit address
(without "flag byte") in Reg. 6.
[ remainder snipped to conserve bandwidth ]
-jc-
FirstName LastName" to LISTSERV@UGA.CC.UGA.EDU.
a 24-bit program from a 32-bit address...a definite no, no! My reasons for
saying this are that the PSW is a 32-bit PSW but all of the program registers
(with the exceptions of R2 and R7) are 24-bit addresses. If this is a COBOL-
VS or COBOL-II program, my recollection is the R6 is the first base register
and it contains a 24-bit address (ignoring the x'03' of course).
Check your link map to insure complete 24-bit addressing and be sure you are
not calling this program from a 32-bit program or linking to it using 31-bit
addressing.
Good Luck!
Oh, by the way; someone likened an "0C4" to a "storage violation." Shame on
you! S0C4 abends do not always lead to storage violations and storage
violations do not always cause S0C4 abends.
Nick Brazziel
> Oh, by the way; someone likened an "0C4" to a "storage violation." Shame on
> you! S0C4 abends do not always lead to storage violations
True. There are three flavors of program interrupts that will result in a S0C4
abend:
1. Interrupt X'04' - Protection Exception - Attempting to store into a
protected storage (i.e. absolute addresses 0-511) is the most common form,
usually when an address of a control block has been zeroed out, a program
subsequently tries to address the control block. Other protection exceptions are
detailed in the S/390 Principles of Operations.
2. Interrupt X'10' - Segment Translation Exception - Attempted to address
virtual storage which the task does not own. Commonly caused by malformed
virtual address. See the Prin. of Ops manual for details.
3. Interrupt X'11' - Page Translation Exception - Same as #2 above, but the
segment portion of the virtual address is in error.
> and storage
> violations do not always cause S0C4 abends.
If by "storage violation" you were referring to a "protection exception"
interrupt (X'04') I would say false. A protection exception will cause a S0C4-04
in the executing task
every time. If you were referring to the various CICS storage violations I
defer.
FirstName LastName" to LISTSERV@UGA.CC.UGA.EDU.
Richard....@CHASE.COM writes:
<< Richard.Tsujimoto >>
I'm in agreement with Richard...none of the G/R contents are within range of
either the abending PSW or the load points of the programs. If these programs
were linked RMODE=24, then they are definitely loaded at the wrong address --
maybe compiled with RM=24 but linked with RMODE=ANY?
FirstName LastName" to LISTSERV@UGA.CC.UGA.EDU.
length regarding "storage violations" but I know full well what assuming can
do, having been in the business since CICS was a baby.