Hi all,
For anyone else who's waiting until the last minute to finish their Y2K
project, here's a report on a little-used remediation technique (one
that, so far as I know, is not patented).
We still have a classic HP3000 that's been doing our accounting for
almost 13 years (it'll be 13 years in February). The accounting software
-- Multiview version 5.01G -- isn't Y2K compliant. This is a bit
irritating, since the database *is* Y2K compliant, but the Quick-based
input screens are not.
In any case, the choice was to spend $5,000 on new software, plus a week
or so of my time to convert all our data, or find something else to do. I
elected to try time-warping the machine back to 1971, the most recent
year with a calendar structure that matches 1999 exactly. This meant
back-dating all the transactions in the database by 28 years, as well as
setting all the file dates back by 28 years.
I wrote two small programs that I'll be happy to make available to fellow
procrastinators. One subtracts 28 years from all dates in all file labels
on the system. This insures that backups and other processes that rely on
file access/modification dates will work properly. The other subtracts 28
years from all dates in an IMAGE database. This one requires manual help
in finding the dates, but if the database design is clean (Multiview's
is), that's not difficult. Both these programs are offered without
warranty of any kind -- if they turn all your data into navel lint, I'll
be happy to sell you a comb.
I ran the first program, which terminates by halting the machine so that
modified labels aren't overwritten during shutdown. I rebooted, setting
the date to December 21, 1971, then ran the second program. Looking at
the data on-line, everything seemed fine, and I added the period
structure for 2000-alias-1972.
Reports were a bit of a problem at first because the report writer kept
insisting that it had expired and refused to work. This was odd, because
as far as it was concerned, it hadn't even been born yet. In any case, a
few minutes with DEBUG and PATCH took care of that problem. The
accounting system now seems happy: all the aging reports are correct, as
are all the financial analysis reports.
Once one little cleanup item is done -- hard-coding the year in the
check-printing layout -- we should be back in business, with less than a
day spent in the project. Keying in dates with 1972 as the year will take
some getting used to, but fortunately the system is not Y2K compliant, so
it'll reject correct dates if we accidentally enter one. And :LISTFs with
dates look a bit odd:
> --CREATED--- --ACCESSED-- --MODIFIED--
>ADVENT PUB GAMES MAR 14, 1950 OCT 27, 1971 AUG 10, 1950
>ADVENT1 PUB GAMES MAR 14, 1950 AUG 16, 1950 AUG 2, 1950
>ADVENTUR PUB GAMES MAR 14, 1950 OCT 31, 1959 AUG 2, 1950
>ADVLINS PUB GAMES MAR 18, 1960 JUN 13, 1961 MAR 18, 1960
>AMAZE PUB GAMES MAR 14, 1950 AUG 12, 1950 AUG 2, 1950
>ANIMAL PUB GAMES MAR 28, 1950 AUG 16, 1950 AUG 2, 1950
>AP5321J AP501S MVCOGNOS SEP 27, 1957 NOV 25, 1963 NOV 25, 1963
>AP5322J AP501S MVCOGNOS SEP 27, 1957 NOV 25, 1963 NOV 25, 1963
>AP535AJ AP501S MVCOGNOS APR 25, 1958 NOV 25, 1963 NOV 25, 1963
>QCOMPUSL PUB ROBELLE NOV 16, 1967 DEC 14, 1967 DEC 14, 1967
>QCOMPXL PUB ROBELLE NOV 16, 1967 DEC 14, 1967 DEC 14, 1967
>QEDIFY PUB ROBELLE NOV 16, 1967 DEC 14, 1967 DEC 14, 1967
>QEDIT PUB ROBELLE NOV 3, 1960 DEC 22, 1971 OCT 15, 1961
>QEDITCM PUB ROBELLE NOV 22, 1967 DEC 14, 1967 DEC 14, 1967
>COMMAND PUB SYS APR 21, 1962 DEC 22, 1971 DEC 22, 1971
>CONFDATA PUB SYS DEC 23, 1946 DEC 21, 1971 NOV 5, 1956
>CONFINFO PUB SYS APR 25, 1961 NOV 25, 1963 NOV 25, 1963
So I can get back to productive work now, and put off our *real* Y2K
remediation project until a more convenient time (or until our
13-year-old hardware fails, whichever occurs first).
I don't recommend this technique for general-purpose systems, but for
systems that serve only a single company function and are accessed only
by a limited set of users, doing the time warp might be a way to handle
that last nagging Y2K issue.
-- Bruce
--------------------------------------------------------------------------
Bruce Toback Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc. (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my friends -
Phoenix AZ 85028 | It gives a lovely light.
btoback AT optc.com | -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to
pay, including collection costs.
|
