Возник такой вопрос. Владелец мэйнфрейма желает перевести все работы на куда-то там (не важно). При этом или не справляется или поняли, что сильно много проблем... В общем желание избавиться от мэйнфрема остаётся, но при этом работу систем поддерживать нужно. В итоге зародилась мысль перевести промышленную систему на эмулятор... По крайней мере до нас дошли такие идеи. Вот хотелось бы знать, действительно ли есть вариант перевода под эмулятор, так что б это нормально работало (в смысле - не побаловаться, а на уровне поддержки промышленной системы)?
Работает IMS. Приложения на Коболе. Причём, судя по теперешней работе - загрузка достаточно приличная. Машина уровня z-900, средняя загрука порядка 40-60%.
действительно ли есть вариант перевода под эмулятор, так что б это нормально работало (в смысле - не побаловаться, а на уровне поддержки промышленной системы)?
Я так понимаю, что прежде всего волнуют вопросы производительности и заявленные оценки производительности эмуляторов Вам известны. Учитывая то, что перенос системы на эмулятор задача, конечно не самая легкая, но и не бог весть какая сложная, я бы предложил попробовать, например под Hercules, то есть перенести образы существующих дисков и попытаться взлетать. Какие эмуляторы рассматриваете? Hercules, zPDT?
Gregory, вы абсолютно правы. Точно можно сказать только потратив немного времени и переведя на Геркулес. Но скажу свой личный опыт. Если z900 даже однопроцессорная загружена на 50-60%, и есть более 100 SIO в секунду, то эмулятор не потянет. Года два назад меряли и профилировали систему для одного заказчика в качестве откатного центра. Так вот Геркулес дал характеристики (на актуальном 4-процессорном сервере с RAID) около 20 MIPS при 200-400 SIO. Это где-то в 2 раза лучше, чем ЕС ЭВМ 1066, даже с z800 с ее 170 MIPS не тягается. А когда растет ввод-вывод, то вообще туши свет. Это исключительно личный опыт, на частных приложениях конкретного заказчика на 31-битной OS/390 и VM/ESA 2.4
Если z900 даже однопроцессорная загружена на 50-60%, и есть более 100 SIO в секунду, то эмулятор не потянет. Года два назад меряли и профилировали систему для одного заказчика в качестве откатного центра. Так вот Геркулес дал характеристики (на актуальном 4-процессорном сервере с RAID) около 20 MIPS при 200-400 SIO. Это где-то в 2 раза лучше, чем ЕС ЭВМ 1066, даже с z800 с ее 170 MIPS не тягается.А когда растет ввод-вывод, то вообще туши свет.
это, безусловно, верно. но для того, чтобы сказать "пойдет" или "не пойдет", важны не MIPSы и не SIO как таковые, а характеристика производительности всей прикладной системы. Если, например, эта система есть некая пакетная обработка, которая на z900 выполняется, скажем, за два часа, а под Hercules будет выполняться за 10 часов, это все еще может быть приемлемо с практической точки зрения в какой-то конкретной ситуации. Если это некая интерактивная система, и время ответа возрастет от 0 до 30 сек. это тоже может быть приемлемо, и для TPS падение transaction/sec в 10 раз тоже может быть все еще перевариваемым... Пр этом нужно иметь в виду, что деградация системы по-видимому будет нелинейной...
Сообщение отредактировал Gregory - Чт, 23.05.2013, 19:04
Gregory, опять же соглашусь с приведенным. С единственной оговоркой - сказанное мною было просто частным результатом, чтобы, так сказать, было от чего оттолкнуться. А решение о том, подходит ли эмулятор и насколько он просядет (или наоборот, выиграет) по сравнению с конкретной установкой, надо уже принимать по результатам модельных испытаний. В подтверждение этого -
Цитата (Gregory)
Если, например, эта система есть некая пакетная обработка, которая на z900 выполняется, скажем, за два часа, а под Hercules будет выполняться за 10 часов, это все еще может быть приемлемо с практической точки зрения в какой-то конкретной ситуации. Если это некая интерактивная система, и время ответа возрастет от 0 до 30 сек. это тоже может быть приемлемо, и для TPS падение transaction/sec в 10 раз тоже может быть все еще перевариваемым...
после переноса пакетной нагрузки на Геркулес регламенты отработались вместо 45 минут за 5 часов с небольшим. И никого это не напрягло, все равно запускается ночью, и результат выкладывается в сеть, и все счастливы, хотя деградация налицо.
Учитывая то, что перенос системы на эмулятор задача, конечно не самая легкая, но и не бог весть какая сложная, я бы предложил попробовать, например под Hercules, то есть перенести образы существующих дисков и попытаться взлетать. Какие эмуляторы рассматриваете? Hercules, zPDT?
Спасибо за отклики. Понятно, что результат переноса - штука индивидуальная. К сожалению, подробности мне не известны. До нас доходят только отголоски дебатов, что происходят в США.
Если чуть более подробно, то история такова. Вчера несколько не хватило времени на подробности...
Почему-то у руководства компании возникла идея уйти от МФ (мэйнфрейм). Тут же появился некий весёлый парень, который заявил, типа "перевести систему - да легко". Тут же сварганил тестовую програмку, что-то там поэкспериментили и пришли к выводу, что "вперёд". Когда встал вопрос, каким образом будем миллионы строк Кобола конвертировать в С#, стали искать конверторы. Немного погодя выяснилось, что конверторы конвертят не сильно хорошо. В частности, в Коболе сплошником идут переопределения одной и той же области памяти, каждое из определений используется в разных операциях. Конвертор это воспринимает болезненно. После продолжительной совместной работы с авторами конвертора, эту идею, как я понял, оставили. Решили писать всё с "нуля". Но возник вопрос с персоналом, кто будет этим заниматься и кто будет разрабатывать спецификации. У авторов новой концепции отношения со специалистами по работающей системе не сложились. Так же они не желают подпускать к разработке сторонних разработчиков (типа нас). В итоге известно только что, языком новой системы будет C#. Что и как относительно всего остального - тёмен лес. Но денег на новые разработки потрачено уже не мало (к тому же чувствуется лоббирование), то отказываться от переноса не собираются.
Из-за возникших трудностей, которые уже продолжаются года полтора и которым конца-края не видать, возникла промежуточная идея (а может и нет) - перевести существующую систему под эмулятор. Скорее всего, авторы новой концепции что-то слышали про возможность эмуляции zOS... но в лучшем случае только пробовали что-то там запускать. (Насколько я понял, они вообще ранее дела с МФ не имели).
Немного по режиму работы системы. Основная работа - выработка отчётов в батч режиме. Но отчётов - до фига и больше, что-то порядка полутора сотен. Для каждого - своё задание. Запускаются каждую ночь (но есть надежда, что не все). Наработка одного отчёта - от минуты до трёх (очень ориентировочно). Но есть и режим он-лайн. В этом режиме так же генерятся некоторые отчёты (которых намного меньше). Подготовка данных и работа с базой так же ведётся в он-лайн.
В принципе, нам с нашими американскими другами хотелось бы как-то вклиниться в процесс разработки (пока что имеющую практический опыт работы с довольно сложной системой группу специалистов активно оттесняют, а с ними - и нас.). Трата денег на фикс-идеи автоматически урезает наш бюджет. Потому, конечно же, хотелось бы собрать максимум информации, что б предложить какой-то рабочий вариант. На два-три года работы в любом случае хватит, но хотелось бы иметь более дальнюю перспективу.
Я бы предложил поиграть в их игры. Выйти с красивой идеей, поработать годик-другой, потом сказать что нужна новая идея и тд... Начать можно с: http://docs.oracle.com/cd....ce.html Это ПС решение для эмуляции не z/OS, но работы JCL в связке с Cobol. Звучит красиво.
Когда встал вопрос, каким образом будем миллионы строк Кобола конвертировать в С#, стали искать конверторы. Немного погодя выяснилось, что конверторы конвертят не сильно хорошо.
не реально
Цитата (AlexV)
Решили писать всё с "нуля".
абсолютно не реально
Цитата (AlexV)
возник вопрос с персоналом, кто будет этим заниматься и кто будет разрабатывать спецификации. У авторов новой концепции отношения со специалистами по работающей системе не сложились.
вот именно это ставит крест на всей дальнейшей деятельности, а не различия в используемых языках/системах/платформах. Доказано не раз. Результат предсказуем - денег потратят немеряно, а разработанное ПО, даже если таковое появится, будет не в состоянии заменить существующее со всеми вытекающими последствиями.
Сообщение отредактировал Gregory - Пт, 24.05.2013, 12:59
Результат предсказуем - денег потратят немеряно, а разработанное ПО, даже если таковое появится, будет не в состоянии заменить существующее со всеми вытекающими последствиями.
"И я того же мнения..." (с) Однако руководству компании крепко эта идея засела в голову. В смысле - уход от МФ. Не знаю, может проблема с финансированием, може специалисты уходят на пенсию, а новых нет... Так или иначе, нам рисуют перспективу закрытия проекта, после перехода "куда-то там". Под это дело уже сейчас сокращают финансирование... А всё идёт к тому, что из этих попыток либо вообще ничего не получится, либо получится "чёрт те что и с боку бантик".
В общем, нужно грамотно объяснить нашим другам-американцам пагубность подобных телодвижений. Вот пока что пробую собрать необходимую инфу.
Результат предсказуем - денег потратят немеряно, а разработанное ПО, даже если таковое появится, будет не в состоянии заменить существующее со всеми вытекающими последствиями.
плюспицот...
Я сталкивался пару раз с таким. К нам пришли пупсики и предложили перенести проектирование форм для литья с 1046 на 386-е. По производительности они были явно лучше. И одну задачу решали достаточно быстро. Но то, что делалось параллельно на 1046, приходилось делать последовательно на 386-й, ибо не справлялось. Ну а про недостаток функционала и постоянное допиливание -- промолчу ))
Потом я уволился, и дальше знаю, что 1046 поменяли на 3 (ТРИ) персоналки и проектирование форм зачахло )) но тогда и завод зачах, видимо им хватало
Я так понял это какой-то американский заказчик. Если есть желание то могу попробовать пробить по своим каналам кто там с ними работает и в чем конкретно проблема. Тогда в ЛС.
По поводу Tuxedo. Эта идея, как правильно сказали, нужна только чтобы осваивать бюджеты. IBM в свое время наглядно показывал, что не работает это нормально. Появляются какие-то ошибки памяти, при этом дебажить практически невозможно в виду отсутствия тулзов. Может Оракл конечно дописал чего - давно не смотрел.
Если клиента сильно заботит проблема персонала, а не какие-то другие политические аспекты, и они не готовы обучать людей (кобол очень простой язык ведь по факту, куда проще всяких объектников), то вариантом может стать разворачивание iLOG BRMS (Business Rule Management System) или EGL. Чтобы писать и поддерживать код на очень верхнеуровнем языке (даже не языке, а наборе бизнес правил) могли бы даже полные ИТ-идиоты, а потом бы это автоматически разворачивалось в эффективный язык платформы.
как я уже высказывался в посте #9, проблема вовсе не в смене платформы и инструментов разработки, а в том, что разработка будет делаться заново в условиях отсутствия требований. Если даже какие-то требования и спецификации для старого ПО удалось найти, они, скорее всего, неактуальны, то есть работающее ПО ими не описывается. И в то же время у менеджмента, да и у разработчиков тоже, имеется ложное представление, что этап управления требованиями (requirement management) не нужен и его можно пропустить.
Дальнейшая схема будет выглядеть примерно так: разработчики смотрят кобольные исходные модули, чтобы выудить из кода спецификации, а затем выразить их на каком-нибудь c#, java и т.д. Очень быстро выясниться, что получается это плохо, а ответы на любые вопросы типа "почему это так?", "зачем это вообще?" и т.д. получить негде, так как даже если и доступны люди, которые могли бы на эти вопросы ответить, они по совершенно понятным причинам отвечать на них не будут... Воспроизведение непонятной логики закономерно приведет к печальным результатам.
Сообщение отредактировал Gregory - Сб, 01.06.2013, 11:54
MicroFocus Enterprise Server Dell BPE/TPE formally known as Unikix (Clerity).
Пока изучаю первый вариант. А кто-то близко знаком (имел дело) с этими?
Добавлено (26.06.2013, 09:45) --------------------------------------------- Мимоходом возник дурацкий вопрос. Допустим, перенесли Зосю под умулятор... А с лицензией как быть?
Мимоходом возник дурацкий вопрос. Допустим, перенесли Зосю под умулятор... А с лицензией как быть?
Вопрос вовсе не дурацкий, а ответ зависит от эмулятора. Для zPDT лицензирование возможно, для Hercules - нет. Эти вопросы широко обсуждаются, например, здесь ibm-legacy-hercules
кстати: "...a number of IBM employees globally have downloaded and are using Hercules open-source System z architecture emulators on IBM workstations. Hercules software, however, is prohibited for IBM internal use." То есть, такую траву нельзя не только курить, но даже и хранить
Сообщение отредактировал Gregory - Ср, 26.06.2013, 14:36
