Re: Y2K

["Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Dennis" == Dennis M Smith <dennis_m_smith1@juno.com> writes:
    Dennis> Thank you Glenn.  I finally heard someone on all these lists,
    Dennis> I've been on, actually come up with the facts.  I been working in
    Dennis> Computers since 1978 as a Operator and programmer and went
    Dennis> through the same things.  The only time we bought more disk space
    Dennis> was so the client could kept more information online not to
    Dennis> increase the date fields.

    >> important commercial and governmental data in the 40s and 50s was
    >> managed on punched cards with 80 characters of storage.  With this
    >> extremely limited memory for a commercial or governmental

  If storage was the primary concern, then the date should have been
stored in binary. 2 bytes of year is worth 64k numbers. 6 digits of
day/month/year plus 6 digits of hour,minute,second would fit into 4
bytes if the Unix encoding was used.

  So, I claim it wasn't "space" that constrained the problem, but
rather imagination. The systems were simply *NOT* engineered to last.

  Why would any hardware or software vendor install a system that
meant that the next upgrade would be unnecessary. It is *HERE* that
the monetary issue arises.

    >> By the time there was some awareness of the Y2K issue in the late 70s,
    >> the birth defect was pervasive.  Any new systems (PCs and
    >> minicomputers) that connected to these systems shared this inhereted
    >> fault to some degree and here we are.

  Neither VMS nor Unix nor Multics have a Y2K problem. Applications
might, but as was pointed out, these were simply retained rather than
maintained.

    >> I managed dozens of programming projects and never had a programmer
    >> advocate 2 digit year fields for efficiency.  They usually complained
    >> about having to maintain compatibility with customers' legacy data.

  If you put a "century" field in a second, parallel table, then you
solve the problem and you retain backwards comptability, *AND* you
give yourself room to grow while maintaining backwards compatibility.

  The problem of not maintaining software, equipment, environment,
public health, capital infrastructure is what we are dealing with.

   :!mcr!:            |  Network and security consulting/contract programming
   Michael Richardson |         Firewalls, TCP/IP and Unix administration
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
 Corporate: http://www.sandelman.ottawa.on.ca/SSW/
	ON HUMILITY: To err is human, to moo bovine.




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNnRhKdiXVu0RiA21AQEwNQL8C94JU6VqBHPqphHcMRM4LYPX4vJzJVPY
Toj9COBWlSv4KCwWPorWKOJa4jRI+QT7sr6hDlLocWh6gvCFCJPQAPOBajOfdFhU
B+cizsg0nkYzT0Ht4SVcpYNCyO76xrII
=oydL
-----END PGP SIGNATURE-----