Comp-3 Linkage variables having garbage data ?

Sasi Kiran Patha · Posted: Wed Dec 12, 2007 4:04 pm

Hi,

I have comp-3 variables in the linkage of a called program (subroutine).

The called program has to retain the linkage variables' values for
successive calls to the subroutine.

On the first call to the subroutine the comp-3 variables are holding garbage data(invalid numeric data), eventhouh the corresponding variables in the calling program are properly initialised and have valid numeric data.

Please suggest how to proceed.

Thank you,

Gnanas N · Posted: Wed Dec 12, 2007 4:38 pm

Did you get S0C7 abend?

Please explain in detail.

Sasi Kiran Patha · Posted: Wed Dec 12, 2007 4:44 pm

Yes , got S0c7 abend..

Gnanas N · Posted: Wed Dec 12, 2007 4:58 pm

Simply, S0C7 abend is because of Invalid data in Numeric field.

Possible causes for this abend include:
Subscript error, referenced beyond table

COBOL: working storage not initialized.

bad data, should check data for errors.

garbage in a field being tested or displayed.

'move zeroes' to group level is display,

had sublevels that were not
period missing after imperative statements within AT
END clause.

binary field in an arithmetic operation is not large
enough to accept result.

dbzTHEdinosauer · Posted: Wed Dec 12, 2007 5:00 pm

Static or Dynamic Link?
What does the CALL statement look like?
What does the PROCEDURE DIVISION USING statement look like?
What do your Linkage Section definitions look like?

Sasi Kiran Patha · Posted: Wed Dec 12, 2007 5:50 pm

Im using Charm as version control tool.

The program is Static linked. The load module of calling program(main
program) has load modules of all the subroutines.

As indicated earlier, the data passed in the calling program to subroutine
just before the call has valid numeric data. The corrupt data is present in
the begining of execution of subroutine.

The garbage data is not found for fields declared s9(09)v9(02),
garbage data is found for the fields declared s9(09)v9(02) comp-3
only.

the programs are compiled with COBOL370 - 24 bit.

Proc division using {variable names (01 level)}.

call 'pgm-name' using {variable names (01 level)}.

Linkage section consits the corresponding 01 levels.

Please let me know if exact code is required.

Sasi Kiran Patha · Posted: Wed Dec 12, 2007 6:58 pm

One more observation is that the copy book variables in the linkage section are passed correctly.

tangentray · Posted: Wed Dec 12, 2007 8:00 pm

could you please post the "call" statement and the "procedure division using" statement?

maybe you have the order of variables passed wrong by some chance?

dbzTHEdinosauer · Posted: Wed Dec 12, 2007 8:16 pm

maybe your archaic static link methodology has an older version of the CALLed module. Browse the load module to insure the correct version of the CALLed module has been bound. You can see the date; Browse the load module and do a FIND on the CALLed module name.

Sasi Kiran Patha · Posted: Wed Dec 12, 2007 8:24 pm

hi, the issue is resolved, solution looks strange ,,,

instead of declaring the numeric data to be passed to subroutines directly in working storage section,,, declared the numeric data in a copy book.
and then passed the copy book 01 level to the subroutine,,,

This was not the case in my previous shop...

Any gueses for this behaviour... ?

Douglas Wilder · Posted: Wed Dec 12, 2007 8:53 pm

I am glad you got it working. In order to know what was happening we would need to see the call statement and the definitions of the fields being passed (from the calling program) and the the linkage section and procedure statement (from the called program).

Craq Giegerich · Posted: Wed Dec 12, 2007 9:47 pm

dick scherrer · Posted: Thu Dec 13, 2007 1:58 am

Hello,

If the calling program has a field defined zoned-decmal and the called module has the "same" field defined as packed-decimal, it will "always" abend. . .

If you changed both sets of code to use the same copybook, you eliminated the mis-match.

Sasi Kiran Patha · Posted: Fri Dec 14, 2007 10:44 am

hi all,

Mr. dick scherrer,

I checked for variable name mismatch and data type mismatch.
There was no mismatch.

Mr. Craq Giegerich,

I have viewed the comp-3 variables' values in xpeditor.

Mr. Douglas Wilder,

Linkage is a bit long... but i will post it in next reply.

dick scherrer · Posted: Fri Dec 14, 2007 8:30 pm

Hello,

When you moved the data elements to the 01, they would become aligned differently. I don't recall an alignment requirement for comp-3 fields, but memory fades. . .

It has been quite a while since i've seen code that didn't use one or more level-01s when issuing the call.

mmwife · Super Moderator Joined: 30 May 2003 Posts: 1592

Hi Sasi,

What are the Hex values of the "garbage" data you're receiving
(e.g. X'3C000467')? Sometimes it's shown as: