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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.