# Re: This was weird: DDS definition for a 50-digit zoned field didn't blow up

     Subject: Re: This was weird: DDS definition for a 50-digit zoned field didn't blow up From: CRPence Date: Wed, 02 Jul 2014 12:54:29 -0500 List-archive: List-help: List-id: Midrange Systems Technical Discussion List-post: List-subscribe: , List-unsubscribe: , fixed

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.