At 13:42 1997.06.01 +0000, you wrote:
>you find so much softjunk *with* sourcecode which was created by some medical
>doctor of some western donor-agency who obviously didn't know what he was
>therefore the bad thing about these people going to other countries
afterwards is not that they
>don't leave their sourcecode in the first country, it is that they might do
the same thing in the
>other country, too.
I know what you mean. Many small market applications were written by
developers who are no longer in business or have lost the source code of the
"old" program. Some of them may have been self-taught and never used good
software engineering practices. Those still in business may require you to
upgrade to their latest version, which may also involve hardware upgrades
(extra memory or disk space or faster processors) and perhaps OS upgrades
(moving to Windows 95 or 97 NT).
My area of expertise is in Clipper, one of the Xbase family of languages. I
can offer to help somebody in this list in a developing country who has an
application written in Clipper, who discovers from testing that it will not
process data for 2000 onwards, and who cannot afford to replace or upgrade
it commercially. Email me and describe the application. If you have the
source code, I can try to fix it. Hopefully, it will be a one-line change.
The Clipper command SET EPOCH TO 1980 will introduce a date "window" that
interprets two-digit years less than 80 as 20xx. If the effort is larger
than that - e.g. the software has other quality problems in date handling,
regretfully my personal resources are limited and I could propose other
approaches you might take. Don't let that limitation stop you asking, anyway.
For the rest of you, start checking all your applications now, if you have
not done so already.
If you advance your system date to test applications, be aware that some
licensed software will expire in the year 2000. For example, our Telecom CD
is valid only for a year. Software may also refuse to function even when the
date is reset back to the present. So always have a backup, and preferably
do your tests with copy data on spare test PCs that can be erased and
restored if necessary.
Check your package by entering transactions (or reservations or patient
treatment dates or whatever is a date in the application) for 1999.12.31,
2000.01.01, 2000.02.01, 2000.02.29, and 2000.03.01. If the package can
accept those dates, run reports from 1999.12.01 to 2000.03.01 to check that
they list in the correct order and date calculations such as debtors ageing
Don't believe that "recent" means "good". I have seen faulty date logic in
code examples from books on Java and on Access written in 1996. The problem
with Year 2000 defects in code is waiting to discover the problem until it
is too late, by which time there is no fallback. You need to start testing
now. This is not a technical problem. All programmers and analysts know what
has to be done in principle. They just don't know how to get all of it done
in time and with the assurance that they really have got it right this time.
My Y2K web page: http://www.iol.ie/~pobeirne/year2000.htm
Patrick O'Beirne B.Sc. M.A. MICS, Systems Consultant, Clipper Developer;
Personal Software Process (PSP) Trainer; TickIT trained ISO 9000 Auditor.
Compuserve: 100023,1304 WWW: http://www.iol.ie/~pobeirne/index.html
Systems Modelling Ltd, Gorey, Co. Wexford, IRELAND. VAT NO. IE4625958Q