× 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.



Kurt,

Remember that when you use binary even character values can be in the field. For example blanks (x' 40404040') shows as 077952576 when you display the field as an integer.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Wednesday, October 31, 2012 3:04 PM
To: Midrange Systems Technical Discussion
Subject: RE: Using the B data type in files

That's great to know. Thanks a lot, Chuck.

-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, October 31, 2012 4:31 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Using the B data type in files

On 31 Oct 2012 14:58, Anderson, Kurt wrote:
<<SNIP>>

I have approval to add 5 identifier columns. I was going to add them
as 9p00 (5 bytes) each. However, I could get the same values for less
space if I used the B data type (9b00), <<SNIP>>

In my 10+ years of RPG programming, I've never dealt with a B type on
a file (in fact, only ever in IBM supplied APIs, and even then I
converted them to integer types).

From the perspective of the database, the DDS data type "B" [9B00] is the same as the SQL INTEGER data type. The database treats them identically, even if some other interfaces [e.g. CL, Query/400, DDS, etc.] might limit the field to the 9-digit presentation; at least without doing something explicitly to override that effect. For example, in Query/400 the report writer allows overriding the 9-digit presentation to a 10-digit presentation; the same report writer, for the sake of the STRSQL, implicitly does that expansion because SQL's perception of INTEGER is incompatible with any 9-digit restriction.

The database SQL treats them [INTEGER and 9B00] identically also.
Either will be presented [from the SQL catalog information for columns, SYSCOLUMNS] as DATA_TYPE='INTEGER' of LENGTH=4 bytes of storage. AFaIK the DSPFFD still shows both as 9B00 [BINARY (9,0) 4-byte] for legacy reasons.

I did find that there is a EXTBININT header spec, but I don't really
see the purpose to using it (I mean I know you can then access the
10th digit, in the case of 9b00, but does that 10th digit get stored
on the file?

The database stores and retrieves the full signed [binary] integer.
The database will place or read the full four-byte buffer value for the SQL INTEGER or the DDS 9B00 data type, irrespective of what any particular interface to the database might have chosen to impose as a restriction. A possible restriction could be an overflow on read or write, diagnosed by the interface, not the database; the database will always accept any value because there is no possible invalid value.

Are there any gotchas to using the B data type?

There may be some interfaces that restrict access only to the 9-digit value; most probably just requiring some special action to ensure the full 10-digit numbers will be available. Any restrictions however are outside the database, as the database honors the full even-byte storage for any integer data-type value. If the 9-digits are all that will ever be required, as implied by the possible alternative\choice of the 9P00, then there should be nothing about the weirdness associated with 9-digit restrictions for use of 9B00 that could ever be a "gotcha" to give any concern.

The Packed Binary Coded Decimal data type does provide data validation, whereas INTEGER data can not [and therefore will not] be validated by the database. That capability may be valuable, or probably in the given scenario, just more of both storage and CPU costs.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

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.