Problem while reading packed decimal

vin12pr · New User Joined: 14 Jun 2006 Posts: 56

Hi All,

I have a table for which key is state-code + target number.

Whats happening is state code is getting populated properly and I am populating the target number by moving 916 to it.

TArget number declaration is PIC S9(3) COMP-3

SOmehow i have no idea why 916 is getting stored properly.Its getting stored as 916F and ultinmately getting abended with an error in table read

Another thing what i noticed is When i move 018 to TArget number ,its getting stored properly.

Kindly advise as to what needs to be done in this regard?

vin12pr · New User Joined: 14 Jun 2006 Posts: 56

one small correction : 916 is not getting stored properly..I appolgize.

William Thompson · Posted: Fri Mar 30, 2007 1:18 pm

X'916F' is correct for packed decimal though X'916C' would be better.
What does the 018 look like when you say it is correct?
What kind of abend do you get when you read the table?

vin12pr · New User Joined: 14 Jun 2006 Posts: 56

It looks like '018C'

vin12pr · New User Joined: 14 Jun 2006 Posts: 56

Here Table refers to a VSAM file which is used in CICS.Its not a DB2 table.I am getting the error "Key not found " error.

William Thompson · Posted: Fri Mar 30, 2007 2:33 pm

That is why it is not wise to use packed decimal as part of a vsam key. Vsam does not see the key as packed decimal, but just a binary string and though the sign C and F are the same, they are different.
If you need the C then make COBOL insure it is there. With TArget defined as S9(3), something like COMPUTE TArget = 916 should force COBOL to insure the sign is as needed. Maybe just MOVE +916 might work, a little experimentation and a look at the generated code can give you a sure way.

Phrzby Phil · Posted: Fri Mar 30, 2007 6:19 pm

Technically, C and F are not the same.

C means positive; F means unsigned (and D means negative).

If you have S9(3) COMP-3, I have no idea why moving 916 would not give you x'916F'. Can you show us a hex screen print?

My testing shows, as expected, both MOVE and COMPUTE populate the rightmost nibble with 'C'.

Phrzby Phil · Posted: Fri Mar 30, 2007 6:20 pm

CORRECTION:

I mean "... would not give you x'916C'".

Sorry.

socker_dad · Posted: Fri Mar 30, 2007 10:49 pm

Since the field is defined as signed, wouldn't you want to move +916 to it?

dick scherrer · Posted: Sat Mar 31, 2007 12:26 am

Hello,

As pointed out earlier - it is not a good idea to define signed packed numbers as keys. . . .

Imagine the support nightmare when the file has the same key with both the "C" sign and the "F" sign and it was intentional - to satisfy the imaginization of a "way too clever" coder. . .

vin12pr · New User Joined: 14 Jun 2006 Posts: 56

Well Guys..Thnx a lot for your replies...the problem was due to the fact that here the table gets modified every 15 days.

916 target number data was included in the table in march 2007 and while creating the policy in CICS i was using the policy effective date as 021207.Since while reading the table,the effective date of policy is also taken in to consideration & Since my policy creation date was < then table modification date,My read of the table was unsuccesfulll..

Thanks,
VIn12pr

Phrzby Phil · Posted: Mon Apr 02, 2007 5:43 pm

If the target field is defined as signed, you need not move +916 to it. Moving 916 suffices, as COBOL (and I hope any language) will store the target field as defined.