The "problem" is that z/OS _cannot_ allow the TOD clock (hardware clock) to go "backwards". The way that STP addresses this is that the STP software can "speed up" or "slow down" the TOD increment pulse (or whatever it's called). This is the hardware portion of STP. And I think that hardware addition is a major portion of the cost of getting STP.
If your application software can be written to use the z/OS software (TIME macro et al.) timing interfaces, getting the _local_ time, then it is possible to have a NTP "steer" this by adjusting the GMT to local offset value in the CVT. This is basically doing a periodic SET CLOCK=hh.mm.ss type command. I assume everybody can understand the problem because there would now be no way to actually relate the TOD clock values to the current "software clock" values. On Wed, Sep 11, 2013 at 11:42 AM, R.S. <r.skoru...@bremultibank.com.pl>wrote: > W dniu 2013-09-11 11:17, Timothy Sipples pisze: > >> Radoslaw Skorupka writes: >> >>> Although PCI-DSS does not mention explicitly NTP, but this is the only >>> solution for mainframe, which in turn requires STP enablement, which >>> means $$$, which is quite unique among other platforms, because others >>> can act as NTP client for free. >>> >> No, you cannot assume that. >> > Yes I can, unless you present other existing option. > > [...] It depends on the definitions of words like "protected," >> "correct," "consistent," and "trusted." "Free" NTP might not be any/most >> of >> those things, particularly in certain non-mainframe virtualized >> environments. >> > There are free time sources which can be considered as consistent and > tursted - like German goverment-supported time (FM signal), polish GUM > servers (official "measurement" authoririty - they provide official > standards for kg, second, meter, etc.) or just GPS. I can prove it in any > court. > > By the way, I'm rather tired of the implicit and explicit criticisms that >> Server Time Protocol (STP) has a separate charge. >> > So get rest. > >> So it does. So what? >> > Maybe some holidays? > > If you need STP, include its cost in your budgeting, negotiate, and/or >> make >> whatever decisions you want to make, [...] >> > WRONG. I don't need STP. Vast majority of shops I know do not need STP (no > sysplex there). However majority of them would be happy to have NTP. And > ANY OTHER SYSTEM OR PLATFORM CAN BE NTP CLIENT FOR FREE. > That's why people repeat: "MAINFRAME IS EXPENSIVE". "MAINFRAME IS COMPLEX". > It is expensive to pay few dozens k$ for NTP. Note in the times of Sysplex > Timer it was 2x50k = 100k$ (2x - for redundancy). > It is quite complex to set up the NTP, although it's not rocket science. > It generates a lot of HW messages, which cannot be supressed even if you > don't care about it (stratum change for any of NTP servers). > I'm rather tired of the continuous signals and proofs why the mainframe is > expensive and complex and fading away. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > -- > Tre tej wiadomo ci mo e zawiera informacje prawnie chronione Banku > przeznaczone wy cznie do u ytku s u bowego adresata. Odbiorc mo e by > jedynie jej adresat z wy czeniem dost pu osób trzecich. Je eli nie jeste > adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej > przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, > rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie > zabronione i mo e by karalne. Je eli otrzyma e t wiadomo omy kowo, > prosimy niezw ocznie zawiadomi nadawc wysy aj c odpowied oraz trwale > usun t wiadomo w czaj c w to wszelkie jej kopie wydrukowane lub > zapisane na dysku. > > This e-mail may contain legally privileged information of the Bank and is > intended solely for business use of the addressee. This e-mail may only be > received by the addressee and may not be disclosed to any third parties. If > you are not the intended addressee of this e-mail or the employee > authorised to forward it to the addressee, be advised that any > dissemination, copying, distribution or any other similar activity is > legally prohibited and may be punishable. If you received this e-mail by > mistake please advise the sender immediately by using the reply facility in > your e-mail software and delete permanently this e-mail including any > copies of it either printed or saved to hard drive. > BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, > fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl > S d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego > Rejestru S dowego, nr rejestru przedsi biorców KRS 0000025237, NIP: > 526-021-50-88. Wed ug stanu na dzie 01.01.2013 r. kapita zak adowy BRE > Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych. > > > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- As of next week, passwords will be entered in Morse code. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
