View previous topic :: View next topic
|
Author |
Message |
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006 Posts: 6250 Location: Mumbai, India
|
|
|
|
You need to give us something concrete to work upon as you're getting a user abend which might mean anything. USER COMPLETION CODE=4087 REASON CODE=00000007 might have a distant possibility to be called by IMS if IMS is involved. Having said that, as Robert indicates about CEE3204S -- I suspect that, it can be as trivial as not using an index properly.
Do you have ODO in your COBOL program?
Suggest, as one of the options, you compile the program with SSRANGE option and execute it again. DISPLAY all the INDEXes and SUBSCRIPTs and check if they are in permissible range. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Looking a bit further, the CEEBINIT and the IGG are probably "artefacts", the original abend causing subsequent abends as LE tries to "clear up".
IEA995I SYMPTOM DUMP OUTPUT 941
Code: |
USER COMPLETION CODE=4087 REASON CODE=00000007
TIME=20.20.32 SEQ=15804 CPU=0000 ASID=0091
PSW AT TIME OF ERROR 078D1000 86BDFDBC ILC 2 INTC 0D
NAME=UNKNOWN
DATA AT PSW 06BDFDB6 - 00181610 0A0DA7F4 001C1811
AR/GR 0: 00000000/84000000 1: 00000000/84000FF7
2: 00000000/00000007 3: 00000000/00031038
4: 00000000/06C1C128 5: 00000000/06C1C2A0
6: 00000000/0002B340 7: 00000000/0002B7F0
8: 00000000/80000000 9: 00000000/00041F9E
A: 00000000/00000001 B: 00000000/86BDFCE8
C: 00000000/0002CB88 D: 00000000/0003FFA0
E: 00000000/8003204A F: 01000002/00000007 |
The above is probably what you want to concentrate on.
The PSW looks "odd".
Register 8 "looks like" the last parameter passed to a Cobol program had no address. But with storage overwriting this needn't matter necessarily (as anything could be happening).
You dropped your current record and still abended, so it is a prior record causing the problem. "Eyeball" the file (see if records "look" consistent, check any occurence values) and the dump (look for "repeating" storage, if you find it, follow it backwards to where it starts and work out what module that is).
As Anuj said, we have little really to go on. If still stuck (after some sleep/someone else taken over) tell us about the "files" the program is reading, how many modules are called and any unanswere questions from above. I think we can ignore the "recursive" bit :-) |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
This particular problem is one of the class of problems that is rarely possible for an application programmer to solve alone. Usually resolution requires generating a trace and reading that trace to determine what stepped on storage and when -- and that could have happened before the first record was processed.
You need to talk to your site support group and get a system programmer involved. Otherwise, the only realistic option to resolve the issue is to contact IBM and open a PMR -- and IBM will certainly want to see the trace as mentioned in the 219 error message text. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Robert Sample wrote: |
This particular problem is one of the class of problems that is rarely possible for an application programmer to solve alone. [...]
|
I eat 'em for breakfast :-)
Good advice, though, Robert. After 10 hours there must have been some sort of "escalation".
Takes our fun away, but Production waits for no-one... |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
I wonder....
after 20 years ( according to the TS ) the criteria used for the original design should be reviewed
the amount of data processed in a reasonable healthy organization must have significantly grown after 20 years.
if I had money to spend I would bet on an internal table overflow!
and consequent program/working storage corruption |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
if I had money to spend I would bet on an internal table overflow! |
Yup, that or possibly a called module overwriting some of the caller's memory. . .
Has any of the called modules been changed since the last successful run? |
|
Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010 Posts: 175 Location: India
|
|
|
|
All of you.... Thanks for helping out..
I skipped 100k records and ran the job. the job completed fine.
This is a monthly Job and i have to reprocess the 100K records next month. I am working on this, i will update the forum after this is resolved..
Thanks again.. |
|
Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010 Posts: 175 Location: India
|
|
|
|
All,
Am writing this post for others to use in future.
I got a 4087, as discussed previously this was a s0c4 abend. The output file for this job was a VBS file (Recordsing mode spanned).
LRECL:1 to 25452.
The output data exceeded the maximum length and hence it caused a boundary violation.
The module was developed a very long time back and there was no file status variable defined. I have modified the program with file status defined it shows a status of 44 now (boundary violation). I have handled this in the code, now it is working file. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Good to hear it is resolved - thank you for the follow up info
d |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Yes, also a useful warning for those too lazy to code FILE-STATUS. Down the line, it costs time and money. |
|
Back to top |
|
|
shankarm
Active User
Joined: 17 May 2010 Posts: 175 Location: India
|
|
|
|
One more thing i want to add is,
We cannot try to skip a record in this case.
E.G
If there are 50 records in a file, if the job abends in 36th record, skipping 36th record will not solve the problem.
Issue record can be on of the 35 records already processed.
Sometimes, if we split the file into smaller files the job runs fine.
The job will not abend in the same statement all the time. every time the job will abend in a different statement and in a different record.
The root cause is that, the program is stepping on storage.
Sometimes its the table overflow, sometimes its boundary violation in file. It could be anything.
Hope this info helps the reader. |
|
Back to top |
|
|
|