Prev: Having trouble declaring/fetching in Pro*Cobol
Next: solutions manual for Fundamentals of Corporate Finance 9th edition by Ross
From: Anonymous on 17 Mar 2010 08:00
In article <462a76d4-9d56-4220-9c93-88293560d161(a)z1g2000prc.googlegroups.com>,
Rene_Surop <infodynamics_ph(a)yahoo.com> wrote:
>Doc/Pete,
>
>Several datestamp fields are in a single table so it's kind of
>annoying looking at them in NULL value.

That didn't seem to be a difficulty for the person who wrote the specs for
the DBA who CREATEd the table... then again, that person probably never
looked at the data after a few years' work had been added.

>Converting these NULL
>datestamp value into a 'new' table (using Cobol program conversion) is
>a very long process and needs to be re-checked everytime, or else the
>INSERT command into the new table will fail.

It sounds like the old table allowed for NULLs while the 'new' ('
original) does not. If this is the case then it might be wise to ask
around what value is to be used as a default when a date-column no longer
allows for NULLs, eg 'In the Old Way this date was allowed to be blank but
in the New Way there has to be a value of some kind. What do you think
would be a good way to indicate to the user that the date did not come
from the Old Way but was made up when the rules changed?'

(it might be wise to respond to the inevitable 'Well, what do *you*
think?' with 'I think we should ask the users what they think, tally the
results and proceed from there'; since this requires that someone actually
Do Some Work it is not likely to be implemented)

Depending on the kind of data I've seen dates like 01 Jan 1900 (with time
of 00:00:00) or 4 Jul 1776 or 15 Oct 1582. If the column-definition is
being changed from allowing NULLs to not allowing them it might be wise to
examine, carefully, any program which uses that table in order to see how
it deals with a NULL date.

DD

From: Alistair on 17 Mar 2010 13:37
On Mar 17, 4:14 am, "Pete Dashwood"
<dashw...(a)removethis.enternet.co.nz> wrote:
> Rene_Surop wrote:
> > Doc/Pete,
>
> > Several datestamp fields are in a single table so it's kind of
> > annoying looking at them in NULL value.
>
> Some RDBMS only allow ONE Date/TimeStamp column per row. (It's because some
> systems update this field automatically and there is no point in having more
> than one of them. Different systems implement the content of this field
> differently, too; it can be a  sequential number or it can be a real time.)
>
> About 6 years back when I first started looking at Migration of COBOL I
> realised that COBOL doesn't implement a DATETIME data type and this could be
> problematic. I discussed it with the potential clients and asked them what
> would be better than NULLs in a date field, to indicate it was not in use..
> This discussion went on for some weeks with some very good points being
> considered. We all agreed that the RDB required a date and we should ensure
> it got one (NOBODY wanted NULLs for very much the same reason you outlined
> above), but the question was: WHAT date?
>
> If you use a future date it is risky. If you use January 1st 1900 there is a
> risk that some applications will convert it to 2000, and so on.
>
> In the end, we decided on 08/08/1988, although not everyone was happy with
> this, as some had records going back that far. At least if it is consistent,
> it is pretty easy to change it to some other base for a given installation,
> or even to make it null, if somebody really wants that.
>
> Today the Toolset has date detection tools built into it and it uses
> heuristics to decide if a COBOL definition is actually a date. It generates
> DDL with dates supported as DATETIME types. The DAL objects contain date
> filters that ensure that only valid dates can arrive on the DB and they are
> converted back to date strings for the COBOL Host Variables in ESQL.
>
> The general rules have evolved to be:
>
> 1. USE date types on the Database. (I tried not doing this for a while,
> figuring it works for COBOL, but I seriously regretted it. The richness of
> SQL date functions is not to be sniffed at ... have a look at this:http://www.sqlusa.com/bestpractices/datetimeconversion/) Doing this in
> COBOL is just pointless; it is like re-inventing a cart wheel only to find
> that there are already  mag radials available...
>
> Given that dates and the handling of them are a large part of most
> information systems, it is only to be expected that the World has met the
> need. I spent a lot of time over decades writing date routines that today
> are really unnecessary; nowadays I simply use what's there. There is huge
> support for everything, including automatic conversion to other languages..
>
> 2. Ensure your database date fields have valid dates in them, rather than
> NULLs. (This one is very arguable, some people feel strongly in favour of
> NULLs)
>
> 3. DECIDE on a date that will be used to indicate "not in use".
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."

I take exception to their descriptions of English and British English:

/*

name alias dateformat

us_english English mdy
Deutsch German dmy
Français French dmy
Dansk Danish dmy
Español Spanish dmy
Italiano Italian dmy
Nederlands Dutch dmy
Suomi Finnish dmy
Svenska Swedish ymd
magyar Hungarian ymd
British British English dmy
Arabic Arabic dmy

*/


That should be English and US English.
First  |  Prev  | 
Pages: 1 2
Prev: Having trouble declaring/fetching in Pro*Cobol
Next: solutions manual for Fundamentals of Corporate Finance 9th edition by Ross