|
View previous topic :: View next topic
|
| Author |
Message |
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
I have the following sysout available from one of the executions. This happened 1/15 times that I ran the same job. Not that it created any issue - all the DB2 tables that were being updated in the job got updated. However, I would like to know what exactly this abend means -
On a QW, it gives the following information -
| Code: |
0E0
Explanation: A program check occurred. The hexadecimal interruption code
is as follows: |
| Code: |
| 29 An ALET specified an access list entry (ALE) that is not valid. |
| Code: |
+IDI0001I Fault Analyzer V11R1M0 (UK68814 2011/06/16) invoked by IDIXDCAP using
+IDI0002I Abend U0000
+IDI0003I Fault ID F58500 assigned in history file PDT.FAULTA.SYSD.HIST
$HASP375 UATDBLOD ESTIMATED LINES EXCEEDED
$HASP375 UATDBLOD ESTIMATE EXCEEDED BY 10,000 LINES
$HASP375 UATDBLOD ESTIMATE EXCEEDED BY 20,000 LINES
$HASP375 UATDBLOD ESTIMATE EXCEEDED BY 30,000 LINES
IEA995I SYMPTOM DUMP OUTPUT 678
SYSTEM COMPLETION CODE=067 REASON CODE=00000014
TIME=01.30.19 SEQ=02690 CPU=0000 ASID=0192
PSW AT TIME OF ERROR 078D7000 B68B2CC2 ILC 4 INTC 2C
ACTIVE LOAD MODULE ADDRESS=368A1170 OFFSET=00011B52
NAME=DK1TNUCL
DATA AT PSW 368B2CBC - 101058F0 102458E0 F1644100
AR/GR 0: 00000000/00000007_00000004 1: 00000000/00000000_3678BDC4
2: 00000000/00000000_006F5134 3: 00000000/00000000_000B0F50
4: 00000000/00000000_368B91A8 5: 01810085/00000000_00000000
6: 00000000/00000000_B688E3BE 7: 00000000/00000000_00000000
8: 00000000/00000000_3678BDC4 9: 00000000/00000000_368B9000
A: 00000000/00000000_3678B000 B: 00000000/00000000_368B2570
C: 00000000/00000000_3204F734 D: 00000000/00000000_36501078
E: 00000000/00000000_33A56494 F: 01810085/00000000_00000000
END OF SYMPTOM DUMP
IDI0123S Processing of abend S0E0 terminated due to unsupported execution enviro
$HASP375 UATDBLOD ESTIMATE EXCEEDED BY 40,000 LINES
$HASP375 UATDBLOD ESTIMATE EXCEEDED BY 50,000 LINES
$HASP375 UATDBLOD ESTIMATE EXCEEDED BY 60,000 LINES
IEA995I SYMPTOM DUMP OUTPUT 389
SYSTEM COMPLETION CODE=0E0 REASON CODE=00000029
TIME=01.31.07 SEQ=02690 CPU=0000 ASID=0192
PSW AT TIME OF ERROR 078D7000 B68B2CC2 ILC 4 INTC 29
ACTIVE LOAD MODULE ADDRESS=368A1170 OFFSET=00011B52
NAME=DK1TNUCL
DATA AT PSW 368B2CBC - 101058F0 102458E0 F1644100
AR/GR 0: 00000000/00000004 1: 00000000/3678BDC4
2: 00000000/006F506C 3: 00000000/000B0F50
4: 00000000/368B91A8 5: 01810085/00000000
6: 00000000/B688E3BE 7: 00000000/00000000
8: 00000000/3678BDC4 9: 00000000/368B9000
A: 00000000/3678B000 B: 00000000/368B2570
C: 00000000/3204F734 D: 00000000/36501078
E: 00000000/33A56494 F: 01810085/00000000
END OF SYMPTOM DUMP
WLPACT01 UATDBLOD STEPU001 IKJEFT01 CC: 0012
IEF404I UATDBLOD - ENDED - TIME=01.31.20
$HASP395 UATDBLOD ENDED |
Regards,
C.T. |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Code: |
| SYSTEM COMPLETION CODE=067 REASON CODE=00000014 |
Suggest you resolve the first error before going on to some other. . .
What kind of program was executing (own code, utility, etc)? |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi,
On a subsequent execution, both these errors got resolved. It's a DB2 module (own code) that inserts data into 6 DB2 tables. I needed to congest data in tables as part of performance testing, and this was 1 out of the 15 executions of the same job, to load up the data.
And this instance didn't create any issue with the inserts; infact, the module completed successfully (the module step is the only step in the job). However, the job abended with MAXCC=12. Since I got the data inserted fine (verified from tables), I just went on with the subsequent resubmissions - all of which - completed successfully with MAXCC=0.
Was curious to know the reason for these abends that happened (again, the module completed successfully as I can see from its SYSOUT).
Regards,
C.T. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
An ALET is used T/W Access Registers in Assembler. You've got some advanced code to deal with. 
You probably should contact the person who wrote this for some assistance....
Mr. Bill |
|
| Back to top |
|
|
Mickeydusaor
Active User
Joined: 24 May 2006
Posts: 258
Location: Salem, Oregon
|
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| You've got some advanced code to deal with. |
Or some rather simple code that has errors in that it can be blown up by data that the code does not expect. . .
Walking on storage can cause many really ugly abends. . . |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Thanks all, for the responses...
Guess the issue had something to do with the environment at that point of time (perfect alignment of stars maybe  ). However, the module executed just fine (reason to believe there wasn't anything incorrect with the code).
In the subsequent runs, this issue never surfaced.
Regards,
C.T. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Well, you have an 067 abend with reason code 14.
The 0E0 I think was just a dump in the dump routine.
It is unlikely that whatever caused this (067)has just gone away on its own.
As Dick has hinted, you could have a busted subscript/index/subroutine going wild which got as far as treading on your code. The abends can get weird for this, because it is not instructions then being executed, but code that happens to be the same as an op-code but is unlikely to have the rest of the instruction correct.
If your database updates are OK, verified as OK, not just "you think", then I'd concentrate on what happens after you finish with the databases.
Problem is, if there is an error, it is still there, only the next time (with different data) it did something else (didn't walk as far, maybe).
If you leave it, because it has "gone away", there is a chance that it is busting something each day, and by the time you find it because it abends again, it might have accumulated a lot of damage.
Funny, whenever I got an abend, it was always my code that did it, in some way shape or form, even if just uncovering something old. If you assume your code is OK, then you are making it more difficult to find mistakes. Bust that habbit, please. |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
ohhh... good thing that this was just a routine written to congest a series of DB2 tables as part of performance analysis (test region). for the data, i did verify it, and is perfect!
i did 15 executions (had to since there are 6 DB2 tables involved, and 1 entry in the base table corresponds to 9504 entries in the child that comes at the lowest end in relationship. 15K in parent would mean abt 152M in the child and my job definitely gonna hit S322 with a single execution of 15K) of the same code to load up the data and 1/15 threw these errors... |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
OK. If you said that up front, you'd not have got the sermon (maybe).
Put a big note in your program, to remind yourself of the abend. Then if you use it again or clone it, you'll know to be wary and if you get something else odd, maybe it'll help put two and two together.
Did you look at the dump? Do you still have it? You could try to locate the start of the procedure code of your program in the dump. Then browse the load library and locate it there. If they are the same for, say, 100 bytes then you are probably not going walking. Check around the NSI, same thing, is the code undamaged?
Give it a go. The more dumps you look at, the easier it gets to look at them. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| i did verify it, and is perfect! |
Maybe, or maybe something slipped thru earlier. . .
Keep in mind that this has failed and if no changes were made to the code to correct the failure, it will happen again if the same conditions are met.
Bad thing about computers - they are quite consistent. . .  |
|
| Back to top |
|
|
|
|
