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 : Zitel-ZITL What's Happening

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Warren Gates who wrote (190)10/20/1996 1:09:00 PM
From: Craig Richards   of 18263
 
Warren,
Thanks for all your informative posts on this thread. In reading the information, this section caught my eye:
>MatriDigm's year 2000 solution provides a 2-byte representation of
> a 4-digit date field
>(1) that enable both converted and non-converted applications
>and data files to coexist
>in the same production environment. Additionally, most existing
>data files and JCL do
>not require any conversion.

I don't know anything about COBOL, but it sounds like they're taking a 2 byte ASCII field (or would COBOL store it as 2 hex digits?), and converting it into a 16 bit value. This way, if a date field is above the value 0x3030, it must be an old style 1900's date, otherwise the year would be stored as a 16 bit value (i.e. 2000 would be stored as 0x7d0). This means there would be no conversion of data files necessary. Is this how other y2k conversions are being done? If not, do you think that this approach provides value compared to other approaches?

It's possible that this is the part that they're trying to patent. (In fact, I think that's what the "(1)" in the text indicates).
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext