хронология команд
May. 25th, 2017 08:27 amОх и люблю же я что-нибудь такое сделать, чтобы ничего не делать. :) Ну, почти ничего не делать. Т.с.
воспользоваться былыми результатами повторно. :)
Есть на станции такие файлы, в которые она сохраняет команды между дампами. Зовут их RELCMDHDF, если что.
Новые создаются при каждом дампе, старые становятся не нужными и если специально не пошевелиться, плодятся годами. Место поедают, конечно, но файлы, в общем-то, не большие. Впрочем, технология выделения дискового пространства там чуточку другая, из-за чего места занимать они могут гораздо больше, чем реально используют. Если станция не сильно старая, то проблема нехватки места может так и не наступить. Скорее станцию заменят. :D
Но вот в рамках эксплуатации могут возникать сложности. Работает там конструкция типа кластера и в случае смены активного узла происходит синхронизация дисков. Сначала будет попытка сделать быстрый апдейт - только того, что изменилось после того как узел находился в забытьи. Если не получилось и процесс затягивается, то происходит переключение на длинный апдейт, то есть тупая синхронизация всего подряд, чуть ли не по кластерам. И чем больше всяких файлов валяется, тем вероятнее переключение на длинный процесс. Поэтому много лет назад, приехавший настройщик, тяжело вздохнут собрался поудалять древние файлы. Хорошо что он ленился. Я тогда про них ещё ничего не знал, а как узнал какое богатство собираются удалять, спохватился и уговорил что сам всё сделаю. Товарищ, конечно, обрадовался, потому что автоматизировать рутинные операции не умел, а команд вводить пришлось бы долго. А тут ему предлагают ничего не делать, но работа при этом сделается. В итоге, файлы эти я скачал, и только после этого удалил те что надо. Потом уже сделал нужные настройки, чтобы станция сама эти файлы и через даталинк отправляла, и удаляла старые. В результате получил архив вносившихся в станционные данные изменений. Зачем? Очень удобно отыскивать когда нечто делалось. Например, возникает вопрос: имеется странный маршрут, зачем и почему он сделан таким? Идеальным был бы электронный журнал, хоть и требовал бы дополнительных телодвижений на протоколирование всего подряд. Но начиналась эта работа слишком давно. Есть два шкафа толстых папок распоряжений, по которым эти изменения вносились. Но когда? И вот тут на помощь приходит RELCMDHDF.
Долгое время пользовался простым grep-ом. Потом прикрутил врапер для удобства. Со временем к враперу прикрутил отыскивание по TRLOG1FILE, в который вообще все диалоги со станцией пишу. Собирался было прикрутить скрипт на веб-страницу, но задумался … и решил, что нужно грузить всё это в БД. Глаза боятся, а руки делают.
В результате получил возможность быстрого поиска, удобного доступа (и не только мне), и сводной таблицы.
Сотрудники тоже оценили фичу. Теперь даже непонятно как можно было без этого обходиться. :)
И вот ещё одна станция оказалась под рукой. Всё ходил вокруг неё, облизывался. Вот только в отличие от нашей, доступа к даталинку нет. А без него файлы качать только через IOFAT. А это не совсем файлы. Точнее, чтобы получить оригинал, нужно его обработать. Старые командники оттуда таким образом я уже давно вытащил. Нужное искал обычным грепом, но это же оскорбляет эстетическое чувство. И вот вчера наконец набросал конвертилку из IOFAT в оригинальные файлики. Таблицы в базе, оказывается, я уже давно сделал и даже скрипты готовы. Так что осталось это дело только загрузить. Класс! Теперь только нюансы отлаживаю. То командные строки оказываются чрезмерно длинные. То внутриблочные счётчики команд решил вернуть.
В общем, сделал один раз, а удовольствие приносит многократно.
воспользоваться былыми результатами повторно. :)
Есть на станции такие файлы, в которые она сохраняет команды между дампами. Зовут их RELCMDHDF, если что.
Новые создаются при каждом дампе, старые становятся не нужными и если специально не пошевелиться, плодятся годами. Место поедают, конечно, но файлы, в общем-то, не большие. Впрочем, технология выделения дискового пространства там чуточку другая, из-за чего места занимать они могут гораздо больше, чем реально используют. Если станция не сильно старая, то проблема нехватки места может так и не наступить. Скорее станцию заменят. :D
Но вот в рамках эксплуатации могут возникать сложности. Работает там конструкция типа кластера и в случае смены активного узла происходит синхронизация дисков. Сначала будет попытка сделать быстрый апдейт - только того, что изменилось после того как узел находился в забытьи. Если не получилось и процесс затягивается, то происходит переключение на длинный апдейт, то есть тупая синхронизация всего подряд, чуть ли не по кластерам. И чем больше всяких файлов валяется, тем вероятнее переключение на длинный процесс. Поэтому много лет назад, приехавший настройщик, тяжело вздохнут собрался поудалять древние файлы. Хорошо что он ленился. Я тогда про них ещё ничего не знал, а как узнал какое богатство собираются удалять, спохватился и уговорил что сам всё сделаю. Товарищ, конечно, обрадовался, потому что автоматизировать рутинные операции не умел, а команд вводить пришлось бы долго. А тут ему предлагают ничего не делать, но работа при этом сделается. В итоге, файлы эти я скачал, и только после этого удалил те что надо. Потом уже сделал нужные настройки, чтобы станция сама эти файлы и через даталинк отправляла, и удаляла старые. В результате получил архив вносившихся в станционные данные изменений. Зачем? Очень удобно отыскивать когда нечто делалось. Например, возникает вопрос: имеется странный маршрут, зачем и почему он сделан таким? Идеальным был бы электронный журнал, хоть и требовал бы дополнительных телодвижений на протоколирование всего подряд. Но начиналась эта работа слишком давно. Есть два шкафа толстых папок распоряжений, по которым эти изменения вносились. Но когда? И вот тут на помощь приходит RELCMDHDF.
Долгое время пользовался простым grep-ом. Потом прикрутил врапер для удобства. Со временем к враперу прикрутил отыскивание по TRLOG1FILE, в который вообще все диалоги со станцией пишу. Собирался было прикрутить скрипт на веб-страницу, но задумался … и решил, что нужно грузить всё это в БД. Глаза боятся, а руки делают.
В результате получил возможность быстрого поиска, удобного доступа (и не только мне), и сводной таблицы.
Сотрудники тоже оценили фичу. Теперь даже непонятно как можно было без этого обходиться. :)
И вот ещё одна станция оказалась под рукой. Всё ходил вокруг неё, облизывался. Вот только в отличие от нашей, доступа к даталинку нет. А без него файлы качать только через IOFAT. А это не совсем файлы. Точнее, чтобы получить оригинал, нужно его обработать. Старые командники оттуда таким образом я уже давно вытащил. Нужное искал обычным грепом, но это же оскорбляет эстетическое чувство. И вот вчера наконец набросал конвертилку из IOFAT в оригинальные файлики. Таблицы в базе, оказывается, я уже давно сделал и даже скрипты готовы. Так что осталось это дело только загрузить. Класс! Теперь только нюансы отлаживаю. То командные строки оказываются чрезмерно длинные. То внутриблочные счётчики команд решил вернуть.
В общем, сделал один раз, а удовольствие приносит многократно.