BKSY2KCR.RVW   990424

"Solving the Year 2000 Crisis", Patrick McDermott, 1998, 0-89006-725-2
%A   Patrick McDermott
%C   685 Canton St., Norwood, MA   02062
%D   1998
%G   0-89006-725-2
%I   Artech House/Horizon
%O   800-225-9977 fax: 617-769-6334 artech@artech-house.com
%P   310 p.
%T   "Solving the Year 2000 Crisis"

(Okay, it's late.  All I can say is, I just got it.)

Part one gives an outline of the problem itself.  Chapter one looks at
the various types of things that can go wrong.  This is reasonably
clear, although it could have had a few more examples.  There are a
number of factors that make the problem note quite as bad as some
suggest, and these are discussed in chapter two.  On the other hand,
chapter three points out why it is not going to be easy.  Chapter four
talks, rather briefly, about some of the disaster scenarios, and why
they won't happen.  Overall, the section is a very good explanation of
the technical aspects of the problem, but is weakened by ignoring the
cumulative affects of multiple failures in independent systems.

Part two examines solutions to the problem.  Chapter five looks
tersely at replacement of old systems.  Expansion of date fields is
discussed in chapter six.  Windowing, in chapter seven, is presented
as a quick but possibly dirty fix.  Chapter eight reviews the
possibility of compressing data in order to extend the life of the
program while maintaining existing data structures.  It is possible,
as chapter nine points out, that you can get away with not fixing Y2K
errors, since they can be worked around.  Special cases of windowing
(encapsulation) and replacement (abandonment) are reviewed
respectively in chapters ten and eleven.  The previous material having
looked at methods, chapter twelve discusses searching out the code
that needs to be addressed.  Chapter thirteen presents the need for
assessments and choices in finding a solution.

Part three looks at the people you will need.  Chapter fourteen talks
about issues of staffing.  Assuming you want someone else to do it for
you, chapter fifteen looks briefly at consultants and outsourcing. 
Tools that might help are reviewed in chapter sixteen.  Chapter
seventeen takes a stab at making a guess at roughing out how much this
is all going to cost you.

Part four looks at the Y2K fix project.  Chapter eighteen is an
excellent overview of the type of information you will need to plan
the project.  Decisions on what to fix and what to abandon are
discussed in chapter nineteen.  Using the fact that Y2K issues are
simple but pervasive, chapter twenty suggests a factory approach. 
Chapter twenty one is a quick guide to project planning.

Part five reviews business issues.  Chapter twenty two looks at the
aspects facing the small business, and the resources it has.  While
parts two to four generally apply to large systems, chapter twenty
three presents a quick check for PC and desktop use.  Points of
failure important to your business should be identified as suggested
by chapter twenty four.  Testing of your preparations is covered in
chapter twenty five.

Although the bulk of the book was written for those faced with the
technical task of correcting Y2K programming problems, the material is
very readable, and generally presents the issues briefly, but
reasonably.  In terms of presenting the problem, the book is on a par
with "The Year 2000 Software Problem" by Jones (cf. BKY2KSWP.RVW).

copyright Robert M. Slade, 1999   BKSY2KCR.RVW   990424