At 15:50 1996/12/07 -0500,Richard WardenI consider breathing terminally dangerous. But someone has to do it. B>)
>>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.
> >I completely disagree with these statements,
>and consider your idea of
>testing downright dangerous.
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.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.
>>2000/02/29 is the current date of choice.
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:
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.