×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.