IBM Mainframe Forum

Hi,

I have a COBOL program that dynamically calls an assembler subprogram.

I justed wanted to play around a little with 64bit adressing and tried the following: (I omitted some standard macros we use in our company here, because I think they are not relevant.)


Can anybody tell me why I am getting a S0C4 error?

Thanks!

Does the base register for the PARAM DSECT have a full 64-bit value? You should be able to determine this in the dump.

Similarly, does the base register for the literal have a full 64-bit value?

You are right, there seems to be a problem... The base register for PARAM is 0.

I modified the code a little bit:


and I get this symptom-dump:
USER COMPLETION CODE=4036 REASON CODE=00000006
TIME=14.28.44 SEQ=51341 CPU=0000 ASID=04DE
PSW AT TIME OF ERROR 078D1F00 B5A781DA ILC 2 INTC 0D
ACTIVE LOAD MODULE ADDRESS=359B2000 OFFSET=000C61DA
NAME=CEEPLPKA
DATA AT PSW 35A781D4 - A7F80006 0A0D5840 303C1244
AR/GR 0: B4AAC48A/00000000 1: 00000000/84000FC4
2: 00000000/359A726C 3: 00000000/359A6F18
4: 00000000/0009C340 5: 00000000/00000000
6: 00000000/0006F6C0 7: 00000000/00000000
8: 00000000/00000002 9: 00000000/359568D8
A: 00000000/0011E050 B: 00000000/35A79128
C: 00000000/0009DB88 D: 00000000/359A7518
E: 00000000/B5A7806E F: 00000000/00000006

The indicative dump appears to show a problem in Language Environment module CEEPLPKA; it is not showing the real problem in your real code.

I don't have much experience analyzing these issues, so I'd better not say any more. However, I am quite confident the PSW and registers here have nothing to do with your problem.

This is quite confusing because if I try to analyse the dump with AbendAid, it says the error occurs in TESTPROG (that is definitly the case) but he doesn't show me the GPRs:

*******************************************
* Supporting Environmental Data *
*******************************************

Abend PSW - 078D0001 B580E99A A(TESTPROG) + 000000C2
Prog PSW - 078D0001 B580E99A A(TESTPROG) + 000000C2
Load Module - TESTPROG Entry Point Address - 3593C000
ILC - 00, INTC - 04 Load Point Address - 3593C000

Registers at time of error

64-bit register values were not captured.

The cited SYMPTOM dump from the previous post was written to the LOG of the IMS-region, where my TESTPROG ran.

Unfortunatly, I have no idea how to tell the system to capture the 64bit GPRs too...

I found out that the error was due to content of GPR6.

The following code does not work:

but if I omit the L R6,0(R1) instruction, I don't get the S0C4.

I guess the reason for this behavior is totally clear for experienced assembler programmers, but not for me...
(I don' even know what, according to standard linkage conventions, the content of GPR R1 really is...)

Your L instruction just loads bits 32-63 of register 6, and leaves bits 0 to 31 unchanged. The L instruction uses bits 0 to 63 of register 1 to establish the address since you are in the 64-bit AMODE. If bits 0 to 31 in registers 1 and 6 are 0, your code probably won't get an S0C4.

In standard linkage, register 1 points to one or more words (not double words) that point to the actual data, so your L instruction is loading the actual address of the first parameter area.

I would not enter AMODE 64 until my registers (all of them!) are completely ready.

I find 64-bit register usage hard to understand, which is why I only use ESA/390 Principles of Operation. Bits 32 to 63 of a real general purpose register in z/Architecture correspond to bits 0 to 31 in ESA/390 usage

Hello,

but if I omit the L R6,0(R1) instruction, I don't get the S0C4.

Why did you include this line of source? If it did what you wanted, what would it do?

When dealing with actual addresses versus the contents of the memory at those addresses one must understand completely why they used the code they used. . . One of the worst things that can happen is that a bit of code will initially run successfully and then later "bite" you.

Address mis-use is the reason for the 0c4. . .

078D0001 B580E99A as a PSW clearly indicates you are in the 64-bit AMODE, as indicated by the 0001 in the first 32 bits of the PSW displayed by ABEND-AIDE as well as the high order bit in the second 32-bits.

I'm just guessing here, but I suspect ABEND-AIDE has to dig out registers from Language Environment control blocks, and LE isn't saving 64-bit registers properly.