Paul Gilmartin wrote:
What initially sets the content of the TOD clock at IPL (or
is it POR) time. IIRC, there is some setting that can only be
accomplished at POR. Is there a clock in the HMC, so the
data path for that initial setting might be:
ETR to HMC (at POR)
HMC to TOD (at IPL)?
The HMC is not used in any of the time setting process. Remember the HMC
is purely optional, its only an operator aid, you can POR/IPL without it
by using the Support Element (SE) (the Thinkpad inside the CPC). There
is an option to sync the HMC time with the time on the SE
As for the POR time, I suppose it depends on the CPC model in use. But
with the latest zZeries it gets the TOD time from the 9037 - if you have
one. If not, it gets the initial time from the Support Element at POR.
That being said if you POR without a 9037, then connect one afterwards,
it just gets on with life and uses the 9037 value. This I know as I
recently did a lot of work with new CPCs and timers. The timer was
connected after the POR and all was ok. Just to add to the loop the SE
will sync to the CPC once a day
With IPL time, each LPAR has its own virtual TOD clock that is initially
set when the partition is activated. The initial value is usually that
of the CPC TOD. If there is a 9037 and the Opsys supports it then it
will use the 9037 time and can accept offset changes etc. The LPAR
profile has options to enable the use of the 9037 and also to specify
any offset value
I recall we once got about 15 seconds out of sync, and were able
to recover without the dreaded POR by repeatedly issuing manual
commands to steer by a couple seconds until after about a week
the ETR was within tolerance to sync to NIST dialup. I believe
an IBM employee (Greg Dyck?) has supplied instructions for doing
this on this list.
Setting a new 9037 time to drift to can be a real pain due to the 4.999
seconds maximum value at a rate 1 sec per 12 hours - i had to adjust 45
secs recently.I never understood why this maximum value was so low. Then
recently I saw some possible explanation for the low value. I was
testing the 9037 ETS a few weeks back and for some reason, not sure why,
the time that was interpreted from the dialup modem was way off, about
21 hours in advance. As this was over the maximum if ignored the value
and disabled the ETS. I suppose a sensible approach. What would have
been better would to have the 4.999 secs for ETS, but a manual offset
greater than this could prompt for "are you sure".
Regards
Roy
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
