Time Synchronization Project –I know nothing!!-

Hi experts,

I have Time Synchronization project. What I now about time synchronization is nothing!!. I don't know from where I can start. I need technical details. Our environment contains hundreds of Windows Servers, Linux, AIX, Tandem and Mainframe.

Also, I don't know the risks that may happened if I changed the time. Our servers do thousands of transactions in second and those transactions can't be stopped.

So, any one can guide me in this project.


Thanks      
 
LVL 7
ALNMOOAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nexissteveCommented:
Ouch - not an easy project.

 Only one way to safely do it - system outage.

Certain applications and databases will absolutely have a fit if you go forward in time. You will need to identify those appliations and databases prior to commencing your project "if you are indeed running fast time wise"

If you are running slow however - all is good. "with most applications" - personally I hope you have a development environment and can test your applications prior to commencing with the production roll.

As for how to set it up - use one of the core routers on your network as the main time source. Use WTC to update this. Point your windows domain controllers at the core router - all domain members should be fine once you have succesfully synched.

Point all other unix , mainframes , AIX , Tandem , routers at the core router.

Again I cannot stress how important it will be to test your applications prior to starting - and I would not attempt this outside of an outage window.

Good Luck



giltjrCommented:
What type of mainframes and what OS's are running on the mainframes?  So mainframe OS's can't be a NTP client.  So if you wanted the mainframe to be invloved, your best bet is to make it the offical time source.


We use our mainframe as the offical time source, as it can't be a NTP client.  For the Windows desktops, we have one Windows server that gets the time from the mainframe and all of the desktops point to this Windows server as their time source.  All other deivices and systems point to the mainframe as their time source.
Kevin CrossChief Technology OfficerCommented:
Have used the same as giltjr before.  Usually mainframes are also most available systems.  Windows boxes get rebooted constantly and can crash as often, whereas a mainframe is rarely IPL'd.  

Also your router may not be able to be configured as time source, so you can use mainframe and have it set its time based on public NTP servers such or your router or just set its time correct; then, set all other machines to point to mainframes as NTP servers (can setup primary and secondary).  

On the Windows side, as long as you setup your Active Directory domain controllers to point to NTP servers in your environment you are pretty much set.  Just change registry HKLM\System\CurrentControlSet\Services\W32Time for server to:

Parameters\NtpServer = ntp.yourdomain.com,0x1 ntp2.yourdomain.com,0x1
Parameters\Type = NTP
Config\AnnounceFlags = 5

As long as the member servers/clients of domain are set to HKLM\System\CurrentControlSet\Services\W32Time\Parameters\Type = NT5DS, then they will automatically synchronize time with domain controllers.

For older Windows machines, you can try putting this in a login script:
net time /domain:{your-domain} /SET /Y
JavaScript Best Practices

Save hours in development time and avoid common mistakes by learning the best practices to use for JavaScript.

ALNMOOAuthor Commented:
We are running z/OS 1.4 in the mainframe.

Can this OS be a NTP client??

If not, is there any way to use GPS to be synchronized with other servers that are offline?

One more, If I have the NTP server in remote site and I am using UDP to connect to that server, how could I how much will be the draft in time caused by unreliable connection?

ALNMOOAuthor Commented:
Also, is there any link that can explain to me in details how can start project like this??

Thanks in advance
giltjrCommented:
z/OS can NOT be a NTP client.  I can't remember when IBM introduced a NTP server for z/OS, but if 1.4 can't be an NTP server it can be a TIMED server.  We are z/OS 1.6 and I can't remember when we changed from TIMED to NTP.

We have z/OS be the main time server.   All non-Windows devices get their time directly from z/OS.  For Windows we have one server get the time from the mainframe and all other Windows devices get their time from that server.

Verifty if your z/OS has the NTP server.

If it does NOT, then you need to get concenses that TIMED will work for you and you will need to get a TIMED client for Windows.  Not all platforms support TIMED.  IIRC the biggest issue with TIMED is no timezone, so all servers that get time from a TIMED server must be in the same time zone.  

If your z/OS does support NTP, then have your system programmers setup it up and start running it and start pointing your devices to z/OS as a NTP time source.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ALNMOOAuthor Commented:
thanks giltjr your detailed answer.

what about connecting Mainframe to GPS? is this possible?
giltjrCommented:
No.

What you need to do is talk to your mainframe system programmers.  The ONLY external time source a zSeries mainframe supports is what is called a sysplex timer.  The sysplex timer has the option to reference another external time source, but it will NOT use the Internet and NTP.  The external timer reference on a sysplex timer requires a modem and it dials someplace to get the time.  I'm not sure where it dials, as we do not have that option.  We only have one site and two mainframes so as long as they are in sync with each other it does not really matter if they have the exact time or not.

ALNMOOAuthor Commented:
Dear giltjr

Sorry for bothering you , but I didn't understand what you mean by that your two mainframes are in sync with each other it does not really matter if they have the exact time or not.


how they are sync and have different time???
giltjrCommented:
The two mainframes have the same exact time, however it may not be the exact real UTC time

That is, say that UTC is 072323, our mainframes might be set to 072457, but both of them say that it is 072457.  As all of our devices get their time from the mainframe they will all say 072457, or close to it depending on the accuracy of their clocks.

The sysplex timers are supposed to be accurate to +/- 30 seconds a year, IIRC, which is about 2.5 seconds a month.  Where as I have had PC's look minutes in a day.

What I was attempting to say, as we do not have to corrdinate our TOD with mainframes located at other sites/companies, we do not need our mainframes set exacty to UTC, but they do need to be in synch with each other.  We run parallel sysplex and that is a requirement.  When you can run 10,000-50,000 transactions a second on a single mainframe and you have two and they are updating the same exact database, the clocks have to be exactly the same or the DBMS gets real confused if yo have to do anytype of roll back or forward.

Sorry about the confusion.
ALNMOOAuthor Commented:
Thanks giltjr

thanks for all
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Networking

From novice to tech pro — start learning today.