SET ADDRESS of GRVAR TO GRVAR-PTR
MOVE VARADD TO WS-POINTER-X
SET ADDRESS of MAGADD TO WS-POINTER
IF FMDDICTS NOT = NULL
SET ADDRESS OF DEMODICT TO FMDDICTS.
END-IF
Here is the problem,
Program B is failing in SOC4 when trying to access the DEMODICT fields.it is because FMDDICTS is having invalid address.When we back tracked we found all because of VARADD is not having proper value.
Then we redefined VARADD to 9(4) from X(4) in program A before calling PROGRAM B.Now VARADD is having a proper value and we could see proper address is moved to FMDDICTS.PROgram ran fine.
Here is my question, Why the address is not establishing properly when VARADD is X(4).Since it is storing a address it is not necessarily that it should be having USAGE IS POINTER? (Like FMDDICTS)
How it ran fine when we redefined it to 9(4).
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Why is VARADD not defined as a POINTER anyway?
It is not good practice to REDEFINES a POINTER, and if the only reason is because VARADD is not a POINTER, then the solution seems simple.
Can you recreate the problem with a cut-down (to the minimum) PROG A and PROG B. If so, and you can't get anywhere with that, post the cut-down programs?
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
An address is a 4-byte hexadecimal-value, normally defined as a POINTER and then can be redefined as PIC 9(09) COMP-5 or BINARY (when BINARY, make sure you've compiled the program using compiler option TRUNC(BIN)). It can also be redefined as PIC X(04).
If the sub-program which is attempting to establish addressability using the "ADDRESS OF" is AMODE 24 and the calling program is passing an AMODE 31 address, then a S0C4 will be raised as an AMODE 24 program cannot address an AMODE 31 address, because the top-byte will be truncated.
An AMODE 31 address can be determined by the high-order byte not equal to X'00', whereas, an AMODE 24 address high-order byte is always X'00'.
You can determine this programmatically by checking the PIC X(04) redefined POINTER for LOW-VALUE in the high-order (first) byte.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Shortly before reading the original post, I had come across this.
It seems that due to the "names" involved I took it more "seriously" than it deserves.
The Enterprise Cobol manual states that a POINTER is four bytes long.
Unless the architecture changes fundamentally, four bytes and containing an address (either 24-bit or 31-bit) is enough of a definition to be rock-solid that it cannot just be "changed" in the future and trip someone up.
Do not REDEFINES it as PIC 9(4). There is too great a likelihood that compiler option NUMPROC(NOPFD) (check your Cobol listing to see if you have that) will subtly "change" the address if you ever MOVE a value to that 9(4) or if you want to "test" it against something.
For anyone wanting to "calculate" with POINTERs, pay attention to what Mr Bill has said. To get the "full" address taken into account, define it as COMP-5, with a PIC of between 5(9) and 9(9) inclusive. The alternate to defining it with COMP-5, is to do so as BINARY, COMP or COMP-4 and using compiler option TRUNC(BIN), however, I'd not use a mix of TRUNC options across modules in a system, and there will be "performance implications" in defining all BINARY, COMP and COMP-4 fields as COMP-5 (which is the affect of TRUNC(BIN)).
For the actual question, I'd expect that the attempt to reproduce the problem at its minimum revealed the program error. It would be nice to know...
