SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Discuss Year 2000 Issues

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: C.K. Houston who wrote (2334)8/1/1998 11:09:00 AM
From: John Mansfield  Read Replies (1) of 9818
 
Some examples - Cory Hamasaki:

'..... Listen Jack, paul, who is not a programmer, knows that all those things
have nothing to do with bank processing... large scale, heavy-duty bank
processing. Bank processing has to do with date-time stamping
transactions, sorting them, posting them, and applying complex business
rules.

Amortization, while too hard to do with a 4 function calculator, is a
couple lines of code when you have a y to the x function. Don't drag
that into Y2K.

Do you understand that older versions of CICS will loop on startup in a
future date? They're still discussing that in the mainframe discussion
groups. What's the significance of that?

Upgrading software like CICS is a chore, especially if you have to
upgrade other products and applications code too.

> > MY CONCLUSIONS

Here's an exercise for you, jack. Consider the expiration date on
credit cards. These dates are not supposed to be validated by point of
sale terminals... and if they are, you'd think that the POS programmers
would code the edits to accept 98, 99, 00, 01, 02, etc. If they
rejected any dates, it would be dates like 57, 67, 77, 0A, AZ, ... but
no, not only did they reject 00, 01, 02, but more than one programmer
made that same mistake. In fact, it seems that dozens or hundreds of
programmers made that mistake.

1. They edited a field that shouldn't have been subject to an edit.

2. They used the wrong criteria.

3. More than one did that.

This is a problem that should not have happened. SHOULD NOT HAVE
HAPPENED. <---<<<< say this 100 times.

Now you're ready for the real thinking... Of all the systems out there,
the ones that are supposed to work with dates, how many have a similar
flaw, simply that they reject 00 as an invalid date?

We, society, have spent almost a year looking for these 00 POS machines
and they should be apparent. The error is right at the user interface.

What about all the hidden systems where the action is to neglect to add
your deposit to your checking account... but it's happening during the
midnight run and no one sees the reject take place... because it's never
happened before. Neglect to post your bill payment too.

And I'm just discussing the systems that have a flaw in the edit.

There's more....

Sorting... there will be more of those.... did the deposit take place
before or after the payment due date? If not, slap a fine on the
account.

Computation... what is the number of days that the account had over
1,000 dollars? Too few? No interest for you. There will be hundreds
of thousands, millions of these problems.

All these things have to be checked and rechecked.
....

___

From:
kiyoinc@ibm.XOUT.net (cory hamasaki)
0:23

Subject:
Re: The Problem with the Y2K Problem
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext