Page 1 of 3

Facing S0C4 abend

PostPosted: Thu Feb 24, 2011 12:31 pm
by sriraj1122
Hi ,

I am calling a subprogram by passing one variable to it. When I am executing the main program I am facing S0C4 abend. All the passed variables & passing variables have the same length still facing the problem. Here is my below code.

Main Program:
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-PGM PIC X(06) VALUE SPACES.
01 WS-VAR PIC X(06) VALUE SPACES.
PROCEDURE DIVISION.
MOVE 'CALLS1' TO WS-PGM.
MOVE 'SRIRAJ' TO WS-VAR.
DISPLAY WS-PGM ':' WS-VAR.
CALL WS-PGM USING WS-VAR
END-CALL.
STOP RUN.


Sub Program :
WORKING-STORAGE SECTION.
01 WS-STATUS1 PIC X(06) VALUE SPACES.
LINKAGE SECTION.
01 WS-VAR PIC X(06).
PROCEDURE DIVISION USING WS-VAR.
MOVE 'SUBPGM' TO WS-STATUS1.
DISPLAY WS-STATUS1.
DISPLAY WS-VAR.
GOBACK.


Facing S0C4 error at the statement -- > DISPLAY WS-VAR.

Please advice.

Re: Facing S0C4 abend

PostPosted: Thu Feb 24, 2011 3:08 pm
by BillyBoyo
Looking at your code, there is nothing obvious to cause this. Please note, the length of an item in the Linkage Section does not have to match the length in the calling program. We usually make them the same, because it is sensible. But if the lengths differ, it will never cause an 0C4. All that is passed to the called program is the address of the parameter.

So, you need to check your compile for the calling program. If the code looks OK, but things aren't OK (you are abending), then maybe the code that is being executed is not the same as the code you are looking at. For instance, the S0C4 would occur at exactly that place and no earlier if you called the sub-program with no parameters. If an earlier version of your calling program was doing that and you haven't compiled the latest, or didn't check that it compiled correctly, or do not have the correct load library in place, then it would be like this.

Have a look at the output listing for your calling program. Note down the exact date/time of the compile. Look at the dump. Even if you have no dump tools to help, early on in the dump you will find the name of the calling program. And some little distance after that you should see the date/time stamp of the compile (format the same as the listing, so easy to see). They should be identical if you are executing the correct version of the calling program.

If this doesn't help, we'd need more information from you.

Re: Facing S0C4 abend

PostPosted: Thu Feb 24, 2011 3:40 pm
by sriraj1122
Hi Billy,,

Thanx for your prompt response.

I have compiled both the programs and then only tried to execute the main program.
Still facing S0C4 abend.

But im not sure how to check the DATE/TIMESTAMP from the DUMP and Listing.
So as of now im assuming that there is no issue with DATE/TIMESTAMP as it is picking upthe recent compiled load module.

Please advice.

Re: Facing S0C4 abend

PostPosted: Thu Feb 24, 2011 7:16 pm
by stevexff
A couple of obvious questions:

Because you are using CALL with a variable, COBOL will be doing a dynamic call to the subprogram. Have you link-edited both modules correctly?

What are the AMODE and RMODE of both programs? If they are different it would explain the S0C4...

Re: Facing S0C4 abend

PostPosted: Thu Feb 24, 2011 10:29 pm
by BillyBoyo
Important to check your compiles and links, as Stevexff is saying.

In the dump, assuming you have no tools to interpret it, you will have a load of stuff up front, then the dump itself, which on the left side of the page it will have all the HEX representation, and on the right side it will show you whatever is displayable (numbers, letters, punctuation etc). The first thing in this part of the dump will be your calling program. You should be able to recognize the time/date stamp.

You could also try locating references to your program name.

If you still can't find your program, try defining an 01 in your working storage of the calling program with some short random string of characters which is unlikely to occur in many places. Compile & link. Check compile and link. Run. Now you should be able to find you program by locating that string. If you can, of course, then you are not running an old version, for definite. But you will know how to find the time/date of compile in the future (always the first thing I'd check, am I looking at the correct compile listing - and if not, why not?).

Look on the log output, and at the start of the dump, see if there is any more information, more messages you don't recognise, reason codes, anything like that.

Re: Facing S0C4 abend

PostPosted: Fri Feb 25, 2011 12:15 pm
by sriraj1122
Hi Steve,

AMODE & RMODE of both the programs are same as below.
AMODE=31,RMODE=ANY

Re: Facing S0C4 abend

PostPosted: Fri Feb 25, 2011 4:33 pm
by Zio69
Just for fun.... try to add these two variables
       01 bin-var    pic 9(9) comp-5.
      01 packed-var pic 9(11) comp-3.

Then, just before the DISPLAY that seems to cause your S0C4, add these statements
          MOVE ADDRESS OF WS-VAR TO BIN-VAR
          MOVE BIN-VAR TO PACKED-VAR
          DISPLAY PACKED-VAR


It won't solve your problem right off the bat, but it will help understanding what is being passed to your subpgm..... or rather, where it is.

Re: Facing S0C4 abend

PostPosted: Fri Feb 25, 2011 8:46 pm
by BillyBoyo
sriraj1122, we need more information to give you any more help. On your outputs, you have the information, but don't know what it is.

Can you find the "General Registers" in the dump? If so, look at contents of Register 7. I am estimating that since you have only one item in your linkage, and you have no files, that Register 7 contains the address of the item you are trying to display. You can check on you Cobol listing if you have a DMAP (Data Map). If it says BLL=R7 (or something like that) for your field, then it is using Register 7. If it is using something else, obviously look there.

Try to look again at the dump. When it gets to the real dump part, the memory contents, the first column is the storage address. Is R7 (or whatever) less than the lowest address? (Particularly if zero). R7 should be pointing to the value of your field in the calling program (which will also, if it has a correct value, help you to find the program in the dump!).

If you are in the mood for trying things, try using call literal, rather than call dataname. Shouldn't make any difference that I know of, but if it doesn't work at all it might give some new clue. I hate these sort of suggestions, but there's not much else we can do without info.

Note. My Cobol is old. If the "usual" register usage in Cobol has changed, someone else please step in and say so :-)

Re: Facing S0C4 abend

PostPosted: Mon Feb 28, 2011 3:53 pm
by Zio69
My apologies... I forgot about COBOL's idiosincrasy for pointers. The actual syntax to achieve what I asked is:
      WORKING-STORAGE SECTION.                     
      01 bin-fld pic 9(8) comp-5.                   
      01 ptr-fld redefines bin-fld usage is pointer.
      01 pk-fld pic 9(11) comp-3.                   
      linkage section.                             
      01 parm         pic x(6).                     
      PROCEDURE DIVISION using parm.               
          set ptr-fld to address of parm.           
          move bin-fld to pk-fld                   
          display pk-fld                           
          move 'hullo' to parm.                     
          display 'inside subpgm ---> ' parm       
          goback.       


I admit I tried something like your code.... and of course it works. Did you get any kind of warning for your SUBPGM at compile time? Could it be that by mistake it was pre-compiled for use under CICS??

Re: Facing S0C4 abend

PostPosted: Mon Feb 28, 2011 8:20 pm
by stevexff
Sriraj

Can you post the linkedit control cards for both modules please? All of it, not just the AMODE/RMODE?