Re: Network Time Protocol (NTP) client support question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Thursday, June 19, 2008 7:49 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Network Time Protocol (NTP) client support question Edward Jaffe asks (rhetorically?): A Linux_for_z LPAR has the ability to steer the hardware TOD clock? Not to my knowledge, no. SNIP Assume that all functions of Linux are implemented (outside of I/O specific) on a z box. With time functions being part of that, wouldn't Linux for z/Series systems be able to update the TOD? Assuming that this is true, what effect would this have on other LPARs in that CEC? So, if the effect is not deleterious, then is this not an OPEN source and cheap way of doing this without having to pay IBM for STP code? Since I do not have a CEC to play with, I don't have the ability to test this. But it seems to me that if one could get standalone time, it could be quickly tested. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- 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
Re: Network Time Protocol (NTP) client support question
An OS running in an LPAR cannot change the hardware clock, it can only modify it's own view of time, which is maintained (IIRC) as an offset to the true hardware clock. Thompson, Steve [EMAIL PROTECTED] 6/20/2008 9:49 AM Assume that all functions of Linux are implemented (outside of I/O specific) on a z box. With time functions being part of that, wouldn't Linux for z/Series systems be able to update the TOD? Assuming that this is true, what effect would this have on other LPARs in that CEC? So, if the effect is not deleterious, then is this not an OPEN source and cheap way of doing this without having to pay IBM for STP code? Since I do not have a CEC to play with, I don't have the ability to test this. But it seems to me that if one could get standalone time, it could be quickly tested. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
Re: Network Time Protocol (NTP) client support question
STP is more dollars than I'll ever talk my site into spending, especially since such function is FREE on every other platform I know of. Last I looked, it lists for in the 5 figure range. Even if free, I'd have difficulty convincing the rest to let me be the BOSS time server. Timothy Sipples [EMAIL PROTECTED] Paul Gilmartin writes (presumably re: z/OS SNTPD): Gulp. $$$? -- 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
Re: Network Time Protocol (NTP) client support question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gibney, Dave Sent: Thursday, June 19, 2008 4:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Network Time Protocol (NTP) client support question STP is more dollars than I'll ever talk my site into spending, especially since such function is FREE on every other platform I know of. Last I looked, it lists for in the 5 figure range. Even if free, I'd have difficulty convincing the rest to let me be the BOSS time server. SNIP Sorry if this has been asked and answered. I haven't been watching this thread that closely. If you were to bring up a copy of Linux in an LPAR, could it not provide the STP capability? Would this solve the problem? Then that same copy of Linux could be used for other things that need to be done, but doesn't require lots of CPU or C-Store. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- 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
Re: Network Time Protocol (NTP) client support question
Thompson, Steve wrote: If you were to bring up a copy of Linux in an LPAR, could it not provide the STP capability? Would this solve the problem? Then that same copy of Linux could be used for other things that need to be done, but doesn't require lots of CPU or C-Store. A Linux_for_z LPAR has the ability to steer the hardware TOD clock? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Network Time Protocol (NTP) client support question
Edward Jaffe asks (rhetorically?): A Linux_for_z LPAR has the ability to steer the hardware TOD clock? Not to my knowledge, no. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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
Re: Network Time Protocol (NTP) client support question
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin On Tue, 17 Jun 2008 12:57:39 -0700, Edward Jaffe wrote: Paul Gilmartin wrote: On Tue, 17 Jun 2008 08:27:18 -0700, Edward Jaffe wrote: Keep in mind that the TOD clock represents GMT (or UTC). Local time is calculated by adjusting GMT by CVTLDTO and CVTLSO. If the TOD drifts by a second or more, you can fix local time with a compensating adjustment to the time zone offset. See SET TIMEZONE= command. Gaah! Since Good Practice dictates that critical timestamps be kept in UTC (or GMT) your suggestion more conceals the problem of drift than fixes it. The whole point of using UTC (or GMT) time stamps is to avoid issues when the time zone offset is changed. For these logging applications, local time is irrelevant. You seem to be saying that for those logging applications the time stamp is a somewhat arbitrary parameter, increasing monotonically, but whose offset and drift from true GMT don't diminish its value. A point of using UTC time stamps is correlating logs from the z (e.g.) with logs from other systems in the enterprise, possibly in different time zones. If the OP's requirement includes agreement between UTC on the z and UTC on the other systems, fudging the local time offset fails to satisfy it. (I have long wondered whether correct UTC could be obtained by fudging CVTLSO. I have not heard of this being done.) How will this affect the time reported by z/OS Unix programs which use time() to get UTC and strftime() to get civil time? How will this affect Java applications? I don't know how z/OS UNIX programs compute local time. If they use a technique that does not rely on CVTLDTO and CVTLSO, they are already out-of-sync with the rest of the system. POSIX defines UTC as primitive, and defines a relationship from UTC to any other TZ (which can be chosen by the individual user.) If the offset from UTC to any of those zones is different from the POSIX specification, (perhaps by an arbitrary value in CVTLDTO), the system is out of sync with the rest of the industry. What industry-wide standard specifies reliance on CVTLDTO and CVTLSO? I have the possibly mistaken impression that time references provided by the US government's official time sources already include the adjustments for leap seconds. If that's true, then of what use is CVTLSO? -jc- -- 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
Re: Network Time Protocol (NTP) client support question
On Wed, 18 Jun 2008 07:12:21 -0500, Chase, John wrote: What industry-wide standard specifies reliance on CVTLDTO and CVTLSO? I have the possibly mistaken impression that time references provided by Not mistaken. the US government's official time sources already include the adjustments for leap seconds. If that's true, then of what use is CVTLSO? Because it would be impractical to consult those official time sources every time a program invoked the TIME macro or similar facilities, there is a higher stratum local reference source, the [E]TOD clock. In order that the hardware TOD clock can run at a fairly uniform rate and not show a discontinuity at a leap second, CVTLSO exists and is adjusted at the occurrence of a leap second for TIME, etc. to use as a correction to the TOD clock for practical calculation of UTC. -- gil -- 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
Re: Network Time Protocol (NTP) client support question
Paul Gilmartin writes (presumably re: z/OS SNTPD): Gulp. $$$? SNTPD comes with every z/OS license; there's no separate charge for it. I think it was introduced back in z/OS 1.4. If you're concerned about SNTPD's CPU consumption, don't be. SNTPD's sole mission in life is to support tiny (a few bytes), unencrypted (typically) network conversations between participating time children that typically ask for the current time about once a week at randomized intervals. (That's your choice for how often and when they ask, but that's typical.) For perspective, clients are requesting a single system value, not a bunch of non-indexed database records. There's no particular math involved: this isn't calculating Pi to the billionth decimal point. SNTPD would probably be set at a middle-ish WLM service class. It can run anywhere in a Sysplex, and it's probably not top priority for disaster recovery. Although given the devalued foreign exchange rates for the dollar these days, maybe Paul's $$$ is close to the truth. :-) Now, whether your particular IT political environment has weird hangups or not, that's (in part) what PCI auditors can help address. [Geez, are we really talking about IT professionals arguing about how to agree on the time of day? Are we next going to argue about the location of the prime meridian, or whether the earth revolves around the sun or vice-versa? :-) If some business user or manager asked me to defend an IT organization that argued about the time of day, I wouldn't even try.] To reiterate, since October, 2007, your System z9 or z10 mainframe (and even z990/z890 connected to a z9 or z10) can be a (S)NTP client, even deriving its time source from a distributed Linux, UNIX, or Windows server. (You simply order the STP feature to get this capability. Yes, there's a price for that. Which is partly why I suggest you maximize that investment by nominating your mainframe as time boss.) Also, z/OS (and probably also Linux on System z) can act as the (most highly available) master time server for distributed systems and other devices, like routers. As said, my *recommendation* would be to nominate the mainframe as boss (your Class 1 time server), let it get master time for your organization from NIST dial-out, a GPS receiver box, or whatever, and then let other servers and clients depend on the boss, possibly hierarchically if you're a really big organization with a highly distributed WAN *and* if the downstream clients (particularly clients) don't need as much time precision. (If you do have a hierarchical time server implementation, you can often configure the most remote time children to use your mainframe time boss as the backup time source, with say a branch server or nearby intelligent router as primary.) But lots of permutations are possible. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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
Re: Network Time Protocol (NTP) client support question
Honestly, this happened before my time, but back in THE day, value was standardized via 'parity' on a nucleus (note m/f connection!) of basic goods. Something might be worth more or less than, say, a pair of shoes regardless of sticker price. We need a modern international incarnation of parity. Shoes, schmoos. How about crude oil? The life blood of international commerce? What's your widget worth in barrels??? Timothy Sipples [EMAIL PROTECTED] M To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU Re: Network Time Protocol (NTP) client support question 06/18/2008 07:33 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Paul Gilmartin writes (presumably re: z/OS SNTPD): Gulp. $$$? SNTPD comes with every z/OS license; there's no separate charge for it. I think it was introduced back in z/OS 1.4. If you're concerned about SNTPD's CPU consumption, don't be. SNTPD's sole mission in life is to support tiny (a few bytes), unencrypted (typically) network conversations between participating time children that typically ask for the current time about once a week at randomized intervals. (That's your choice for how often and when they ask, but that's typical.) For perspective, clients are requesting a single system value, not a bunch of non-indexed database records. There's no particular math involved: this isn't calculating Pi to the billionth decimal point. SNTPD would probably be set at a middle-ish WLM service class. It can run anywhere in a Sysplex, and it's probably not top priority for disaster recovery. Although given the devalued foreign exchange rates for the dollar these days, maybe Paul's $$$ is close to the truth. :-) Now, whether your particular IT political environment has weird hangups or not, that's (in part) what PCI auditors can help address. [Geez, are we really talking about IT professionals arguing about how to agree on the time of day? Are we next going to argue about the location of the prime meridian, or whether the earth revolves around the sun or vice-versa? :-) If some business user or manager asked me to defend an IT organization that argued about the time of day, I wouldn't even try.] To reiterate, since October, 2007, your System z9 or z10 mainframe (and even z990/z890 connected to a z9 or z10) can be a (S)NTP client, even deriving its time source from a distributed Linux, UNIX, or Windows server. (You simply order the STP feature to get this capability. Yes, there's a price for that. Which is partly why I suggest you maximize that investment by nominating your mainframe as time boss.) Also, z/OS (and probably also Linux on System z) can act as the (most highly available) master time server for distributed systems and other devices, like routers. As said, my *recommendation* would be to nominate the mainframe as boss (your Class 1 time server), let it get master time for your organization from NIST dial-out, a GPS receiver box, or whatever, and then let other servers and clients depend on the boss, possibly hierarchically if you're a really big organization with a highly distributed WAN *and* if the downstream clients (particularly clients) don't need as much time precision. (If you do have a hierarchical time server implementation, you can often configure the most remote time children to use your mainframe time boss as the backup time source, with say a branch server or nearby intelligent router as primary.) But lots of permutations are possible. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing
Re: Network Time Protocol (NTP) client support question
It shouldn't matter too much for your PCI audit. The requirement is not really that each server has exactly the same time, as long as any time difference is fairly constant and is quantifiable. It's there really so that different server's system logs can be used collectively or in concert should some later investigation into something become necessary. If you can demonstrate to your auditor that you take steps to ensure that the mainframe clock does not drift too much and that you know what any time difference is, he should accept that, or at least note that a compensating control is in place. For example, twice a year setting the HMC system clock with some external time reference (even the Speaking Clock) and ensuring that your IPL'd systems pick up that changed time. You don't need to be second-accurate, as long as the difference is known. Brian -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Chauhan, Jasbir Sent: 16 June 2008 20:03 To: IBM-MAIN@BAMA.UA.EDU Subject: Network Time Protocol (NTP) client support question As part of the PCI audit we need to look into adopting NTP (network time protocol) on the mainframe to ensure all of our 'systems' are synchronized. Can STP provide NTP client capability to maintain 'same time' across heterogeneous platforms. Hopefully, some one out there has a solution. I'll also contact IBM to see if how they have one. We are running on a z9-BC. - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- 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
Re: Network Time Protocol (NTP) client support question
On Tue, 17 Jun 2008 11:38:30 +0100, Bri P wrote: It shouldn't matter too much for your PCI audit. The requirement is not really that each server has exactly the same time, as long as any time difference is fairly constant and is quantifiable. It's there really so that different server's system logs can be used collectively or in concert should some later investigation into something become necessary. If you can demonstrate to your auditor that you take steps to ensure that the mainframe clock does not drift too much and that you know what any time difference is, he should accept that, or at least note that a compensating control is in place. For example, twice a year setting the HMC system clock with some external time reference (even the Speaking Clock) and ensuring that your IPL'd systems pick up that changed time. You don't need to be second-accurate, as long as the difference is known. What are the guaranteed maximum drift rates of: o The HMC clock between settings with an external reference o The [E]TOD clock between IPLS in the absence of STP or ETR? (I suspect the vendor won't specify the latter, but will recommend STP.) Will this be acceptable to the auditor? -- gil -- 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
Re: Network Time Protocol (NTP) client support question
Actually, as of October, 2007, System z's Server Time Protocol (STP) can act as a Simple Network Time Protocol (SNTP)/NTP client in order to receive its master time. Your System z9 (or z10) is capable of that function if you get the STP option. You can visit here to start getting some more information: http://www.ibm.com/systems/z/advantages/pso/stp/ntp.html Also, I agree that it is highly desirable to have your mainframe act as the master (S)NTP server for your other servers and even PC/Mac clients. Let the mainframe be the highly available time boss if at all possible. See here for some setup information (for z/OS): http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.halu101/sntpdinfo.htm So, in summary, you can use the STP feature to let the mainframe get a master time for your organization (via SNTP/NTP client support, such as by connecting to a dedicated GPS box that delivers its time signal via a closed NTP link). Then use the mainframe's SNTPD -- included with z/OS -- to keep every other server and client in sync. That'd be the preferred approach. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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
Re: Network Time Protocol (NTP) client support question
Bri P wrote: It shouldn't matter too much for your PCI audit. The requirement is not really that each server has exactly the same time, as long as any time difference is fairly constant and is quantifiable. It's there really so that different server's system logs can be used collectively or in concert should some later investigation into something become necessary. If you can demonstrate to your auditor that you take steps to ensure that the mainframe clock does not drift too much and that you know what any time difference is, he should accept that, or at least note that a compensating control is in place. For example, twice a year setting the HMC system clock with some external time reference (even the Speaking Clock) and ensuring that your IPL'd systems pick up that changed time. You don't need to be second-accurate, as long as the difference is known. Keep in mind that the TOD clock represents GMT (or UTC). Local time is calculated by adjusting GMT by CVTLDTO and CVTLSO. If the TOD drifts by a second or more, you can fix local time with a compensating adjustment to the time zone offset. See SET TIMEZONE= command. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Network Time Protocol (NTP) client support question
On Tue, 17 Jun 2008 08:27:18 -0700, Edward Jaffe wrote: Keep in mind that the TOD clock represents GMT (or UTC). Local time is calculated by adjusting GMT by CVTLDTO and CVTLSO. If the TOD drifts by a second or more, you can fix local time with a compensating adjustment to the time zone offset. See SET TIMEZONE= command. Gaah! Since Good Practice dictates that critical timestamps be kept in UTC (or GMT) your suggestion more conceals the problem of drift than fixes it. How will this affect the time reported by z/OS Unix programs which use time() to get UTC and strftime() to get civil time? How will this affect Java applications? -- gil -- 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
Re: Network Time Protocol (NTP) client support question
On Tue, 17 Jun 2008 23:08:42 +0900, Timothy Sipples wrote: Actually, as of October, 2007, System z's Server Time Protocol (STP) can act as a Simple Network Time Protocol (SNTP)/NTP ... http://www.ibm.com/systems/z/advantages/pso/stp/ntp.html Hooray! Also, I agree that it is highly desirable to have your mainframe act as the master (S)NTP server ... http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.halu101/sntpdinfo.htm So, in summary, you can use the STP feature to let the mainframe get a master time for your organization (via SNTP/NTP client support, such as by connecting to a dedicated GPS box that delivers its time signal via a Gulp. $$$? closed NTP link). Then use the mainframe's SNTPD -- included with z/OS -- to keep every other server and client in sync. That'd be the preferred approach. Now you must face the organizational politics. The group with the existing NTP server may not wish to relinquish its position in the pecking order, and argue, We were given the requirement to provide 5-second accuracy compared to NIST and 1-second agreement across the installation. We are meeting that requirement and operating successfully. Can you provide a business justification for spending $$$ to get accuracy 1000 times better than needed? They may be deaf to the argument, We're the best so we should be the master. By being in closer agreement with NIST, you may be perceived as violating established practice. -- gil -- 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
Re: Network Time Protocol (NTP) client support question
Thanks for all your responses. 2nd Level support too came back with the 'z/OS currently is not implemented as SNTPD client' response. However, they did add my name to the list of their 'Marketing database inquiries' for such a request. Apparently there are others who have made similar requests but the numbers aren't enough to get any consideration. The fact that it would require a design change would lead me to believe that there was no immediate plan to add this feature in the upcoming z/OS releases either. Unfortunately, the PCI standard is big on absolute statements such as Synchronize all critical system clocks and times and Verify that NTP or similar technology is used for time synchronization. Anything that does not meet the specified standards must have a compensating control that meets and exceeds the requirement. The assessor on-site, is here to both ensure we are in compliance with the PCI standard and to help us find solutions to help us comply. In our discussion yesterday he specifically stated that setting time manually has not been accepted by Visa in their review of similar PCI reports. Hopefully, we can come up with a compromise. Best Regards, Jasbir -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, June 17, 2008 11:27 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Network Time Protocol (NTP) client support question Keep in mind that the TOD clock represents GMT (or UTC). Local time is calculated by adjusting GMT by CVTLDTO and CVTLSO. If the TOD drifts by a second or more, you can fix local time with a compensating adjustment to the time zone offset. See SET TIMEZONE= command. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 -- 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
Re: Network Time Protocol (NTP) client support question
I'm wondering if you've asked the wrong question to the wrong support group. Basic concept. In mainframes, Time is a hardware function. For this reason, setting the time is best handled at the hardware level. You have a couple of alternatives, depending on your hardware configuration. For Parallel Sysplex based technology, IBM has supported the 9037 Sysplex Timer for many years. The Sysplex Timer can dial out to NIST ACTS in Boulder Colorado for a time synchronization accuracy of something like 0.1 second or better. OR IBM has introduced a follow-on technology called STP which is built into the mainframe itself. This technology is enabled by ordering a feature code to be installed on the machine, and is available on z990, z890, z9 and z10 servers. STP supports dial out to NIST ACTS in Boulder, and has just recently been enhanced to allow the STP service to synchronize to a local or internet-based NTP service. So, to answer the literal question of an NTP Client for z/OS, the literal answer is STP syncronized to an NTP service. To answer the more broad-based question of making sure a mainframe system automatically has the correct time, the broad-based answer is any one of the above options. Brian On Tue, 17 Jun 2008 15:31:29 -0400, Chauhan, Jasbir wrote: Thanks for all your responses. 2nd Level support too came back with the 'z/OS currently is not implemented as SNTPD client' response. However, they did add my name to the list of their 'Marketing database inquiries' for such a request. Apparently there are others who have made similar requests but the numbers aren't enough to get any consideration. The fact that it would require a design change would lead me to believe that there was no immediate plan to add this feature in the upcoming z/OS releases either. Unfortunately, the PCI standard is big on absolute statements such as Synchronize all critical system clocks and times and Verify that NTP or similar technology is used for time synchronization. Anything that does not meet the specified standards must have a compensating control that meets and exceeds the requirement. The assessor on-site, is here to both ensure we are in compliance with the PCI standard and to help us find solutions to help us comply. In our discussion yesterday he specifically stated that setting time manually has not been accepted by Visa in their review of similar PCI reports. Hopefully, we can come up with a compromise. Best Regards, Jasbir -- 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
Re: Network Time Protocol (NTP) client support question
Paul Gilmartin wrote: On Tue, 17 Jun 2008 08:27:18 -0700, Edward Jaffe wrote: Keep in mind that the TOD clock represents GMT (or UTC). Local time is calculated by adjusting GMT by CVTLDTO and CVTLSO. If the TOD drifts by a second or more, you can fix local time with a compensating adjustment to the time zone offset. See SET TIMEZONE= command. Gaah! Since Good Practice dictates that critical timestamps be kept in UTC (or GMT) your suggestion more conceals the problem of drift than fixes it. The whole point of using UTC (or GMT) time stamps is to avoid issues when the time zone offset is changed. For these logging applications, local time is irrelevant. How will this affect the time reported by z/OS Unix programs which use time() to get UTC and strftime() to get civil time? How will this affect Java applications? I don't know how z/OS UNIX programs compute local time. If they use a technique that does not rely on CVTLDTO and CVTLSO, they are already out-of-sync with the rest of the system. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Network Time Protocol (NTP) client support question
What *do* you have? Do you have IBM 9037 Sysplex Timer? Brian On Tue, 17 Jun 2008 16:16:18 -0400, Chauhan, Jasbir wrote: Brian, As you others pointed out, STP is the key-word here. Maybe I should have made that clear at the outset - we don't have it. I was looking for alternatives -- and inform the decision makers accordingly. Thanks for all the feedback. Best Regards, Jasbir -- 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
Re: Network Time Protocol (NTP) client support question
The z/9 cannot be a SNTP client, but there are hardware features to sync the z/9 hardware clock to a secondary or primary standard (NIST). That once was the now withdrawn sysplex timer and is now software loaded in the HMC. If your SMTP server is also in sync with NIST, then the requirement should be satisfied. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chauhan, Jasbir Sent: Tuesday, June 17, 2008 2:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Network Time Protocol (NTP) client support question Thanks for all your responses. 2nd Level support too came back with the 'z/OS currently is not implemented as SNTPD client' response. However, they did add my name to the list of their 'Marketing database inquiries' for such a request. Apparently there are others who have made similar requests but the numbers aren't enough to get any consideration. The fact that it would require a design change would lead me to believe that there was no immediate plan to add this feature in the upcoming z/OS releases either. Unfortunately, the PCI standard is big on absolute statements such as Synchronize all critical system clocks and times and Verify that NTP or similar technology is used for time synchronization. Anything that does not meet the specified standards must have a compensating control that meets and exceeds the requirement. The assessor on-site, is here to both ensure we are in compliance with the PCI standard and to help us find solutions to help us comply. In our discussion yesterday he specifically stated that setting time manually has not been accepted by Visa in their review of similar PCI reports. Hopefully, we can come up with a compromise. Best Regards, Jasbir -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, June 17, 2008 11:27 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Network Time Protocol (NTP) client support question Keep in mind that the TOD clock represents GMT (or UTC). Local time is calculated by adjusting GMT by CVTLDTO and CVTLSO. If the TOD drifts by a second or more, you can fix local time with a compensating adjustment to the time zone offset. See SET TIMEZONE= command. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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
Re: Network Time Protocol (NTP) client support question
On Tue, 17 Jun 2008 12:57:39 -0700, Edward Jaffe wrote: Paul Gilmartin wrote: On Tue, 17 Jun 2008 08:27:18 -0700, Edward Jaffe wrote: Keep in mind that the TOD clock represents GMT (or UTC). Local time is calculated by adjusting GMT by CVTLDTO and CVTLSO. If the TOD drifts by a second or more, you can fix local time with a compensating adjustment to the time zone offset. See SET TIMEZONE= command. Gaah! Since Good Practice dictates that critical timestamps be kept in UTC (or GMT) your suggestion more conceals the problem of drift than fixes it. The whole point of using UTC (or GMT) time stamps is to avoid issues when the time zone offset is changed. For these logging applications, local time is irrelevant. You seem to be saying that for those logging applications the time stamp is a somewhat arbitrary parameter, increasing monotonically, but whose offset and drift from true GMT don't diminish its value. A point of using UTC time stamps is correlating logs from the z (e.g.) with logs from other systems in the enterprise, possibly in different time zones. If the OP's requirement includes agreement between UTC on the z and UTC on the other systems, fudging the local time offset fails to satisfy it. (I have long wondered whether correct UTC could be obtained by fudging CVTLSO. I have not heard of this being done.) How will this affect the time reported by z/OS Unix programs which use time() to get UTC and strftime() to get civil time? How will this affect Java applications? I don't know how z/OS UNIX programs compute local time. If they use a technique that does not rely on CVTLDTO and CVTLSO, they are already out-of-sync with the rest of the system. POSIX defines UTC as primitive, and defines a relationship from UTC to any other TZ (which can be chosen by the individual user.) If the offset from UTC to any of those zones is different from the POSIX specification, (perhaps by an arbitrary value in CVTLDTO), the system is out of sync with the rest of the industry. What industry-wide standard specifies reliance on CVTLDTO and CVTLSO? -- gil -- 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
Re: Network Time Protocol (NTP) client support question
Paul Gilmartin wrote: What industry-wide standard specifies reliance on CVTLDTO and CVTLSO? I assume this question is purely rhetorical. Every system has its own variables that carry this information. These are merely the ones used by z/OS. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Network Time Protocol (NTP) client support question
As part of the PCI audit we need to look into adopting NTP (network time protocol) on the mainframe to ensure all of our 'systems' are synchronized. Can STP provide NTP client capability to maintain 'same time' across heterogeneous platforms. Hopefully, some one out there has a solution. I'll also contact IBM to see if how they have one. We are running on a z9-BC. Best Regards, Jasbir -- 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
Re: Network Time Protocol (NTP) client support question
Chauhan, Jasbir wrote: As part of the PCI audit we need to look into adopting NTP (network time protocol) on the mainframe to ensure all of our 'systems' are synchronized. Can STP provide NTP client capability to maintain 'same time' across heterogeneous platforms. Hopefully, some one out there has a solution. I'll also contact IBM to see if how they have one. We are running on a z9-BC. STP is a cost option. If you don't have it, you can still synchronize your systems for free by running SNTPD under z/OS UNIX. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Network Time Protocol (NTP) client support question
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chauhan, Jasbir Sent: Monday, June 16, 2008 2:03 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Network Time Protocol (NTP) client support question As part of the PCI audit we need to look into adopting NTP (network time protocol) on the mainframe to ensure all of our 'systems' are synchronized. Can STP provide NTP client capability to maintain 'same time' across heterogeneous platforms. Hopefully, some one out there has a solution. I'll also contact IBM to see if how they have one. We are running on a z9-BC. Best Regards, Jasbir z/OS cannot be an NTP client. However, you can use STP (which is not NTP!) to maintain the clock on the z and then use z/OS as your NTP server for the rest of your systems. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Network Time Protocol (NTP) client support question
On Mon, 16 Jun 2008 14:10:51 -0500, McKown, John wrote: -Original Message- [mailto:[EMAIL PROTECTED] On Behalf Of Chauhan, Jasbir Sent: Monday, June 16, 2008 2:03 PM As part of the PCI audit we need to look into adopting NTP (network time protocol) on the mainframe to ensure all of our 'systems' are synchronized. Can STP provide NTP client capability to maintain 'same time' across heterogeneous platforms. z/OS cannot be an NTP client. However, you can use STP (which is not NTP!) to maintain the clock on the z and then use z/OS as your NTP server for the rest of your systems. There are several sides to this topic: o AFAIK, there is no way to maintain accurate time on z without spending the big bucks for STP (or ETR, if it's still supported). o With STP, z will probably have the most accurate time of any system in your shop. Logically, z should be the NTP server. o But, as so often stated in this list, logic must sometimes yield to Legacy inertia. And in the OP's case, it appears that Legacy is the existing non-z NTP server. IBM would be well advised to learn to play well with others as an NTP client. -- gil -- 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
