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
