Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Forum Index
 
Register
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
u4087 Abend - not able to resolve.
Goto page Previous  1, 2
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> ABENDS & Debugging
View previous topic :: :: View next topic  
Author Message
Anuj Dhawan

Senior Member


Joined: 22 Apr 2006
Posts: 6254
Location: Mumbai, India

PostPosted: Wed Jun 13, 2012 1:34 pm    Post subject:
Reply with quote

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
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7312

PostPosted: Wed Jun 13, 2012 3:16 pm    Post subject: Reply to: u4087 Abend - not able to resolve.
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8547
Location: Dubuque, Iowa, USA

PostPosted: Wed Jun 13, 2012 4:36 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7312

PostPosted: Wed Jun 13, 2012 6:24 pm    Post subject:
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Senior Member


Joined: 14 Mar 2007
Posts: 10689
Location: italy

PostPosted: Wed Jun 13, 2012 6:43 pm    Post subject: Reply to: u4087 Abend - not able to resolve.
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19254
Location: Inside the Matrix

PostPosted: Wed Jun 13, 2012 6:50 pm    Post subject:
Reply with quote

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
View user's profile Send private message
shankarm

Active User


Joined: 17 May 2010
Posts: 175
Location: India

PostPosted: Fri Jun 15, 2012 5:55 pm    Post subject:
Reply with quote

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
View user's profile Send private message
shankarm

Active User


Joined: 17 May 2010
Posts: 175
Location: India

PostPosted: Tue Aug 28, 2012 10:12 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19254
Location: Inside the Matrix

PostPosted: Tue Aug 28, 2012 10:26 pm    Post subject: Reply to: u4087 Abend - not able to resolve.
Reply with quote

Good to hear it is resolved - thank you for the follow up info icon_smile.gif

d
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7312

PostPosted: Tue Aug 28, 2012 10:30 pm    Post subject: Reply to: u4087 Abend - not able to resolve.
Reply with quote

Yes, also a useful warning for those too lazy to code FILE-STATUS. Down the line, it costs time and money.
Back to top
View user's profile Send private message
shankarm

Active User


Joined: 17 May 2010
Posts: 175
Location: India

PostPosted: Tue Aug 28, 2012 10:35 pm    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> ABENDS & Debugging All times are GMT + 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts APCT Abend while running an online CI... amitc23 CICS 1 Wed May 06, 2020 9:59 am
No new posts Transaction xxxx abend D106 Andi1982 CICS 1 Fri Apr 03, 2020 1:38 pm
No new posts How to resolve SYNCH15! & SYNCH16... elixir1986 Compuware & Other Tools 0 Thu Mar 19, 2020 5:08 am
No new posts Recovery Routine/Abend exit to releas... Siva NKK Kothamasu PL/I & Assembler 14 Tue Feb 25, 2020 4:43 pm
No new posts HANDLE AD2R CICS ABEND Nileshkul CICS 4 Sat Dec 07, 2019 12:11 am

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us