Steven Dorst asked about setting D3 time from the host OS. Here are some notes about setting the OS or MV time from either environment.
D3 already has a program in dm,bp called start.rtc for setting the D3 time based on the OS time. For D3NT the code just terminates because (I believe) D3NT gets its time directly from the OS, like many of the MV environments that don’t rely on a virtual machine for such services. For D3 over Linux and other Unix-like environments start.rtc chains to start.rtc.unix where the following code does the heavy lifting.
execute "!exec date +%H:%M:%S" capturing utime
execute "SET-TIME ":utime
The date from *nix is in UTC format. The HMS mask above converts the output to a format which can be used by the D3 command set-time. If you are finding that D3 isn’t keeping up with the system time (possible, not likely) then you can setup a phantom to run "start.rtc" at periodic intervals. If you’re interested and you have D3, check the program to see how its also sets the date, accounting for non-USA formatting. If you don’t have the code handly, just look into the masks to retrieve Year, Month, and Day in a format that’s suitable for SET-DATE.
If you find the time isn’t right on your system, then either the hardware clock or the system/OS clock might be wrong.
To set the hardware clock to agree with the system/OS clock, here is the command for Linux:
(You can’t tell but there are two hyphens preceding the options on this command.)
If you are sure the hardware is keeping good time but the OS needs to read it again, use:
If you find a need to change the OS time manually, or from your MV environment, use:
date -s "hh:mm:ss"
(Only one hyphen.) Use the appropriate MV method for shelling out like "!date …" or "execute \!date …\".
You might want to change the clock more automatically. To get your system to poll an NTP server for the current time, use ntpdate. To run a server which update the local time periodically from a remote server, use ntpd.
I’ve found that Linux in Microsoft Virtual PC sometimes has a problem syncing the soft-clock in Linux with the virtual clock and real clock. This is because of timing issues in the kernel, issues in VPC, and/or the fact that I’m running a super fast AMD dual core processor. You many be able to fix this by modifying /boot/grub/conf, where you’ll find a "kernel" statement use by the boot loader to boot a specific kernel. Here is an example of a kernel line with the parameters for timing in blue (line broken into segments to fit this blog column:
ro root=LABEL=/ rhgb
quiet clock=pit nosmp
I honestly couldn’t tell you the ramifications of each flag, though I did look them up before using them. I’ve been setting up a software phone system using the latest incarnation of Asterisk@Home. It’s called Trixbox and is built over a CentOS4 distro (RHEL4 clone). For this environment I found timing is OK when I just use the clock=pit option. YMMV
If I missed anything critical, please let me know and I’ll edit this content.