Y2K: Cinderella: Testing - Topic 006"
At 15:50 1996/12/07 -0500,Richard Warden wrote:
>>At 11:35 07/12/96 +0200, Chris Anderson wrote:
>>The essence is in testing by setting the clock forwards.
>>2000/02/29 is the current date of choice.
>>
>>Apart from silly things (e.g. Windows 3.1 displays 2000
>>as "19:0") nothing serious or system threatening has
>>yet been discovered.
>Chris,
>
>I completely disagree with these statements,
>and consider your idea of
>testing downright dangerous.
I consider breathing terminally dangerous. But someone has to do it. B>)
Now Richard, if you are going to jump down my throat for speaking in
shorthand on a totally different issue, then this is not a good start to
our long and rewarding association. I am an ancient professional. I assume
(usually with disastrous results) that the people I talk to know the basics
of systems operation and generally
what they are talking about.
You are telling me, in other words, that my Cinderellas are such total
goats that they will change their live systems on my whim and then
scream at me when all hell breaks loose? Not!
Hmm, well, maybe some.
However, you raise some very important issues which we need to dissect.
>>The essence is in testing by setting the clock forwards.
>>2000/02/29 is the current date of choice.
I don't understand your objection to this. It is just a convenient
date. It also checks if the system knows about leap and Century years.
Where is the objection? How else can you obtain empirical data?
Most Cinderellas only have the one machine. Most are probably at risk
anyhow because they have never heard of the concept of backups.
The Restaurant where I often eat lost their harddrive recently because
of a lightning strike. Their backups were inadequate and they lost months of
crucial data. They were very cross. Tough.
So I am not advocating that you rush in and change anything without
having adequate backup. I never said that. I was talking about
"Why", not "How".
Testing is key to the Cinderella project. I am not saying that ALL
users have rush out and test. They can merely read the lists and
get a free ride on the back of the donkeys who are actually doing the test work.
But it would be nice if a few participated and got their hands dirty and spread the load.
It is after all their problem, not mine.
But the guys doing the tests that we now see results from
know all about backups and recovery and reruns. The very first
technical report dealt with backup products.
Backup is high on the priority list.
>There are already anecdotes of file backup management systems automatically
>deleting 'old' files when the date is changed to, say, 2000/02/29. These
>systems archive files to tape, and delete them from the hard disk after a
>certain period of time. By jumping the date forward these systems think
>files have been archived when they have not, and delete them anyway.
My problem with this is the word "Anecdotes". The "Advertising" phase
of Y2K is now drawing to a close. The message is out, action is being
taken. Perhaps now we should wrap our favourite Urban Legends in cotton
wool, tuck them away in the bottom drawer and keep them until next time.
Today, we need hard empirical facts. Which program is this? What system
does it run on? What are the parameter settings? Have we tested it
exhaustively? Will the supplier fix it?
Let us now identify these wonky applications, examine them, tweak them,
and if they still refuse to cooperate, hurl them out.
If this case is a real problem then we must look at the product closely.
And test it.
If there are real world programs which behave like this (in the Cinderella
domain) drag them out into the light of day. Name Names. Show examples.
This is also the "classic" mainstream scenario for temp files on OS based
systems such as MVS. You run a little daily job to "scratch" your disk/tape
catalog based on the expiry date of the file. In the pre-ESA 2.2 era
you got a rude shock on Saturday 2000/01/01 because all your files got
scratched. (Slug believes there is a real possibility of this happening
999 days before then anyhow, but nobody is taking him up on it).
This not the time to run daintily round the garden waving our hands in
the air when we hear about a Y2K problem. We need to grab the problem
by the ears and pragmatically fix it.
>Also this idea should not be tried on any systems that rely on forward date
>calculations, such as inventory management where stock has an expiry date
>and should be scrapped and re-ordered when that date is reached.
I say that it is absolutely essential that such systems should be subjected
to the most rigorous testing. Now. Today.
Because if they don't work you are going to have to replace or fix or
take some action. This takes time and money. On the other hand, if
they do work, then you can relax and save your hard-earned money.
Or better yet spend it in riotous living.
If for example, this mission critical suite is so important to you
that you decide to go non-Cinderella and upgrade to a so-called
fully compliant system. Does this mean you are not then going to
test your application by setting the date forward? Please. Get real.
You are obviously not going to do this on your production system.
You are going to do it in a test environment.
If you can afford it, on a side by side machine so that you can
duplicate your processes and observe the results.
>As another example, I run an accounting package for my company that has an
>automatic bill reminder facility that works as soon as Windows is started.
>If I set the system date to 2000/01/01 mayhem would result. Accounts
>registers would be automatically updated from now to 2000 with all the
>regular payments due every month, quarter or year. The reminder list would
>be a mile long.
Well then I suggest you test it so that you know it works come the day.
This sounds sort of mission critical to me. Anything to do with real
money is non-trivial.
Just don't test it on your production machine.
>I've discussed this option with professional colleagues, and our view is
>that no one should consider setting the system date forward unless they know
>exactly what impact it will have on their systems.
If you knew what the impact was before you started, you wouldn't need
to do it at all. What a typically mindless "corporate" response.
BCP (Back Covering Policy) at its worst. It sounds so smooth.
It sounds so threepiece suit and old school tie. But it is utter bullshit.
If this is the best those @#$% &+!( professionals can come up with, I
would suggest that they investigate alternative career paths.
>Are you willing to take responsibility if someone takes your advice, plays
>around with dates, and screws up their system?
>
>Richard
>
In some ways I would be wildly happy. At least it would show that they
are aware of the problem and are prepared to do something about it.
The sad fact is that most of the guys are sitting on their butts contemplating
their navels. Relatively few people are active on these lists for example.
So only a tiny proportion of the real world know what pots.
The ultimate method for playing around with dates and screwing up your
system is to do nothing.
I take responsibility for my own actions. I back up my opinions with
facts, not suppositions. I have earned my daily bread for the last
27 years in giving advice and troubleshooting problems for my customers.
If I advise someone to do something and they do it, yes, I take
responsibility. On the other hand, like a doctor, when I give
advice and they do not take it, or they do it wrong, and die,
then I take no responsibility.
But if idiots do something totally mindless because they misunderstood
what I was saying or take it out of context, then all they will get is
the horse laugh.
Richard, Thank you for your input.
The Message is: Testing is vital. Just don't do it in Production.
So, we have derived some benefit from this exercise because we can now define:
BASIC TESTING RULES FOR CINDERELLAS
You don't test on your production system.
Create a test environment.
You take secure and complete backups.
You define what you are looking for.
Assume that you will trash the system and plan to recover.
Usual Disclaimers.