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