Time testing on system

[Peter Zeiszler]

Here is a new one that I have never seen before. We have a new environment that we used to test the time drift for the daylights saving time change. Because we are a 24x7x365.25 location we have to drift our time. The OS is 8.2.

We performed our time drift forward and everything worked ok. We then brought the time back to normal time and rebooted the cluster.

Now I am seeing an odd behavior with the queue manager. I do not want to nuke the queue manager and recreate it (like I said - we are 24x7...). The problem is that if I submit a batch job to run with a time before the current time it is submitting the time as 1-nov-2006.

Example:
$ show entry 588
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
588 Security Report SYSTEM Holding until 30-SEP-2006 00:00:00.00
On idle batch queue SYS$BATCH_CADDO
$ set entry 588/after="11-sep-2006"
$ show entry 588
Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
588 Security Report SYSTEM Holding until 1-NOV-2006 23:51:56.09
On idle batch queue SYS$BATCH_CADDO

-----------------------------------------
I am thinking that the queue manager has the time of 1-nov-2006 23:51:56 as the last valid time so it is putting the new time as that time.

Any ideas on how to clear that up without nuking and recreating the queue manager?
Has anyone ever seen this before?

I know on the 7.3-1 systems (last valid OS we did time drift testing with) when you submit for the previous time it still knew the current time as the last valid time.

[John Gillings]

Peter,

I don't think I understand where the "1-NOV-2006" comes from.

You should be able to fail over the queue manager without interrupting anything:

$ SHOW QUEUE/MANAGER/FULL
$ START/QUEUE/MANAGER
$ SHOW QUEUE/MANAGER/FULL

If it doesn't restart, try specifying /ON=(node1,node2,...) where the first entry on the list is different from the current node. If you need it to run on a specific node, you can then fail it back to the normal list immediately. See HELP START/QUEUE/MANAGER/ON

"Despite the transition, queues on the running nodes are not stopped. All requests to the queuing system, for example, PRINT, SUBMIT and SHOW ENTRY requests will complete as expected".

[David B Sneddon]

Peter,

How EXACTLY did you perform your time drift
forward and how EXACTLY did you bring it back
to normal?

I have drifted systems forward and back and
have not seen any problems...

Dave

[Petr Spisek]

If you change time for only one member of the cluster, you should have a problem with the queue_manager, which is runing on one member. Queue_manager sets the time of entry.
Check SHOW QUEUE/MANAGER.
Petr

[Peter Zeiszler]

We set the clock on the one system forward to October 31. We then started up our normal applications. We know we have issues with specific programs during this change so have them shutdown (i.e. DCE$DTSD). We then ran the macro that changes the clock cycle so that after 6 hours the clock has only gone forward 5 hours for an overall effect of falling back one hour. Then we changed the TimeZone logicals and verified everything was working. We let the system run normally under a load to verify no errors.

To put the time back to normal time we shutdown all of our applications, set the time to the real current time, then we rebooted the system.

We have already shutdown the complete cluster. The queue manager file is on a common disk and one of our tests was to move the queue manager around to each of the 3 systems to verify that each of the systems ran the queue manager properly.

All 3 systems have the correct current time.

-------------------------
$ show que/full/manager
Master file: CLSTR_COMMON:[VMS$COMMON]QMAN$MASTER.DAT;

Queue manager SYS$QUEUE_MANAGER, running, on CREEK::
/ON=(CREEK,CADDO,TEJAS)
Database location: CLSTR_COMMON:[VMS$COMMON]
-----------------------

[Peter Zeiszler]

I don't remember what time the system was when we moved the time back to normal time. I would have to guess that the clock was "1-NOV-2006 23:51:56.09" when we did a set time on the system prior to rebooting.

This is the first system we have done the time drift testing with on OpenVMS 8.2. We have never seen this problem on the older OS.

One other step I forgot to mention. After we moved the time back to normal and did a reboot we also anal/disk/repair all disks so that it cleans up any issues with files created in the future.

We also did not have our console manager connected to the system during this testing (cabling wasn't done yet). So I may have no evidence of the date & time of when we flipped the clock back to normal time.

[Peter Zeiszler]

We also drifted all 3 nodes in the cluster at the same time.

This isn't impacting us (well it hit me on a couple batch jobs I submitted as all), its just strange and we never seen this before. Since I don't have another system at 8.2 to use for testing I can't even attempt to reproduce it.

If anyone has an idea where the time comes from that would be nice to know. Or if anyone has done this type of test and is getting similiar results I would be interested in also.