Re: 9/9/99

Buck,

There was another post about this thread that made some comment about
users finding their way around a problem.

I'm going to touch upon that post and yours and digress a bit, as I do
;-)

Here's a real world situation:

My company has several applications, of which inventory control and
purchasing are two of them.  The clients that have inventory control,
but do -not- have purchasing have been creative. As users can be <g>

The purchasing module updates a numeric, (not date data type field),
next receive date in the inventory balance file.  Now I'm talking
"legacy" (pre date data type) applications written this decade. Now
that's old! ;-}

The next receive date field in the inventory balance file is expected to
be populated from the purchasing module that does date validation.  But
the user discovered that if they use CHGDTA/DBU,etc. and key 11/11/11 to
indicate delivery within 1 week, 22/22/22, 33/33/33, etc. to mean
something else and so on.  They were happy campers.

Now, nothing is done with this date except to print or display for
informational purposes.  In other words, no code cares what the contents
is.

Is this a Y2K risk? Nope.  If you don't act upon a date field contents,
what does it matter what the contents is?  The purchasing module prints
expected deliveries by date (validated) from the real purchase orders.

But I agree with you, 090999 is not one that any of my many creative
geniuses have come up with. :-)

It doesn't have to be ported S/3x code to have "dates" that allow any
numeric value.  And even when date data types became available, lack of
display support and performance problems left many people in the learch.

So, what am I to do? Put a trigger on the item balance file and reject
the user's creative solution?  Force them to acquire the Purchasing
module? Continue to leave the field as an ignored numeric value and let
them stay "happy campers"?

I'm staying with the latter.

IMO, there are dates and there are dates that matter.  I wouldn't waste
the coding time on dates that don't matter.  And 9/09/99 is a new one on
me.  Well, let's see what happens in one week.  Head for the hills! <g>

But I do get a kick out of the early morning panic report (they call it
"news" around here) and have spewed my Wheaties on my
couch.davenport.sofa.cat for a good chuckle.  (we don't cotton to
chesterfields) <VBG>

Anyway, hope you all the other subscribers have a good weekend (get some
R'n'R while we can).



Buck Calabro wrote:
> 
> Jim,
> It's not inconceivable to imagine a shop with strict input data checking -
> one that allows only valid dates to be entered into the system.  It's not
> inconceivable to imagine that same shop using 090999 to mean "Permanent" or
> "end of time."  But imagine being the guy writing the code back in 1970.
> Would you have picked 090999 or 123199?
> 
> I've seen plenty of "special" date values in applications, but 090999 simply
> is not one I've come across.  I've heard about this 090999 "problem" for
> several years, but nobody who talks about it has been able to actually find
> a system that actually uses it.  This would pretty much be the definition of
> "urban legend."  Newsgroups are notorious for spreading urban legends...
>
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---