IWS - The Information Warfare Site
News Watch Make a  donation to IWS - The Information Warfare Site Use it for navigation in case java scripts are disabled



BKY2KPRS.RVW   971114

"The Year 2000 Problem Solver", Bryce Ragland, 1997, 0-07-052517-X,
U$29.95/C$43.95
%A   Bryce Ragland
%C   300 Water Street, Whitby, Ontario   L1N 9B6
%D   1997
%G   0-07-052517-X
%I   McGraw-Hill Ryerson/Osborne
%O   U$29.95/C$43.95 905-430-5000 800-565-5758 fax: 905-430-5020
%P   270
%T   "The Year 2000 Problem Solver"

In order to conserve memory or storage space, or simply for ease of
data entry, many programs have been coded to use only the last two
digits of the year when dealing with dates.  The year 2000 will see
the first time in the history of computers when the dates will cross
from one century into another.  Programs calculating time based on
only the two digit year field will give erroneous results, with
consequences of varying severity.

In its simplest form, that is the year 2000 problem.  (For many of the
same reasons that led to the problem in the first place, most techies
refer to it as Y2K.)  The year 2000 problem is not, actually, a single
problem, but a whole pile of related troubles, with results that are
unpredictable until you start examining them in detail.

Ragland's review of the situation covers a great deal of territory. 
He correctly presents Y2K as first and foremost a management issue. 
The technical work, while arduous and tedious, is not sophisticated. 
He notes that while the problem resides in programming, it will show
up mostly in data corruption.  The book looks at a number of both
common and unusual concerns, including the often cited case of bank
interest, and the less recognized use of December 31, 1999 in "keep
until" fields to mean "retain forever."

The book text actually comprises less than half of the pages in this
work.  The appendices are longer, most providing contact information
and brief annotations for configuration management tools, service
vendors, analysis tools, conversion tools, validation tools, and other
resources.

Ragland starts with a precis and some examples of the problem.  He
then looks at the corporate view, examining management, costs
(including legal), leap year, and data.  A five-step approach is
proposed to deal with Y2K, including awareness, assessment,
renovation, validation, and implementation.  (Readers may be forgiven
for thinking that this plan bears a striking resemblance to any
maintenance situation.)  Two chapters purport to cover the small
business and home office.

Ragland's background in military and government systems is clearly in
evidence.  Not only is there a definite emphasis on large systems, but
many non-governmental readers may be confused by the frequent use of
jargon such as COTS (Commercial Off The Shelf).  (Corporate readers
might best interpret this term as a reference to PCs, routers, or
other "shrink wrapped" items.)  While desktop workstations do get
mentioned, Ragland seems to see system software as the only potential
trouble spot.  Different sliding windows in applications software,
macros that may or may not use provided date functions, and even the
fact that many spreadsheets handle February 29th incorrectly in an
attempt to be "bug for bug" compatible with old versions of Lotus
1-2-3 are ignored.  Advice on dealing with PCs is simplistic almost to
the point of insult, and is no help to concerned users.

While coverage is broad, there are definite gaps.  This is the more
disappointing when you note how much material is repetitive or
redundant.  The organization of material is also sometimes confusing. 
Why, for example, does an anecdote pointing out the scope of the
problem come in chapter ten under the heading of "Validation," rather
than in the initial chapter with other examples, or in the chapters on
"Awareness" or "Assessment."  Many of the explanations and examples
could have been much clearer, and while the appendices are undoubtedly
valuable, the annotated descriptions of tools seldom provide a
thorough understanding of what the product can do for you.

(One suggestion that I must take exception to advises explaining Y2K
as a virus problem.  True, Ragland admits that the year 2000 problem
*isn't* a virus, but anyone who "understands" Y2K explained as a virus
really has no idea of either concept.)

This work does have serious drawbacks as a guide to dealing with the
year 2000 issue.  On the other hand, it has great value as a resource
both in explaining the situation to management, and in providing
contact information for tools and other sources of assistance.  Given
both the specialized nature and short duration of Y2K, it is
unrealistic to expect deathless technical prose, and this is
definitely "good enough."

copyright Robert M. Slade, 1997   BKY2KPRS.RVW   971114