Личные впечатления от TWS (был пилотный проект в прощлом году) очень неоднозначные. Да он работает, но конфигурируется достаточно замороченно. Если конфигурить расписание через ISPF это куча экранов и взаимозависимостей. Есть внешний веб-интерфейс, там несколько удобнее, но ИМХО все равно неудобно. Впечатлиться продуктом не получилось.
Если конфигурить расписание через ISPF это куча экранов и взаимозависимостей. Есть внешний веб-интерфейс, там несколько удобнее, но ИМХО все равно неудобно
согласен.
в качестве суррогата TWS aka OPC можно использовать cron в z/OS UNIX. Pro: штатное средство, достаточно простое; Contra - только запуск по регламенту, зависимости придется реализовывать в заданиях
Для реализации зависимости можно использовать технику c "фиктивными" наборами данных, в протых ситуациях это может быть решением. Имеется в виду описание неиспользуемых наборов данных с DISP=OLD/SHR чтобы реализовать зависимость за счет ENQ/DEQ
Сообщение отредактировал Gregory - Пн, 19.09.2011, 19:42
DISP=OLD/SHR чтобы реализовать зависимость за счет ENQ/DEQ
Вот. Настраивать то процесс не часто надо, можно и побродить в панельках. Зато богатство возможностей описания зависимостей. Задание может ждать несколько заданий. (прямая зависимость) Ждать что определенные ресурсы не используются другими заданиями. (не совсем прямая) При этом одни задания могут одновременно пастись в ресурсах, а другие нет. Определённые события, когда процесс запускается при детекте старта совсем другого не TWS задания. (присылали файл по фтп и пускали затем через фтп триггер джоб)
Если конфигурить расписание через ISPF это куча экранов и взаимозависимостей. Есть внешний веб-интерфейс, там несколько удобнее, но ИМХО все равно неудобно.
Да можно через batch всё описать. Быстро и удобно. А то вам всё панельки да окошки подавай...
Да можно через batch всё описать. Быстро и удобно. А то вам всё панельки да окошки подавай...
Именно так мы и делаем))) Правда, для этого есть более веская причина - development, и только он, может описать зависимости, но не может определить регламент, так как не владеет ситуацией в production да и доступ туда имеет строго ограниченный (read-only и то не везде). Support отвечает за production, владеет ситуацией и может планировать регламент, учитывая распределение нагрузки всех приложений, время поступления данных для обработки и время готовности результатов для различных регионов (world-wide). Поэтому development определяет сети пакетно, а support модифицирует их интерактивно. У TWS/OPC действитель большИе возможности, но всегда ли они нужны? Во многих случаях OMVS cron более чем достаточно и зависимости не нужны. Из пушки стрелять по воробьям неразумно...
Да можно через batch всё описать. Быстро и удобно. А то вам всё панельки да окошки подавай... dry
Заказчик хочет наглядности и конфигурабельности Конкретно в их ситуации план исполнения меняется минимум раз в неделю, а менять свои бизнес-процессы в угоду TWS-у они не собираются. Пилотный проект в конечном итоге выполнял IBM, но, насколько мне помнится, так все поставленные вопросы решить не удалось.
Встречались ли кому нибудь замеры, пусть и условные, стоимости выполнения инструкций на z?
Насколько я понимаю, IBM кроме принципов работы ни какой информации о работе z/hw не распространяет. А с 64 битной ESAME, за вычетом ESA, не совсем всё хорошо: - большая часть инструкций включена в facility которые на z/машине могут и отсутствовать. Был сильно удивлён, не обнаружив на довольно таки новой z9 основных: Extended-immediate facility и General-instructions-extension facility. - производительность многих из новых инструкций оставляет желать лучшего. Нашли apar PK05895, описывающий одну из таких ситуаций.
Складывается такое ощущение, что эффективно функционирующее ПО: - функционирует в режиме ESA (инструкции ESA, 31 битная адресация, не использует верхние части регистров) - переходит в режим ESAME , только там где без этого ну, ни как не льзя.
Замеры производительности у них только очень условные, на своих смесях. Эти замеры дают только пищу для ориентировочной оценки мощности процессора на основе таких эмпирических вещей, как "количество коротких CICS-онлайн транзакций", "тяжелые пакетные задания с массивным вводом-выводом" и прочее. Вменяемых и сравнимых с другими платформами TPC-тестов с открытыми кодами мне не встретились, хотя сам я брал пару лет назад в свободное время некие тесты на С и пытался что-то там измерять. Про ESA и ESAME. Около года назад дяденька-индус из IBM кулуарно на мои вопросы "когда же общесистемное ПО станет полноценно 64-битным" сказал: "когда ESAME станет зрелой и выловим там блох". На мой вопрос, когда же это случится, он ответил: "когда это будет настолько нужно рынку, чтобы без этого уже никуда". Так что думаю, что ESAME-возможности будут в состоянии facility еще пару-тройку поколений машин, когда уже другие платформы начнут подпирать.
С некоторых пор относительная стоимость выполнения инструкций потеряла смысл. На разных процессорах многие инструкции выполняются совсем по разному. Это зависит от реализации процессора и также связано с тем, что машинные команды разделяются на два типа "hardcoded" и "millicoded". Millicoded реализованы как последовательность железных команд и располагаются в HSA. Причем наиболее тяжелые состоят из сотен железных и есть даже прецеденты (по слухам), что некоторые hardcoded из предыдущих версий реализованы в новых как millicoded. Скорость выполнения также варьируется в зависимости о кэша процессора, затрат на трансляцию виртуального адреса в реальный (совсем разные при работе в режиме LPAR или под VM), цикла процессора и еще много чего. Так что получить более менее стабильную таблицу затрат времени на инструкцию невозможно. Мне попадалась презентация с SHARE c рекомендациями по программированию на ASM c точки зрения производительности в современных условиях. Так вот они сильно отличаются от тех, что я усвоил в те годы когда программировал на ASM.
