|
Roger Boucher <RBoucher@stanpac.com> wrote: >Sorry!!! I meant turning forward and then turning back... >so either set of issues is highly relevant to me. Thank >you for catching that. Aha! At first I was thinking you might not be too badly off. If you turn the date back and then forward again to the current date you might just get away without any problems. But turning the clock futurewards is not a good idea on your production system. It happened to me once on a live system after we had removed the front panel to repair the on/off switch. Unbeknownst to us at the time, there was a feature in the 9406 that caused it to IPL with a future date after disconnecting and reconnecting the panel. I know a few people were bitten by this. The immediate problem was that hundreds of scheduled jobs had been submitted both by the IBM job scheduler and J.D. Edwards' Sleeper as they tried to catch up with the "backlog", particularly the JDE product which will submit 365 instances of a daily job if you set the clock forward 1 year. You run JDE, don't you? Do you have any other job scheduler, e.g. Robot, and how would that be affected? After you sort out that mess you find that you have QHST history that never goes away because it never expires. The same goes for problem logs. You also have journal entries with future dates waiting to get mixed in with, and become indistinguishable from, your genuine future journal entries. You also have strange creation, last used, and possibly last saved/restored dates on objects that could affect your tape management system and subsequent backups. After you set the clock back you have to check that your various job schedulers are back in synch. and the right jobs are primed to go. You may also have problems with applications that may have stored the current date in various places and closed out periods etc. You have to have a complete understanding of how each application tracks its dates to be sure you've covered that area. Like Al I'm really amazed that your software provider won't let you have a temporary licence to conduct essential testing. I'm sure it's not J.D. Edwards because I've always found them to be very co-operative in these circumstances. I too think we should know who it is so (a) we can avoid buying their software and (b) it might put some pressure on them to be more reasonable. Dave Kahn, ABB Steward Ltd. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.