Re: DDS DFT for date field: does COBOL honor DFT value with initialize or WRITE verb?

Hi Chuck

Thanks for your detailed explanation.

Im not sure that it makes sense though. It sounds like you are stating that because COBOL loads an entire record into the buffer prior to WRITE-ing it, therefore the OS will ignore the DDS DFT constraints that established.

However, COBOL does honor various other requirements that are established in the DDS. For example if I have a numeric field described in DDS, then COBOL will properly initialize that to zeroes. This will occur properly with both LF and PF WRITEs.

Why does COBOL adhere to numeric constraints on a field during the record add process, but ignores the DFT constraints?

Thanks!

Joel

-----Original Message-----
From: COBOL400-L [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, August 16, 2016 12:17 PM
To: COBOL400-L@xxxxxxxxxxxx
Subject: Re: [COBOL400-L] DDS DFT for date field: does COBOL honor DFT value with initialize or WRITE verb?

On 16-Aug-2016 09:06 -0700, Stone, Joel wrote:

(COBOL ILE on v7r1)

I have the following DDS for a DB file:

CREATE_DT L DATFMT(*MDY) DATSEP('/')
DFT('01/01/01')

When I initialize the record and WRITE, I receive data mapping error
CPF5035: Data mapping error on member CSC_MST. With reason code 17:
17 -- The format of the data in a date, time, or timestamp field is
not valid.

From the above, it appears that COBOL does not honor the DFT value
keyword in DDS.

Is it possible to get this to function properly for an add record?

The issue is not the language, but the I\O being utilized; i.e.
physical /native/ [aka Record Level Access (RLA)]. That type of I\O
requires the complete\valid record buffer be provided. Use of SQL
allows naming the columns for which data will be provided.

Perform the I\O via a Logical File that omits the filed CREATE_DT,
and the database will implicitly assign the default-value according to
the DFTVAL specified. Note: '01/01/01' is 01-Jan-2001 per the 100-year
window required for a two-digit year, of 01-Jan-1940 to 31-Dec-2039.

Otherwise I am forced to initialize each field individually and if a
field gets added, there will be unnecessary debugging involved.

And it makes the code messier.

The beauty of designing\coding with /logical independence/ in effect,
whereby every program would perform I\O only via a static Record Format
(RCDFMT) of a Logical [File] view of the data, rather than the
potentially changing physical record layout. Such a program likely
would not need to be recompiled, such that the properly defined defaults
would have the DB generate the default value on the insert.