On 16-Aug-2016 13:11 -0700, Stone, Joel wrote:
<<SNIP>> 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.
The DFT() of the Data Description Specifications (DDS), as the
Default Value (DFTVAL) for the field, indeed _is ignored_ for any field
in the buffer [a buffer as a reflection of the physical file Record
Format (RCDFMT)] for which a native\RLA *record-insert* occurs; the
buffer serves as, in effect, the record-image.
That is because, conspicuously, a value specified, is a value for
which a /default/ is not required. IOW, an explicit specification of a
value, conspicuously eliminates any requirement for an
implicit\defaulted assignment of a value. An effective /record-image/
that is described by the physical record format, implies that there was
a value supplied for each field of the physical format. There would
need to be a separate buffer [like the null-byte-map] that would need to
be passed as additional information to inform the database which fields
for which effectively /no-value/ had been passed, for which [effectively
the request being that] the database must supply a default or NULL value
for the logically missing\omitted [but for which there is a physically
present] value.
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.
A program variable is initialized according to what the HLL claims
[in the docs] will be done for initializations. Thus if COBOL claims
that numeric _variables_ [aka numeric data items] will be initialized to
zero [and presumably character strings to EBCDIC blanks], then that
should not be at all surprising; in fact, quite expected.
FWiW: In My Experience (IME), COBOL initializes all database /field/
declarative data-items to blanks, irrespective of their data-types; and
even standalone data items, declared as DATE FORMAT are initialized to
blanks. Maybe that is something I have done wrong in the [compiler
directive or source specifications of the] few COBOL programs I have
written, though the default option is *STDINZ for "Standard
Initializations ; IME, when I do not explicitly perform my own
initializations, numeric values and date values are 0x40s for all
data-items that were variables in my program per my having included them
via external DDS references :-(
However an implication that the COBOL would "properly initialize" a
numeric _field_ value "to zeroes" would also *explain exactly why* the
DFT() is not applicable. Notably, if the DDS explicitly had the DFT(-1)
specified for that numeric field, then the COBOL having /initialized/
the field to zero, instead of initialized to the value of negative-one
as requested\specified by the DDS, would be defeating the DFT()
specification; and that, just as I alluded, *is the effect*.
This will occur properly with both LF and PF WRITEs.
Perhaps those _data items_ are being "properly" initialized according
to the rules of the COBOL compiler and your specifications\directives to
the compiler, in that regard; but, again, I do not see /proper/
data-type initializations for the declaratives in the COBOL program for
data items derived from an external record format. Yet if such
initialization were in effect, then there should be no surprise that the
numeric values would be initialized to zeroes.
But to be clear, those are the _program variables_ that are being
initialized. And are variables that presumably will be used for storing
the data in a record-buffer that will be passed into the native I\O
request of "write" [aka insert or put]; and thus, again, actual values
would have been supplied, for which the database need not assign a
default-value.
Why does COBOL adhere to numeric constraints on a field during the
record add process, but ignores the DFT constraints?
The alluded /constraints/ are not met in my experience; again, I get
blanks for numeric variables.
The DFT is always /ignored/ for the data inserted via a physical
record format, as I suggest; because the presence of the field in the
record format implies data has been supplied for the "write" statement,
the database tries to use each datum corresponding to the respective
field in the buffer position, as the contiguous data that should be
inserted into the file as the row-data.
Just as COBOL assigns a /default/ value to both numeric and character
data items [aka variables], so too the COBOL presumably assigns a
default to a DATE data-typed data item. A default for a date variable,
just like a default for a numeric variable, is presumably going to be
the compiler default-values rather than the defaults from the DDS. And
in my experience, COBOL is /stupid/ in that regard, per initializing all
data-items as-generated from an included external format, with 0x40 as
EBCDIC blanks, irrespective the data types of the respective declarative.
So again, if having the DFT() value assigned to the physical field is
the desirable effect, then perform the I\O via a logical [file] record
format that omits that physical field.
Note: There could be a way for a HLL [such as COBOL or RPG] to define
a /logical/ record format that omits the physical fields, without the
specification\declaration of an actual LF record format, for which the
native DB2 would then be aware that the physical fields would require a
default to be assigned, but I am not aware of any language other than
the SQL that has that capability -- effectively, the ability to name
only those fields into which the supplied values will be inserted, so
omitted fields will get assigned their data-type or explicitly-defined
default.
midrange.com
