Hi,
zuletzt gab's das vermehrt bei den Y2K Test (kann mich noch lebhaft erinnern).
Da Du ja zum Glück ein Testsystem hast mein Tip: Alles neu aufsetzen, denn Dein Testsystem wird nie mehr sein, wie es mal war!
Dazu aus der KBASE:
Cautions About Year 2000 Testing of Notes and Domino
Problem:
As the issue of Year 2000 readiness becomes increasingly important, companies are testing their software to make sure that it will actually work after the millennium rollover. During this testing, some customers have encountered issues when setting their computer clocks forward in order to test the functionality of Notes and Domino.
What are some common pitfalls and ways to avoid problems when doing Year 2000 testing of Notes and Domino?
Solution:
NOTE: First and foremost, it is extremely important that production servers and data not be used for Year 2000 testing. Ideally, you should have a completely separate testing environment, in which test servers do not route mail, replicate, or otherwise interact with the production environment. If this is not possible for your organization, at the very least, you are urged to back up all your important data and system files and restore them once your testing is complete.
Notes and Domino are designed to function correctly in an environment in which the date progresses forward in accordance with the normal passage of time. Suddenly advancing the clock many months into the future may yield unexpected results and cause problems. Additional problems may occur when you suddenly move the clock backward again when testing has been completed.
Presented below is a compilation of issues that have been reported by customers, along with some other suggestions about topics that may need special attention. This is by no means a complete list; it is merely a starting point. The entirety of what should be covered by an organization's Year 2000 testing efforts is far beyond the scope of this technote.
1. Expiration of User ID Certificates
By default, User ID certificates expire two years from the date they were issued. Some customers who have advanced the clock have found that all their user certificates suddenly expire. In the normal course of time, administrators would have ample warning and be able to recertify users before their certificates expire. When the certificates all artificially expire at once, you must recertify them before they can be used, to access your server.
To avoid this problem, before you begin testing, recertify any User ID's with which you would like to test, with an expiration date well beyond the testing time frame.
Additionally, if the server's date has been set ahead, clients may see the following error message when connecting to the server:
"The server's certificate has expired."
In fact, however, it is the certificate in the client's User ID that has passed its expiration date, not the certificate of the Server ID.
2. Replication Histories
If you set the clock forward, then have servers replicate with each other, and then set the clock back, you will find that replication will no longer occur. This is because the replication history will show a successful replication entry from the future, and replication logic is designed so that replication will not take place if the current time is before the most recently recorded replication.
The only way to fix this problem once it has occurred is to manually clear the replication history of affected databases. This can be extremely time consuming, and there is no automated workaround to avoid doing it by hand. To avoid the problem in the first place, back up all databases before testing or use an isolated test environment.
3. View Indexes
Similar to the way replication is handled, Notes keeps track of the last time a view was indexed and will not reindex a view, if the last recorded date the index was updated is in the future. This problem can be particularly troublesome for the Public Name & Address Book.
To avoid the problem, do not move your clock backward in time. If, however, the clock is set back, you should restore your databases from backup.
NOTE: The issue of the last modified date being in the future can be avoided, if the view index is discarded and rebuilt. To do this on a server, run Updall -r on the database. On a workstation (local database), change the properties of the view from "Index Discard - Never" to "Index Discard - After each use".
4. Archive and Purge Functions
Many applications have some way of archiving and/or purging old data. When the clock is advanced, archive and purge agents will assume that current data is much older than it really is, and thus process it according to how they have been programmed. This could result in your data being moved around or completely deleted. In addition, after setting the clock back, you may find that documents are not archived or purged as expected, because the last modified date is far ahead in the future (this is similar to Issues 2 and 3 above).
To avoid the problem, back up your databases or use an entirely separate testing environment.
5. Customized Applications that Trim Year Values to Two Digits
Internally, Notes and Domino store dates in a Year 2000 ready format, but there is nothing to prevent database designers from taking a date value and extracting only the last two digits of the year. Many problems can occur if comparisons are made based on these trimmed date values, as "00" will sort as a smaller number than "98". This is not a failure of Notes, but a failure to program wisely.
To avoid this problem, use the Notes native date format for comparisons and sorting.
6. External Programs that Exchange Data with Notes
If your Notes application exchanges data with an external program, then you must perform thorough testing of the application and the means by which data is exchanged. For example, a non-Year-2000-ready external program could give a date value of "01/03/19100" to Notes, which cannot be interpreted correctly unless you specifically code a date-handling routine yourself, to parse this type of value. Also at risk are operations that depend on fixed field lengths. There are many possible ways for this type of processing to go awry, even though Notes is functioning as designed.
To avoid this problem, make sure all your applications are Year 2000 ready and that all data-exchange operations work correctly.
Supporting Information:
For more information regarding Lotus's policies and practices regarding the Year 2000, please visit Lotus' Year 2000 web site at:
http://www.lotus.com/year2000.
This information is current as of the date set forth above, is provided for informational purposes only, and is furnished "as is" without warranty of any kind, express or implied. This information is not, and should not be construed to be, a warranty or an extension or modification to the terms of any applicable warranty. The limited warranty for Lotus products is solely as contained in the software agreement governing your use of Lotus software. Lotus' assessment of the Year 2000 readiness of its products is an ongoing effort, and the information contained herein is subject to change. To ensure you have current and accurate information about the Year 2000 readiness of Lotus products, you should periodically refer to the Lotus Year 2000 web site.
Year 2000 Ready Definition: When IBM and Lotus refer to a product as Year 2000 ready it means that the product, when used in accordance with its associated documentation, is capable of correctly processing, providing and/or receiving date data within and between the 20th and 21st centuries, provided that all products (for example, hardware, software and firmware) used with the product properly exchange accurate date data with it. IBM and Lotus consider products not Year 2000 ready if we know that they do not meet the definition of Year 2000 ready set out above, or if they have not been tested.
Lotus products identified as Year 2000 ready may require user intervention, such as the application of a maintenance release or update, or the installation of the latest version release. The IBM Year 2000 Product Readiness Database (accessible through Lotus' Year 2000 web site or directly at
http://www.ibm.com/year2000) includes information for Lotus software products to denote situations in which such action may be required and includes additional information that might prove useful to our customers and partners.
This information, other Year 2000 related Technotes published by Lotus, and all other information contained on Lotus' and IBM's past and present Year 2000 web site pages regarding products and services offered by Lotus, IBM and IBM's subsidiaries are "Year 2000 Readiness Disclosures" under the Year 2000 Information and Readiness Disclosure Act of 1998, a U.S statute enacted on October 19, 1998. This designation also applies to information delivered through or derived from Lotus' and IBM's past and present Year 2000 web site pages, such as electronic and printed Product Readiness Reports, various editions of the Lotus White Papers and FAQs, and other materials.
Lotus' and IBM's Year 2000 web site pages have been and will continue to be Lotus' primary mechanism for communicating Year 2000 information.
Copyright 1999 Lotus Development Corporation. All rights reserved.
Thema: time is too far in the future (Gelesen 10484 mal)