"COBOL400-L" <cobol400-l-bounces@xxxxxxxxxxxx> wrote on 07/19/2016
01:00:05 PM:
----- Message from "Stone, Joel" <Joel.Stone@xxxxxxxxxx> on Mon, 18
Jul 2016 20:04:36 +0000 -----

To:

"'COBOL Programming on the IBM i (AS/400 and iSeries)'" <cobol400-
l@xxxxxxxxxxxx>

Subject:

[COBOL400-L] what is a common and quality method of adding a record
to a file with "L" date data type fields?

Is writing a date value of 01/01/0001 a good idea?

Or is setting field to null work better?



When using alpha fields in the past, many folks would code to put
'00000000' in any alpha or numeric date field that was undefined.
What is a good approach for iseries date fields on add?

I've done it both ways. One point to understand is that you will have to
set the date to '01/01/0001' even if you use null values when using native
COBOL WRITE or REWRITE statements. (I'll simply refer to them as WRITE
statements from here on out.) The database will validate the value of the
field even when the value is set to null in the null-map. I don't believe
this is a requirement when using SQL.

In general I've found that coding for the null values more effort than the
payback is worth--at least with native COBOL access. This is true because
you have to set the value to '01/01/0001' before writing the record and
then set null flag in the null-map. When reading you will check for the
null-value or for the '01/01/0001'--so you have to write code to handle it
either way. Using SQL to insert and select/fetch the records is a little
easier, but there's still coding required.

I love the basic idea of using a null value for a date field/column that
cannot be determined, but as the expression goes: "The devil is in the
details." In this case, it's the implementation details.

Michael Quigley
Computer Services
The Way International
www.TheWay.org

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 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.