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



On 02-Jul-2014 12:10 -0500, James H. H. Lampert wrote:
Had a weird experience at a customer installation. It seems that,
because some out-of-date software generated some incorrect DDS, we
had a source member with a field defined as:

A U07611 050S00

And it didn't blow up on compilation.

The integrated DB2 database [and SQL] was enhanced several releases ago to support up to a maximum of 63 digits of decimal precision. Unlike other data type enhancements that were made available only via\to the SQL, the DDS was enhanced to support the specification; DSPF, PRTF, PF, and LF.

<http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_53/rzakc/rzakcmst07.htm>
"What's New for V5R3 in the DDS for display files information

Technical updates to DDS for display files information:

Numerous minor technical updates were incorporated into the information.

Updated the information about zoned fields to show a new maximum length of 63 digits.
..."

A DSPPFM of the resulting file shows the field with 31 digits,
padded on the right with 19 spaces.

I suspect the origin of that is a side effect of the application performing the WRITE. The DSPPFM just shows the undescribed /record/ data, so what is in the field should be what was entered by the application. The journal should show the same.

FWiW: The default query, i.e. RUNQRY QRYFILE(the_lib/the_file), will show the described result; the data might appear as '+' plus symbols to indicate the data has errors.

I don't think I've ever seen anything like this before.

See also: Decimal result options (DECRESULT) for the Run SQL Statement (RUNSQLSTM) and similar specification on other SQL interfaces.

Note: Multiple times I have reported on these fora that the DB apparently had failed to properly enforce data integrity for the longer decimal values in the SQL TABLE; i.e. what is supposed to be in contrast to the DDS-defined database files for which no such integrity checks occur. Thus if the file in this scenario had been an SQL TABLE instead of a database file created with Create Physical File (CRTPF) form DDS, then the same issue whereby apparent blank-padding was the result of the application likely would have been possible even though the DB should have failed the WRITE due to a /data mapping error/. I have never seen any followup by anyone if any fix was ever pursued.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.