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
--Boundary_(ID_3wGQM/z6Vyg773S/X/72Ag)
Content-type: MESSAGE/RFC822
Content-description: Mailbox
Content-MD5: J09kUPUUAxk3YX4fMBxOvQ==
X-Sun-Data-type: mail-message
Return-path: <sun-managers-relay@ra.mcs.anl.gov>
Received: from stars1.hanscom.af.mil by drizzle.tfs.com (SMI-8.6/SMI-SVR4)
id SAA11940; Tue, 3 Mar 1998 18:04:00 -0500
Received: from smtpgw.hanscom.af.mil by stars1.hanscom.af.mil
(SMI-8.6/SMI-SVR4) id RAA20226; Tue, 3 Mar 1998 17:54:23 -0500
Received: from ra.mcs.anl.gov by smtpgw.hanscom.af.mil (SMI-8.6/SMI-SVR4)
id RAA26398; Tue, 3 Mar 1998 17:58:22 -0500
Received: from localhost (daemon@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3)
with SMTP id QAA26536; Tue, 3 Mar 1998 16:38:16 -0600 (CST)
Received: by ra.mcs.anl.gov (bulk_mailer v1.5); Tue, 3 Mar 1998 16:33:56 -0600
Received: (from daemon@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3)
id PAA26262 for sun-managers-outbound; Tue, 3 Mar 1998 15:44:40 -0600 (CST)
Received: (from listserv@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3)
id PAA26255 for smmsgs-out; Tue, 3 Mar 1998 15:44:36 -0600 (CST)
Received: from antares.mcs.anl.gov (mcs.anl.gov [140.221.9.6])
by ra.mcs.anl.gov (8.8.3/8.8.3) with SMTP id PAA26235 for
<sun-managers@ra.mcs.anl.gov>; Tue, 3 Mar 1998 15:43:37 -0600 (CST)
Received: from smtpgw.hanscom.af.mil (smtpgw.hanscom.af.mil [129.53.1.252])
by antares.mcs.anl.gov (8.6.10/8.6.10) with ESMTP id PAA14824 for
<sun-managers@ra.mcs.anl.gov>; Tue, 3 Mar 1998 15:34:15 -0600
Received: from stars1.hanscom.af.mil by smtpgw.hanscom.af.mil
(SMI-8.6/SMI-SVR4) id QAA21039; Tue, 3 Mar 1998 16:30:52 -0500
Received: from drizzle.tfs.com by stars1.hanscom.af.mil (SMI-8.6/SMI-SVR4)
id QAA19573; Tue, 3 Mar 1998 16:26:51 -0500
Received: from hail.tfs.com by drizzle.tfs.com (SMI-8.6/SMI-SVR4)
id QAA11771; Tue, 3 Mar 1998 16:36:27 -0500
Received: by hail.tfs.com (SMI-8.6/SMI-SVR4) id QAA05008; Tue,
3 Mar 1998 16:34:29 -0500
Date: Tue, 3 Mar 1998 16:34:29 -0500
From: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Subject: Y2K testing
Sender: sun-managers-relay@ra.mcs.anl.gov
To: sun-managers@ra.mcs.anl.gov
Reply-to: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Message-id: <199803032134.QAA05008@hail.tfs.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Content-MD5: puIuI7/itX+cWzWLE3hy0g==
Precedence: bulk
Content-length: 1261
>From gibian@stars1.hanscom.af.mil Tue Mar 3 18:04:01 1998
Followup-to: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Status: RO
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
--Boundary_(ID_3wGQM/z6Vyg773S/X/72Ag)--