Abend Statement at wrong offset



Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Re: Abend Statement at wrong offset

Postby Guybond » Tue Oct 30, 2012 12:15 pm

Hi Guys,

OK Billyboyo you are right.. The SOC4 wasn't from the SSRANGE Check. The default compile here is with SSRANGE off, so I needed to compile again with it on.
The issue was within the logic module "Y2CCS507" which does some date manipulation stuff.
I don't perform it, but obviously somewhere else it is called before my code.
It is a standard copybook included in all the programs here.

I removed it and my forced subscript error is now what the abend catches. And is showing the correct line of the statement number.

IGZ0006S The reference to table AMBS-WS-FILE-NAME-CHAR by verb number 01 on lin
region of the table.
From compile unit XMLTST at entry point XMLTST at statement 1390 at co
offset +000013BA at address 1A601C6A.

Code where PMT cycle is max 8:
001389 MOVE 10 TO AMBS-PMT-CYCLE-DUE
001390 MOVE AMBS-WS-FILE-NAME-CHAR(AMBS-PMT-CYCLE-DUE)
001391 TO AMBS-WS-FILE-NAME-C

Thanks for the help everyone.

I think I need to cleanup a lot of these programs and remove some of the dead code that is not needed!
Guybond
 
Posts: 6
Joined: Mon Oct 29, 2012 2:25 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Re: Abend Statement at wrong offset

 

Re: Abend Statement at wrong offset

Postby BillyBoyo » Tue Oct 30, 2012 1:17 pm

I'm glad you've had some progress.

However, Y2CCxxxx "date processing" looks like "Year 2000" stuff. If you remove it, you'd best be sure it is no longer needed.

I think you need to track the S0C4. If the program-code is memory is being "overwritten", then removing a bit of code can sometimes make the problem "go away" in that an abend is no longer caused, but can just mean that something else is going on that doesn't get noticed, over overwriting "first time" code, so you don't know it's gone.

It may well be the first line of code in the copybook, then the compiler is showing you the first line-number in the compile that "could be" involved.

000200           MOVE A
000201             TO B


If it is A which causes an abend, you'd want to see 000200. If B, to avoid confusion, you'd still want to see 000200.

000200           MOVE A TO B MOVE C TO D MOVE E TO
000201            F


If "F" causes a problem...

Maybe have a look at http://ibmmainframes.com going forward. It won't automatically be assumed you are a beginner, but make sure you ask "good questions".
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: Abend Statement at wrong offset

Postby Guybond » Tue Oct 30, 2012 1:32 pm

OK great thanks,

I use the COBOL date functions now rather than the supplied ones here to manipulate dates.
FUNCTION DATE-OF-INTEGER
FUNCTION INTEGER-OF-DAY etc.

I think the SOC4 was because the file I was using later on was empty and I didn't have any file status checks on it, oops... So opened and tried to read an empty file.

I will move over to the other forum I think, didn't see at first this was for students etc mostly.

Cheers
Guybond
 
Posts: 6
Joined: Mon Oct 29, 2012 2:25 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Abend Statement at wrong offset

Postby enrico-sorichetti » Tue Oct 30, 2012 1:37 pm

but even there, a supposedly expert forum, You will see questions
that really should belong to the kindergarten forum(*) ;)

(*) no offense meant for children attending kindergarten
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort
enrico-sorichetti
Global moderator
 
Posts: 2644
Joined: Fri Apr 18, 2008 11:25 pm
Has thanked: 0 time
Been thanked: 130 times

Re: Abend Statement at wrong offset

Postby BillyBoyo » Tue Oct 30, 2012 3:29 pm

I'm still not sure about your S0C4. If you open a file, read it, and it is empty, you won't get a S0C4 unless you also try to access the data defined under the FD. If that is what's happening, then OK, but the actual offset from the dump should point, via the offset in the program, to a line of code which is accessing data in the FD.

If it is something else, I feel you need to find it.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Re: Abend Statement at wrong offset

Postby dick scherrer » Tue Oct 30, 2012 11:25 pm

Hello,

I agree with the "you need to find what caused the problem rather than work around it". . . Strongly agree :|

I use the COBOL date functions now rather than the supplied ones here to manipulate dates.
I also believe you need to examine the Y2CCxxxx code and make sure it returns Exactly what the date functions return. I suspect that "really close" is Not good enough.
Hope this helps,
d.sch.
User avatar
dick scherrer
Global moderator
 
Posts: 6304
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 91 times

Re: Abend Statement at wrong offset

Postby Guybond » Wed Oct 31, 2012 3:34 pm

Hi,

The SOC4 was because I had the incorrect DD name for the file in the JCL compared to what was assigned in the program.
I had //VSD860AO in the JCL and 'assign to VSD860' in the program. Took me way to long to see this! haha..

The Y2CCxxxx coopybook code is a routine to return a julian date from a gregorian date, so prefer the cobol function really..

thanks!
Guybond
 
Posts: 6
Joined: Mon Oct 29, 2012 2:25 pm
Has thanked: 0 time
Been thanked: 0 time

Re: Abend Statement at wrong offset

Postby BillyBoyo » Wed Oct 31, 2012 4:47 pm

Thanks for the update.

If it ain't broke, don't fix it without a Spec
If it is broke, don't fix it without a Spec
If it ain't broke, don't break it, with or without a Spec

Those are some of my CYA rules :-)
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 264 times

Previous

Return to IBM Cobol

 


  • Related topics
    Replies
    Views
    Last post