| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5883.1 | | UTRTSC::KNOPPERS | Oswald Knoppers | Tue May 13 1997 04:07 | 6 |
| I have never heard of this. What errors does this customer *exactly* get
and where?
Regards,
Oswald
|
| 5883.2 | System time has gone backwards | CHEFS::ACBREO::howlett_t | | Tue May 13 1997 17:35 | 26 |
| Hi
I have more information now,
The VMS is 5.4 DEcnet version not sure but phase IV
the system is frozen, and cannot be upgraded.
They set the date to 19th may to check that it was ok
It was, they set the date back to the current date, and
rebooted,
the last process that seemed to run was DNS$BACK
THEN
Event #353.4 Parameter #0 = system time has gone backwards
clock must be set after 19th May
And everything stops, only way to reboot is to disable DNS
The only thought I can come up with, is maybe reregistering
the licence would help, The cluster is down and its a live system
so its embarrassing.
Terri
|
| 5883.3 | DNS is a distributed database: messing with time a no-no | SMURF::PBECK | Paul Beck | Tue May 13 1997 18:26 | 7 |
| Warning: I'm pretty foggy on this (it's been a long time):
I don't think it's a license problem. DNS timestamps transactions.
Setting time backwards while running DNS can do a number on the
namespace (so DNS makes sure that you can't do that). Not sure what
the solution is (other than waiting another six days or so) ... a
DNS expert is needed here.
|
| 5883.4 | how to recover from this... | UTRTSC::KNOPPERS | Oswald Knoppers | Wed May 14 1997 03:29 | 152 |
| Ah, this is not DECnet... Found the following (old) stars article, hope
this helps.
Regards,
Oswald
----------------------------------------------------------------------------
[DECdns] DNS-E-BADCLOCK and DECnet Events 353.4, Time went Backward
COPYRIGHT (c) 1988, 1993 by Digital Equipment Corporation.
ALL RIGHTS RESERVED. No distribution except as provided under contract.
Copyright (c) Digital Equipment Corporation 1989, 1993. All rights reserved
PRODUCT: VAX Distributed Name Service (DNS), V1.0, V1.1
OP/SYS: VMS and OpenVMS VAX
SOURCE: Digital Customer Support Center
SYMPTOM:
The error:
%DNS-E-BADCLOCK, DNS server clocks not synchronized
is generated after a user or System Manager used VMS SET TIME, SYSMAN
CONFIG TIME, or DTSS to set the system time incorrectly into the future,
and then subsequently sets the time backwards.
Also, setting OpenVMS time back in the Fall to Standard Time may cause
this problem on a DNS server node if not done correctly.
SOLUTION:
Use the following procedure to recover from BADCLOCK errors on a DNS
Server node:
- Obtain the complete file specification for clearinghouse file on
this node. This file is typically located in SYS$SYSROOT:[DNS$SERVER]
and its filename takes form of MY_CH.DNS (The UAF record for the
DNS$SERVER account can also be used to find the location of this
directory.)
- Stop the DNS Server software:
$ @SYS$MANAGER:DNS$STOP
This must be done in order to remove the DNS$TRANS.EXE and DNS$BACK.EXE
images from the installed list.
- Use a SHOW SYSTEM command to find the DNS$TA and DNS$BACK processes
on the DNS server node. If they are hung in the LEF state, then they
must be stopped:
$ STOP PROCESS/ID=xxx
- Delete the global section with the bad time:
$ DELETE SYS$SYSTEM:DNS$GLOBAL.GBL;*
- The DNS Clerk (the DNS$ADVER process) should still be running. If it
is not running, then invoke SYS$MANAGER:DNS$CLIENT_STARTUP.COM to
restart the DNS Clerk software.
- Build a new global section with the DNS$CONTROL command:
DNS> REBUILD NAME
This will produce a new SYS$SYSTEM:DNS$GLOBAL.GBL file and exit you
from DNS$CONTROL.
- Restart the DNS server software:
$ @SYS$MANAGER:DNS$STARTUP.COM
- Add the DNS Database file (clearinghouse file) back to the global file:
DNS> ADD CLEAR .MY_CH FILE SYS$SYSROOT:[DNS$SERVER]MY_CH.DNS
- Check the DNS$UTS attribute of each directory with the master
replica in MY_CH:
DNS> SHOW CHAR CLEAR .MY_CH (to obtain list of directories)
DNS> SHOW DIR .MY_DIR ATTRIBUTE DNS$UTS (see if UTS and timestamp match)
- If any timestamps for DNS$UTS are in the future then:
o Wait till that time to use the directory...
OR
o Delete the DNS database file and repair as a lost DNS database.
This repair procedure information can be found in another article
in this database entitled:
[DECdns] How to Recover a Lost DNS Database from another DNS Server
IMPORTANT NOTE:
This procedure has worked many times; however, it may corrupt the
clearinghouse_CH.DNS file. You should be restoring the file from a recent
backup so you can recover the namespace in this event.
ANALYSIS:
Time changes into the future do not effect DNS. Time going backwards
without adjusting GMT offset with DNS$CONTROL first, causes the DNS$TA and
DNS$BACK to go LEF for the length of time that time went backwards. If time
went backwards a short length of time -- e.g., one hour for a change from
Daylight Savings Time to Standard Time -- then it may be acceptable for the
DNS Server to be out of commission for one hour.
DNS relies on coordinated system times between DNS Server nodes to prevent
corruption in its internal databases. The following errors and symptoms may
be observed when VMS time went backwards on a DNS server node:
- "%DNS-E-BADCLOCK, DNS server clocks not synchronized"
- DECnet Event 353.4 (Backwards Time Event).
- DNS> Show Name (time went backs counter is incrementing)
- DNS$BACK and/or DNS$TA processes hang in LEF
- DECnet Event 353.5 DNS-E-NOCOMMUNICATION errors are reported on DNS
clerk systems.
- DECnet Event 352.12 (Skulk Failed) errors are reported on DNS servers.
- Regular DECnet connectivity to the Miss-Set DNS Server works ok
- DNS$TRANS can sometime respond
DNS maintains time in terms of offsets from GMT time. It is therefore
necessary to reset the DNS TIMEZONE in the FALL when time is set back one
hour in most timezones.
The correct procedure for setting system time backwards on a DNS server
node is outlined in the "VAX Distributed Name Service Management Guide",
DNS V1.0 (AA-KN85A-TE), December 1987, page 3-33, DNS V1.1 (AA-KN85B-TE),
August 1988, page 3-33.
There is also another article in this database describing this procedure
titled:
[DECdns] Changing System Time on DNS Server Systems
|
| 5883.5 | Thanks Oswald | CHEFS::puppie.reo.dec.com::howlett_t | | Wed May 14 1997 09:30 | 8 |
| Hi Oswald,
Thanks that stars article is just what we need
I will copy the answer to the year 2000 people here
as I am sure others will hit the same problem
Regards
Terri
|
| 5883.6 | General Answer is in the HELP::DNS Conference | DRAGNS::SAUNDERS | John Saunders, DECdns Engineering, (508) 275-5424 | Wed May 14 1997 13:13 | 16 |
| Please check HELP::DNS, note #1438.*.
Of course, VMS V5.4 is unsupported. Among other things, this
means that we don't know whether dns$diag existed then, or whether
this command existed then.
Your customer has run into a problem in the concept of a "frozen
system". He's also frozen the bugs, and he's frozen himself out of
support.
I guess there are a lot of customers who figured, "well, if it works
now, it will continue to work". They've left time out of their
calculations...
John Saunders
DECdns Engineering
|
| 5883.7 | Old Version, Wrong Test Procedures... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon May 19 1997 16:09 | 15 |
|
For an extensive discussion of the 10K delta-time ECO -- referenced
as "May 19th" in .0 -- please see VAXAXP::VMSNOTES. It is unlikely
that particularly many V5.4 systems will need this ECO.
Referenced there is the procedure used to roll the time forward, and
to correctly roll the time back to the current time -- I expect this
customer did not follow the directions, and skipped a few steps. As
such, I'd expect there may be some other problems around...
And as mentioned, V5.4 has been de-supported for a while now -- look
at an upgrade to the current release, V7.1, or to something somewhat
more recent than V5.4. (Consider what will happen around the Year
2000 testing that will be coming up -- I am aware of *no* plans to
ECO V5.4.)
|