S0C4 Abend when running a converted code

rakeshnaredlla · New User Joined: 04 Aug 2008 Posts: 26 Location: Hyderabad

I have converted a cobol -I code to cobol 390 this cobol -1 code was calling a assembler routine. The assembler routine is used to open files which would be used in JCL.

This assembler program was running fine with Cobol -1 code but when I am using the same assembler code for Cobol 390 it was abending with S0C4 abend.

I have replaced the following code in the assembler program

Before:

dbzTHEdinosauer · Posted: Thu Jun 25, 2009 8:03 pm

I have forgotten everything I knew about assembler, but as a BROT,

I always have assembler modules that are CALLed by COBOL modules
LINKed above the line - amode any, rmode 31 (or the other way around).

To CALL a below the line assembler module from COBOL (which is usually above the line - unless your site is all below the line)
you need a wrapper or something. It is just easier to insure that the assembler module execute above the line.

Bill O'Boyle · Posted: Sat Jun 27, 2009 4:57 am

Substitute R12 with another register. R12 (when called from a HLL running under LE), contains the address of the CAA (Common Anchor Area).

Also, if you want to retain AMODE 24 in Assembler, specify DATA(24) in the COBOL compile options.

Regards,

rakeshnaredlla · New User Joined: 04 Aug 2008 Posts: 26 Location: Hyderabad

Thanq Bill. I tried the approch whic you mention but it is abending in some other place.Please find the details below.

This assembler modules is loading an address of a program using the below code

UmeySan · Posted: Mon Jun 29, 2009 3:50 pm

@ rakeshnaredlla !

So you have converted a cobol-I code to cobol-390 code. Ok Sir. But
why have you modified the called Ass-Programm, which is called???

What happens, if you use the original Ass-Programm. Remember Bill's hint about DATA(24) in Cob-Programm.

I could not realy comprehend, why you changed that simple OPEN command, in conjunction with a GETMAIN.

Here's a little example, using OPEN/CLOSE in an Ass-Pgm below the line using Dataareas above the line.

IF and EIF are in-house macros, same as IF-THEN-ELSE-ENDIF in Cobol.
So same as CLC and BRUNCH, please ignore.

USING IHADCB,R11

CHGAMODE 31,R14
L R11,=A(S3OLD)
IF DCBOFLGS,Z,DCBOFOPN,TM
OPEN ((R11),INPUT)
LH R7,DCBLRECL
EIF
CHGAMODE 24,R14

CHGAMODE 31,R14
L R11,=A(S3OLD)
IF DCBOFLGS,NZ,DCBOFOPN,TM
CLOSE ((R11))
EIF
CHGAMODE 24,R14

DROP R11

* Definitions

S3OLD DCB DDNAME=S3OLD,
MACRF=(GL),DSORG=PS,
EODAD=OLDVSNEW_CLOS,
DCBE=S3OLD_DCBE

S3OLD_DCBE DCBE RMODE31=BUFF

rakeshnaredlla · New User Joined: 04 Aug 2008 Posts: 26 Location: Hyderabad

Hi Umeysan,

The reason for changing the Assembler code is.

The loads which is getting created after converting the cobol code to cobol 390 is reflecting 24/24 because of this assembler programs which are in 24/24 .So to make the load as 31/ANY we include the RMODE(ANY) AMODE(31) in the cobol link member but due to this the assembler was showing S0C4 abend, to resolve this we did the changes in assembler program.

CHGAMODE is not available under our assembler environment.

Please let me know if you have any questions.

Thank you,
Rakesh

CaptBill · Posted: Mon Jun 29, 2009 6:41 pm

A rule I learned about 24/31 but programs:

A 24 bit program can call a 31 bit program with no problem.
A 31 bit program can call a 24 bit program, but will usually have problems.
If the called program is 24 bit, then compile the calling program with AMODE(24).

Bill O'Boyle · Posted: Tue Jun 30, 2009 4:45 am

Are you passing 24-Bit storage from the COBOL caller to the Assembler sub-program as a separate parm?

Could you post your R1 parmlist that you're mapping-to in the sub-program?

Also post your COBOL CALL USING statement.

I'm not trying to discourage you using Assembler, but have you checked-out the EXTERNAL attribute in COBOL (introduced in VS/COBOL II, 20+ years ago), which includes (amongst others) FILES being defined as EXTERNAL to the COBOL CALLER?

If you rewrote the sub-program in COBOL, it might make things easier going forward as well as increase the maintenance ability for Tech's who don't know Assembler.

Also, LE (Language Environment) has some handy-dandy Callable Service routines, such as CEECRHP (Create Heap), where you can specify the option as to where the Heap Storage needs to be allocated (IE: Below The Line), coupled with CEEGTST (Get Heap Storage --- Similar to a GETMAIN and/or STORAGE OBTAIN), using the options which you defined in the previous CEECRHP call.

Just some thoughts....

Regards,

rakeshnaredlla · New User Joined: 04 Aug 2008 Posts: 26 Location: Hyderabad

Hi Bill,

No I am not passing 24-Bit storage from the COBOL caller to the Assembler sub-program as a separate parm.
But in my cobol link i am using this MODE AMODE(31),RMODE(ANY).

Below is the call details

Robert Sample · Posted: Tue Jun 30, 2009 5:02 pm

Okay, you originally said

dbzTHEdinosauer · Posted: Tue Jun 30, 2009 5:08 pm

and the amode rmode attributes of both as revealed in the loadlib.

from the member display list of the loadlib and PF11 - cut and paste the rmode amode attributes.

please.

rakeshnaredlla · New User Joined: 04 Aug 2008 Posts: 26 Location: Hyderabad

Robert,

This is what happening with my Assembler, it is getting called from a Cobol program and it also calls another cobol Program.

Here is the example Prg1 calls----> ASMPROG Calls----> Prg2.

Please find the call statement which is getting used for calling an assembler.

Robert Sample · Posted: Tue Jun 30, 2009 6:53 pm

Okay, your PRG2 COBOL program is expecting a 200-byte area, followed by a 603-byte area, followed by a 1-byte area. However, the assembler program is passing an address to a 4096-byte area (which is wasteful but not wrong), a full word (which may or may not be an address), and an address to a 1-byte area. If MASORGEN in the assembler code is not set to an address before the call to PRG2, that could easily explain your abend since COBOL would assume the full word points to the address of a 603-byte memory area.