BKPM4Y2K.RVW   990218

"Practical Methods for Your Year 2000 Problem", Robert B. Chapman,
1998, 0-884777-52-X, U$55.00
%A   Robert B. Chapman bobchap@ibm.net
%C   32 Lafayette Place, Greenwich, CT   06830
%D   1998
%G   0-884777-52-X
%I   Manning Publications Co.
%O   U$55.00 hetr@manning.com 516-887-9747 http://www.manning.com
%P   217 p. + CD-ROM
%T   "Practical Methods for Your Year 2000 Problem"

Some points seem to be made pretty clearly in the preface.  First, the
author does not get bogged down in details.  (The first paragraph
tells us that the phrase "Year 2000 Ready" has been officially defined
by IBM, but doesn't tell us what the definition is.)  Second, the
content of the book will be directed at managers of MVS systems, and
will push some specific IBM products.  Third, the book just might have
some ideas about how to keep general project costs under control, even
in an emergency.  Fourth, Bob Chapman has seen the hysteria, and is
wryly unimpressed with all the running in circles.

Part one looks at the basic concepts that Chapman will look at in
greater detail later in the book.  Chapter one claims to be a brief
look at the Y2K problem, but, even allowing for brevity, it doesn't do
much more than say that there is a problem, and take a couple of
potshots at DEC and UNIX.  Recommended rules for keeping the cost
down, and the scope of the project contained, are given in chapter
two.  Some are very apt, such as the suggestion to stick to the
immediate problem, and not try to upgrade your entire application base
on the coattails of the Y2K effort, as is being promoted by a number
of consultants.  Other advice, such as replacing all "obsolete"
languages with COBOL, might raise a few eyebrows.  (Fair's fair,
though: the language-of-the-month-club who dismiss COBOL tend to
ignore the facts that it still works, and is understood by a larger
number of people than "trendy" systems.)  Some of the content is of
the valid-but-not-terribly-helpful variety, as is much of the
scheduling "guidance" in chapter three.

Part two looks at what is probably the most important part of the
endeavour, the evaluation of the task.  Although chapter four mentions
smaller systems (twice, actually, since an error has duplicated the
two paragraphs), the real emphasis is on mainframes, and source code
inventory tools from IBM.  Chapter five explains the categories of
dates much better than was done in chapter two, and also, very
importantly, defines categories separately for programs, files, and
user interfaces.  The discussion of techniques for fixing dates
problems varies between the very generic and the code specific in
chapter six.  Chapter seven assumes that COBOL source code is
available for all programs, so assessment may be just a bit
problematic for those who don't fit this narrow definition.

Part three gets more deeply into the actual process of recovery. 
Chapter eight passes too quickly over the development of test scripts,
although the advice on types of testing needed with different
categories of issues can be valuable.  Test hardware environment
options are reviewed in chapter nine.  Specific COBOL code for
category 2 problems is given in chapter nine, but not much else. 
Chapter eleven presents some interesting, and counterintuitive,
aspects of testing modified programs.  The actual implementation, in
chapter twelve, is dismissed rather tersely.

The quality of the material varies enormously.  Some points are
excellent, and valuable regardless of system; some will be useful only
to those in a specific environment (and I don't just mean IBM); and
some will be of only questionable value regardless of audience.  The
system bashing that goes on is fully equal to that of any Mac or
Microsoft groupie, and every bit as simplistic, annoying, and
unhelpful.  Religious pronouncements about the superiority of COBOL or
IBM products may very well be true, but are not validated in the book. 
Workstations are dismissed with the blanket condemnation that they are
all going to completely fail, so why even try.

I really don't know whether I can recommend this text or not.  Even
within its field, it is too narrowly focussed for those who work in
real offices and companies.  On the other hand, there are a number of
good points, some of them great.  A number of points and suggestions
are not covered in any of the other Y2K books I have reviewed.  If you
can afford to look at another book, it is short and interesting enough
to be instructive, although possibly also offensive.

copyright Robert M. Slade, 1999   BKPM4Y2K.RVW   990218