Есть пару вопросов по времени на мейнфремах / z/OS. 1) Насколько точны встроенные часы? Какова может быть разбежка за год без использования синхронизации времени. 2) Есть ли поддержка NTP? Насколько я понял - NTP может использоваться как внешний источник точного времени при использовании STP (Server Time Protocol). Без STP поддержки NTP нету. Так ли это? 3) STP используется для высокоточной синхронизации времени в сисплексе. Если сисплекса нету, как синхронизировать время для отдельного мейфрейма?
Добрый день! а можно попутный вопрос - какая нужна (и главное - для чего?) нужна точность? в свое время IBM рассказывал, что точность нужна только для того, чтобы согласованно гонять банковские транзакции. по сути заданных вопросов 1) у нас за год погрешность не была больше 3 секунд (на 9672-R16). часы не дергали за год ни разу, сравнивали с контроллером домена, который синхронизовал свое время по атомным часам. померяли за 2005 год, больше не повторяли. 2) да (если правильно помню), без STP поддержки NTP нету. но источник не под рукой, если важно, могу поискать. 3) если нет сисплекса, то никак. я баловался в свое время, синхронизуя мейнфрейм с внешними часами через часы SE - там был OS/2, я доставлял свои программульки, а HMC был с 2 сетевыми картами (одна вовне к атомным часам, другая - в сеть HMC-SE). получилось через задницу, ненадежно. перестал этим заниматься.
Спасибо за ответ! Точность времени нужна для "для того, чтобы согласованно гонять банковские транзакции. "
Вот вычитал в Server Time Protocol Planning Guide: NTP client support and support of PPS are available on the z10 EC, z10 BC, z9 EC, and z9 BC configured in an STP-only Coordinated Timing Network.
Получается, для того, чтобы использовать синхронизацию с NTP сервером, надо закупать и активировать STP.
Точность, которую можно получить с использованием NTP сервера как внешнего источника точного времени: –100 milliseconds when using NTP servers without a pulse per second output –10 microseconds when using NTP servers with a pulse per second output –100 milliseconds when using dial-out to a time service from the HMC
Существует программа, которая позволяет синхронизировать время по NTP внутри z/OS без доп. аппаратуры. Однако, с ней есть проблемы, при сдвиге времени назад в некоторых случаях падает СУБД DB2. Поэтому для синхронизации в производстве она, в существующем ее виде, неприменима. Шаг однократного сдвига времени подбирался экспериментально и скорее всего превышает какие то предельные значения. В принципе ее можно дорабатывать, но нужна доп. информация по допустимым значениям сдвига времени. 100% гарантии что все будет работать естественно никто не даст. Все на свой страх и риск. Исходные коды опубликовать не могу, пока не получу разрешения от коллеги, который разработал большую часть этой программы. Написана программа была еще до появления STP, т.к. покупать Sysplex Timer для синхронизации одиночной машины было .... дороговато. Программа помогала выставлять точное время при перезапуске системы. Сейчас ИМХО гораздо надежнее будет докупить лицензию на STP, тем более что нужно гонять банковские операции.
У упомянутой программы действительно есть проблемы. Я начинал её дорабатывать, пытаясь подгонять время постоянно с минимальным шагом. Но там получается сильно сложный алгоритм... Хотя в принципе можно доработать. Но это в общем-то не сильно нужно. Дело в том, что уход часов в самом деле невелик и периодически (положим - раз в месяц) можно останавиливать DB2, запускать синхронизацию (она займёт мало времени), а потом стартовать DB2 опять.
Давно мучает вопрос, как на мейнфрейме делать автоматический переход на летнее время?
Это как раз проще. Есть возможность устанавливать поправку к LOCAL TIME. Но одновременно нужно править PARMLIB! Всё делается запуском одного задания. Само задание запускается либо вручную, либо через автокоманды JES2, или через какую другую прогу, реализующую расписание (таких не мало).
угу, или держать 2 разных пармлиба. Тоесть все равно вручную, просто TWS докупить, чтобы по расписанию. А сколько секунд потратится пока задание распланируется, запустится, выполнится. А вы тут микросекунды считаете. Смешно. В 60х годах что, перехода на летнее время не было? В USS же допилили. Почему в z/OS за столько лет нельзя было что-то сделать?
Тоесть все равно вручную, просто TWS докупить, чтобы по расписанию. А сколько секунд потратится пока задание распланируется, запустится, выполнится.
Вообще-то несколько разные вопросы - перевод времени и обработка событий заданием... Если при переводе вперёд в событиях просто появляется "дырка", то при переводе назад происходит "накладка" событий (предполагаем, что задание работает с локальным временем). Поэтому не придумали ничего лучше, как останавливать системы при переводе назад и ожидать, пока сдвинутое время нагонит...
Вообще перевод времени - дурость. Но это уже отдельная тема. И кстати, в СССР время начали двигать в начале 80-х годов, если не ошибаюсь. В 60-х точно не двигали.
В России летнее время впервые было введено декретом Временного правительства от 1 июля 1917 года. В 1931 году возврат к «зимнему времени» был отменён, и СССР стал жить по «декретному времени» (бывшему летнему), со сдвигом на 1 час, но без ежегодного перевода стрелок. Вновь перевод стрелок был возобновлён с 1 апреля 1981 г. Постановлением Совета министров СССР.[14], но уже относительно декретного времени, так что общий сдвиг летнего времени в России достиг 2 часов.
По правильному, всё должно работать по Гринвичу и только отображение для пользователей в локале. Тогда дырок не будет. Но у людей есть глупая привычка ставить железное время в локальное. Мол операторам на консоле не удобно Гринвич видеть.
Небольшая историческая справка : STP появился только на относительно новых машинах начиная c Z890/Z990 . Для старых процессоров ( начиная с ~ EC9000/9021,9672... до Z10 включительно ) для синхронизации времени использовались ETR-порты и Sysplex Timer-ы ( IBM 9037 ). В IBM 9037 ( это ~ ПЭВМ c OS/2 и Winows 3.11 под ней ) имеется возможность синхронизации с государственными службами точного времени по телефонному модему по протоколам ~ NTP/SNTP хоть по атомным часам... См: http://www.redbooks.ibm.com/abstracts/sg242070.html А также имеются средства настройки перехода на зимнее-летнее время: меняется смещение от Гринвича, т.е. локальное время. Соответственно, этим тоже можно пользоваться в z/OS. Т.е. корректное решение подобных проблем : глобальное время ВСЕГДА по Гринвичу, а локальное - можно менять для удобства операторов.. Главное - потом в листингах, трассах и пр... не путать, где глобальное а где локальное.
