Actually it is the DDS and some UI & HLL which are the really strange beasts with regard to integer\binary; i.e. for honoring the DDS specifications, only up to the precision supporting all digits as decimal nine, such as supporting only 9999 versus 32767 for the 2-byte integer.

The database actually treats the fields as signed integers, fully supporting the largest of both the negative and positive values when defined with a zero scale. Although assigning non-zero as the "decimal positions" [or scale] causes the database to limit the maximum neg & pos values, the value is still stored as hex\binary representation of the inserted #-byte integer. The oddity of the ability to assign scale was not carried forward as a feature of the newer 8-byte integer\binary type. Use the SQL to perform the I\O to confirm that the database honors the true integer values for fields with zero scale, not some utility like UPDDTA or language like CL. The following request will insert the numeric value of 32,767 with hex value 7FFF into the buffer representing column TID:

INSERT INTO TheFile (TID) VALUES(decimal(2**15-1, 5))

Note: although the database should support the largest value on the 8-byte integer, on a v5r3 system I was only able to insert up to the value of 2**63-513 versus the expected 2**63-1. FWiW I seem to recall that I found and reported that same issue ages ago, and that there was a fix for it. So I think the system I used is just missing a PTF.

Regards, Chuck

Simon Coulter wrote:

On 11/02/2010, at 7:55 AM, Lim Hock-Chai wrote:

A PHN_OR_PIN 10B 0
A TID 2B 0

Database Binary fields are a strange beast. They are not Integers
and they can contain decimal positions. The allocated storage is
a function of the number of digits and they don't support the full (expected) range of normal integers.

A Binary field with between 1 and 4 digits will occupy 2 bytes of
storage. Between 5 and 9 will occupy 4 bytes of storage, between
10 and 18 will occupy 8 bytes of storage.

TID is defined as 2 digits therefore it will occupy 2 bytes with a maximum value of 9,999

PHN_OR_PIN is defined as 10 digits therefore it will occupy 8 bytes with a maximum value of 999,999,999,999,999,999


This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].