IBM Mainframe Forum

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!

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.



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.



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".

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

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

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.

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.

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!

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