Representation of Integers
When processing in a z/OS environment, you should also be aware of the way that SAS stores integers. Like other numeric values, SAS maintains integer variables in 8-byte floating-point (real binary) representation. But under z/OS, outside of SAS, integer values are typically represented as 4-byte (fixed point) binary values using two's complement notation. SAS can read and write these values using informats and formats, but it does not process them internally in this form. SAS uses floating-point representation internally.

and further under SAS document TS-654 Numeric Precision 101

Quote:

72,057,594,037,927,936

is the largest value that can be stored exactly in SAS on a mainframe (the Unix and PC values are smaller). Your data is losing precision and you have several choices:
1) do not use numeric variables for your data
2) split the 18-digit packed decimal values into smaller values
3) accept that you cannot get precise values using SAS for your particular data and live with your results.

Thank you Robert. These values and copybook is extracted through UNLOAD utility from DB2, do some modification through SAS and then we load it back to the database through LOAD utility. Since this field is untouched in the SAS process we require the same value to be carried out while loading back to the database. Thanks for the insight!

Is there any alternate solution available in SAS like converting into some format while reading and reformatting it to its original value later? I tried splitting the variable into two but it didn’t work out.

It doesn't matter what it is really called, it was probably a poor move to PACK it in the first place. You are not doing calculations with it, so, even if its content is numeric, it does not have to be defined as a numeric field.

Bill: SAS numeric variables have a maximum of 8 bytes and hence the value I quoted before is the absolute largest numeric value that can be precisely stored. I haven't looked yet to see if the newer z machines support 16-byte floating point values; even if they do, SAS has not yet been updated to allow them.

Suceender: use $CHAR10. in SAS to read the value. As long as you do not need the numeric value for anything, this will preserve the exact data in the field and DB2 should handle the data fine. You could read the data as

Code:

@064 I_CUST1 PK5.
@069 I_CUST2 PD5.

which would give you two variables that, together, can precisely represent the original value. Note the difference between PK and PD informats!

Side note: your COBOL declaration S9(18)V places the decimal point after the last digit (the V is optional in this case, by the way) whereas your SAS statement S370PD10.1 is placing the decimal point before the last digit. For the purposes of your original problem, not an issue -- but something to be aware of going forward.

Thanks for the detailed explanation. I used $CHAR10 and it worked fine. However when I used PK5 and PD5 split up the precise is maintained but the first 9 character has some other value. Please see the example below. Unless I use this field for computation I am fine with CHAR representation.