Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Handling a data item having address

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Arunkumar Chandrasekaran

New User


Joined: 01 Jun 2010
Posts: 63
Location: India

PostPosted: Sat Mar 30, 2013 11:16 pm    Post subject: Handling a data item having address
Reply with quote

Hi all,

Recently we encountered a strange situation.Job got SOC4 abend in a particular program.When we checked into this we found ,

Program A is calling program B.

GRVAR is a group item.VARADD is one among the group item having

PIC clause X(4).

ie.

Code:
01 GRVAR.

      05 VARADD   PIC X(4).


VARADD is storing a address of a another group data item MAGADD.

FMDDICTS is one among the group item MAGADD.

Code:
01 MAGADD.

      05 FMDDICTS  USAGE IS POINTER.


FMDDICTS is pointer having address of DEMODICT table.

PROGRAM A is calling PROGRAM B using GRVAR-PTR.
GRVAR-PTR is havingaddress of GRVAR using the below statement.

Code:
SET GRVAR-PTR to ADDRESS OF GRVAR.

In program B here is the code

Code:
01  WS-POINTER USAGE IS POINTER

01 WS-POINTER-X1 REDEFINES WS-POINTER
   05  WS-POINTER-X  PIC X(4).

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

Please explain me what is happening here??

Please let me know if you need any more details.


Thanks,
Arun
Back to top
View user's profile Send private message

Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Sun Mar 31, 2013 12:16 am    Post subject: Reply to: Handling a data item having address
Reply with quote

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?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Sun Mar 31, 2013 12:26 am    Post subject: Reply to: Handling a data item having address
Reply with quote

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.

HTH....
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7315

PostPosted: Sun Mar 31, 2013 5:29 pm    Post subject: Reply to: Handling a data item having address
Reply with quote

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...
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Replace values in the input data Vikas Maharnawar DFSORT/ICETOOL 10 Thu May 11, 2017 2:18 pm
No new posts Group Data based on a key Arun Raj DFSORT/ICETOOL 7 Thu Apr 27, 2017 11:29 pm
No new posts unload data from table with lob columns farhad_evan DB2 0 Sat Apr 22, 2017 1:32 pm
No new posts SORT JSON type of data maxsubrat DFSORT/ICETOOL 8 Wed Apr 19, 2017 6:01 pm
No new posts RC 20 for Address ISPEXEC "ISRED... pkmurali CLIST & REXX 3 Sun Apr 16, 2017 11:30 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us