I asked about issues surrounding administration of systems involved in Y2K
testing (The original query is attached). The consensus was that the following
are required:
1. Always reboot after setting clock backwards. Additionally, some things don't
like major changes in the clock in either direction, so just reboot after all
clock changes for Y2K testing.
- We are rebooting after all the testing related clock changes.
2. Setting the clock backwards causes some licensing systems to think they are
being "attacked", including FlexLM.
- We are just going to avoid having to run any of our licensed software on
systems with Y2K based clock settings. If we end up having to debug problems, we
will first fallback to non-debugger based techniques. If that fails, then I will
have to get a set of licenses specifically for the machine(s) setup for
developer debugging with Y2K clock settings.
3. Make sure any clock synchronization mechanisms are disabled during clock
changing, i.e. ntp.
- I should be running xntp or similar, but don't so this is not an issue.
4. A full reinstall after we're done messing with the clock is a safe way to
ensure the systems involved return to normal operation.
- Already had this planned.
5. This is a deceptively complex problem, so don't think you are making
mountains out of molehills.
- Reassuring that I'm not over-reacting.
6. Testing now is actually pretty early. Many respondents don't plan on having
testing completed until end of 1998 or later (now, which were banks...? ;-)
- We are actually doing pretty well as Y2K testing goes even though I personally
have been getting itchy that we're late.
And a few me too-s.
- Just makes me feel better about our schedule.
Formal testing of Y2K starts Monday, though we've done preliminary testing this
week and these points seem to cover everything.
My thanks to:
"Kevin P. Inscoe" <kinscoe@cbis.com>
birger@sdata.no (Birger Wathne)
David Thorburn-Gundlach <david@bae.uga.edu>
"Christopher L. Barnard" <cbar44@tsg.cbot.com>
Tom Erickson <Thomas.M.Erickson.1@gsfc.nasa.gov>
Seth Rothenberg <SROTHENB@montefiore.org>
Harry Levinson <levinson@ll.mit.edu>
David Harte <david.harte@hos.horizon.ie>
-Marc
Marc S. Gibian
COMSYS Information Technology Services phone: (781) 377-6350
PRISM/TFS email: gibian@stars1.hanscom.af.mil
or is it: gibian@hanscom.af.mil
well, maybe: gibianm@hanscom.af.mil
and if all else fails: marc.gibian@acm.org
attached mail follows:
My customer's work has progressed to the point where we have to validate their
Y2K support. Of course, this has system administration implications and thus
this posting...
I am concerned about the issues involved with supporting this Y2K work. Test
systems will be getting setup with their clocks reset to various times
immediately prior to the important transition times, run through the
transitions, and then reset to the next test. I am particularly concerned about:
1. being able to run licensed products such as the SPARCworks debugger and
ClearCase when the system on which it is running has had its clock set into
Y2000 range.
2. setting clocks backwards after a test.
Am I needlessly complicating this, or missing issues? The testing IS being done
on machines against which the Y2000 Solaris patches have been applied, so the OS
itself -should- be okay.
TIA,
Marc
p.s. - Yes, its late, but at least its being tested!
Marc S. Gibian
COMSYS Information Technology Services phone: (781) 377-6350
PRISM/TFS email: gibian@stars1.hanscom.af.mil
or is it: gibian@hanscom.af.mil
well, maybe: gibianm@hanscom.af.mil
and if all else fails: marc.gibian@acm.org
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:33 CDT