🚀 go-pugleaf

   Can anyone please explain how the Y2K problem happened to me?  Back in
1984 a tiny little known computer company decided to make all of their
products recognise the year 2000 properly.  If you have one of their
computers on your desk from 15 years ago your computer is Y2K compliant. 
Last year Microsoft released Windows 98 which shipped with, "minor issues"
concerning the year 2000.  If I buy a brand new computer that comes
pre-loaded with Win 98 today I have to download a patch from MS's web site
in order to make the OS Y2K compliant.  And yet, if I have the original
Macintosh from 1984 I can keep going until the year 2019 before I'll have
any problems with dates.

   Someone explain to me why anyone is still migrating from any other OS
to Windows with the well known Y2K issues in Windows that still aren't
100% fixed.  I can't explain it for the life of me.

In article <FUJn2.83911$c8.40687293@hme2.newscontent-01.sprint.ca>,
rslade@sprint.ca (Rob Slade, doting grandpa of Ryan and Trevor) wrote:

>BKY2KNSH.RVW   981030
>
>"Year 2000 in a Nutshell", Norman Shakespeare, 1998, 1-56592-421-5,
>U$19.95/C$29.95
>%A   Norman Shakespeare
>%C   103 Morris Street, Suite A, Sebastopol, CA   95472
>%D   1998
>%G   1-56592-421-5
>%I   O'Reilly & Associates, Inc.
>%O   U$19.95/C$29.95 800-998-9938 707-829-0515 nuts@ora.com
>%P   336 p.
>%T   "Year 2000 in a Nutshell: A Desktop Quick Reference"
>
>*Can* the Year 2000 problem be put in a nutshell?  (Please?)
>
>And isn't it just a tad late to be starting this?  (On the other hand,
>Nutshell books *are* generally worth waiting for.)
>
>Part one is a general overview of the situation.  Chapter one starts
>with a rather exaggerated doomsday scenario, including concerns that
>have already been seen, and thus have been addressed.  At the same
>time, it ignores the "upstream" multiplier effect of supplier and
>infrastructure failures.  However, it does go on to note needs and
>concerns for management of the potential failures.  Management and
>budgeting considerations are expanded in chapter two.  Legal questions
>are addressed in chapter three, in a somewhat generic fashion.  Some
>standard planning models and assumptions are given in chapter four.  A
>little technical information in chapter five may help with
>calculations for dates and windowing or packing solutions.  Chapter
>six looks at the desktop PC; which is interesting in view of a very
>heavy COBOL and IBM mainframe and mid-range emphasis elsewhere (as
>well as a few PC related goofs in the doomsday scenario). 
>Unfortunately, some of the information is missing and some is wrong in
>regard to the desktop.  There is no mention of a "cold rollover" test
>for the CMOS/system date, and the statement about Excel's date
>interpretation is incorrect.  (I have confirmed this in my own
>testing.)  On the other hand, the warning about internally developed
>applications is quite important.
>
>Part two provides some forms and checklists to help organize a Year
>2000 project, including triage, inventory, and a project template. 
>There are about a hundred pages of COBOL references and tutorial in
>part three.  Date functions get extensive listings in part four with
>attention to general types, COBOL, PL/1, MVS LE, Visual Basic, and C. 
>There is a conceptual look at code scanners in chapters eighteen and
>nineteen.  An appendix lists Web sites for Y2K vendors, tools, and
>other resources.
>
>Was it worth waiting for this?  I'm not sure.  There is little wrong
>with the information, but neither is this a cut and dried quick fix
>that you might expect from the Nutshell series.  An unrealistic
>expectation in the case of the disaster of the century, admittedly,
>but there you are.  Still, with the big iron emphasis, and the big
>project orientation, the material is this work seems to be coming
>later than it would have been necessary to start these kinds of
>projects.  There is relatively little in the volume for small
>businesses depending upon desktop machines, and almost nothing on
>fallback plans for non-compliance in the supply chain.  The material
>is fine as far as it goes, but it doesn't go as far as it needs to at
>this late date.
>
>On the other hand, it's no worse than any of the others.
>
>copyright Robert M. Slade, 1998   BKY2KNSH.RVW   981030
>
>-- 
>======================
>rslade@vcn.bc.ca  rslade@sprint.ca  robertslade@usa.net  p1@canada.com
>Subscribe to techbooks mailing list at techbooks-subscribe@egroups.com
>       or via the Web at http://www.eGroups.com/list/techbooks/
>Robert Slade's Guide to Computer Viruses, 0-387-94663-2 (800-SPRINGER)