topic Re: Issue with larghe PD fields in SAS Programming

Issue with larghe PD fields

JohnDawson — Mon, 27 Feb 2017 17:19:29 GMT

I have defined an input field on my input file in SAS as @243 TIER4MAX PD9.3 This field was created by a COBOL modules that had a PIC clause as PIC S9(13)V999 COMP-3. The SAS module simply read in the data and put it into a SAS dataset with no manipulation. The input value looked like this:

rrrrrrrærrrrrrrræ rrræ rrrrrrrærrrrrrrrærrrræ
0999999999999999990999909999999999999999999999
99999999C99999999C9999C99999999C99999999C9999C

We use SAS V9.4

When I run the SAS code my output looks like this:

rrrrrrrðrrrrrrrræ rrræ rrrrrrrðrrrrrrrrærrrræ
0999999989999999990999909999999899999999999999
99999999C99999999C9999C99999999C99999999C9999C

Notice that first and fourth field had the last byte changed from Hex '9C' to Hex '8C' . Fields 1, 2, 4 & 5 are defined as PD9.3 while fields 3 & 6 are defined as PD5.3. Fields that are defined with PD9.3 and contained all 9's stayed the same, but the fields that contained all 9's except for the left most bit had the bit before the sign changed to Hex '8C'. Field 3 contained Hex ;099999999C and it stayed the same on the output.

So does anyone know why Hex '9C' was replaced with Hex '8C' on the 2 larger fileds, and how can this conversion be prevented.

Re: Issue with larghe PD fields

mkeintz — Mon, 27 Feb 2017 17:29:29 GMT

How are you producing the hexadecimal output content?

If you just issue something a statement like "put tiermax=best32.6", do you see the intended value?

Re: Issue with larghe PD fields

art297 — Mon, 27 Feb 2017 17:36:52 GMT

Have you tried with a different informat? Different ones have to be used if you're inputing a file from a different operating system. See: http://support.sas.com/kb/56/654.html

Art, CEO, AnalystFinder.com

Re: Issue with larghe PD fields

Kurt_Bremser — Mon, 27 Feb 2017 17:55:55 GMT

Packed decimal with a length of 9 has 17 decimal digits. That are more digits than can be stored in 8-byte real format with reliable precision.

See http://support.sas.com/documentation/cdl/en/lrcon/69852/HTML/default/viewer.htm#p0ji1unv6thm0dn1gp4t01a1u0g6.htm for details.

Re: Issue with larghe PD fields

JohnDawson — Mon, 27 Feb 2017 18:54:01 GMT

When I changed the format on the put statement from @243 TIER4MAX PD9.3 to @243 TIER4MAX best32.6 it changed the outout to spaces, so that didn't work

Re: Issue with larghe PD fields

JohnDawson — Mon, 27 Feb 2017 19:25:25 GMT

OK, so it looks like I'm out of luck due to a restriction in SAS. Is that correct?

Re: Issue with larghe PD fields

Kurt_Bremser — Mon, 27 Feb 2017 19:30:30 GMT

When all possible digits are used, you will have an inaccuracy in the last digit. With 3 digits after the decimal point, this happens in the 1/1000 range. Which values do you have that need total accuracy down there?

Re: Issue with larghe PD fields

JohnDawson — Mon, 27 Feb 2017 19:49:38 GMT

These fields are defined in COBOL as PIC S9(13)V999 and the maximum number I could have in this field would be 9999999999999.999 and in hex it looks like this:

099999999
99999999C

and it gets converted to this:

099999998
99999999C

I do manipulate other fields to get my desired results, and then I use this file and compare it to my input file to get a file of differences and these fields that are getting the left most byte converted to Hex '8C' from hex '9C' are throwing a monkey wrench into that process because they shouldn't be different.

So it's not really the accuacy issue, it'd a matter of the contents of the input files has been altered in the outout file that's causing the grief. One good thing is that I can edit the output file after I run my SAS job to change all occuances of Hex '8C' to Hex '9C' and I should be fine to run the compare. I just wanted to know why and could I do something to avoid getting this result.

Re: Issue with larghe PD fields

Kurt_Bremser — Mon, 27 Feb 2017 20:06:55 GMT

The accuracy problem will only appear with sufficiently large numbers. Run a proc means on real data to get the maximum number that actually appears in the data.