Вторник, 26.09.2017, 23:05
Приветствую Вас Гость | RSS
Главная | Эмулятор для промышленной системы - Форум | Регистрация | Вход
Форма входа
Логин:
Пароль:
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Страница 1 из 212»
Форум » Технические форумы » Hercules » Эмулятор для промышленной системы
Эмулятор для промышленной системы
AlexVДата: Четверг, 23.05.2013, 15:52 | Сообщение # 1
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Привет всем!
 
Возник такой вопрос. Владелец мэйнфрейма желает перевести все работы на куда-то там (не важно). При этом или не справляется или поняли, что сильно много проблем... В общем желание избавиться от мэйнфрема остаётся, но при этом работу систем поддерживать нужно.
В итоге зародилась мысль перевести промышленную систему на эмулятор... По крайней мере до нас дошли такие идеи.
Вот хотелось бы знать, действительно ли есть вариант перевода под эмулятор, так что б это нормально работало (в смысле - не побаловаться, а на уровне поддержки промышленной системы)?
 
Работает IMS. Приложения на Коболе. Причём, судя по теперешней работе - загрузка достаточно приличная. Машина уровня z-900, средняя загрука порядка 40-60%.
 
GregoryДата: Четверг, 23.05.2013, 17:33 | Сообщение # 2
Генерал-майор
Группа: Доверенные
Сообщений: 304
Репутация: 7
Статус: Offline
Цитата (AlexV)
действительно ли есть вариант перевода под эмулятор, так что б это нормально работало (в смысле - не побаловаться, а на уровне поддержки промышленной системы)?
Я так понимаю, что прежде всего волнуют вопросы производительности и заявленные оценки производительности эмуляторов Вам известны. Учитывая то, что перенос системы на эмулятор задача, конечно не самая легкая, но и не бог весть какая сложная, я бы предложил попробовать, например под Hercules, то есть перенести образы существующих дисков и попытаться взлетать. Какие эмуляторы рассматриваете? Hercules, zPDT?
 
akostДата: Четверг, 23.05.2013, 18:30 | Сообщение # 3
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
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
 
GregoryДата: Четверг, 23.05.2013, 19:01 | Сообщение # 4
Генерал-майор
Группа: Доверенные
Сообщений: 304
Репутация: 7
Статус: Offline
Цитата (akost)
Если 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
 
akostДата: Пятница, 24.05.2013, 08:42 | Сообщение # 5
Admin
Группа: Администраторы
Сообщений: 473
Репутация: 4
Статус: Offline
Gregory, опять же соглашусь с приведенным.
С единственной оговоркой - сказанное мною было просто частным результатом, чтобы, так сказать, было от чего оттолкнуться. А решение о том, подходит ли эмулятор и насколько он просядет (или наоборот, выиграет) по сравнению с конкретной установкой, надо уже принимать по результатам модельных испытаний.
В подтверждение этого -
Цитата (Gregory)
Если, например, эта система есть некая пакетная обработка, которая на z900 выполняется, скажем, за два часа, а под Hercules будет выполняться за 10 часов, это все еще может быть приемлемо с практической точки зрения в какой-то конкретной ситуации. Если это некая интерактивная система, и время ответа возрастет от 0 до 30 сек. это тоже может быть приемлемо, и для TPS падение transaction/sec в 10 раз тоже может быть все еще перевариваемым...
после переноса пакетной нагрузки на Геркулес регламенты отработались вместо 45 минут за 5 часов с небольшим.  И никого это не напрягло, все равно запускается ночью, и результат выкладывается в сеть, и все счастливы, хотя деградация налицо.
 
AlexVДата: Пятница, 24.05.2013, 10:20 | Сообщение # 6
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Цитата (Gregory)
Учитывая то, что перенос системы на эмулятор задача, конечно не самая легкая, но и не бог весть какая сложная, я бы предложил попробовать, например под Hercules, то есть перенести образы существующих дисков и попытаться взлетать. Какие эмуляторы рассматриваете? Hercules, zPDT?


Спасибо за отклики.
Понятно, что результат переноса - штука индивидуальная. К сожалению, подробности мне не известны. До нас доходят только отголоски дебатов, что происходят в США.
 
Если чуть более подробно, то история такова. Вчера несколько не хватило времени на подробности...
 
Почему-то у руководства компании возникла идея уйти от МФ (мэйнфрейм).
Тут же появился некий весёлый парень, который заявил, типа "перевести систему - да легко". Тут же сварганил тестовую програмку, что-то там поэкспериментили и пришли к выводу, что "вперёд".
Когда встал вопрос, каким образом будем миллионы строк Кобола конвертировать в С#, стали искать конверторы. Немного погодя выяснилось, что конверторы конвертят не сильно хорошо. В частности, в Коболе сплошником идут переопределения одной и той же области памяти, каждое из определений используется в разных операциях. Конвертор это воспринимает болезненно. После продолжительной совместной работы с авторами конвертора, эту идею, как я понял, оставили. Решили писать всё с "нуля".
Но возник вопрос с персоналом, кто будет этим заниматься и кто будет разрабатывать спецификации.
У авторов новой концепции отношения со специалистами по работающей системе не сложились. Так же они не желают подпускать к разработке сторонних разработчиков (типа нас).
В итоге известно только что, языком новой системы будет C#. Что и как относительно всего остального - тёмен лес. Но денег на новые разработки потрачено уже не мало (к тому же чувствуется лоббирование), то отказываться от переноса не собираются.
 
Из-за возникших трудностей, которые уже продолжаются года полтора и которым конца-края не видать, возникла промежуточная идея (а может и нет) - перевести существующую систему под эмулятор. Скорее всего, авторы новой концепции что-то слышали про возможность эмуляции zOS... но в лучшем случае только пробовали что-то там запускать. (Насколько я понял, они вообще ранее дела с МФ не имели).
 
Немного по режиму работы системы.
Основная работа - выработка отчётов в батч режиме. Но отчётов - до фига и больше, что-то порядка полутора сотен. Для каждого - своё задание. Запускаются каждую ночь (но есть надежда, что не все). Наработка одного отчёта - от минуты до трёх (очень ориентировочно).
Но есть и режим он-лайн. В этом режиме так же генерятся некоторые отчёты (которых намного меньше). Подготовка данных и работа с базой так же ведётся в он-лайн.

В принципе, нам с нашими американскими другами хотелось бы как-то вклиниться в процесс разработки (пока что имеющую практический опыт работы с довольно сложной системой группу специалистов активно оттесняют, а с ними - и нас.). Трата денег на фикс-идеи автоматически урезает наш бюджет. Потому, конечно же, хотелось бы собрать максимум информации, что б предложить какой-то рабочий вариант. На два-три года работы в любом случае хватит, но хотелось бы иметь более дальнюю перспективу.
 
XOpenДата: Пятница, 24.05.2013, 11:47 | Сообщение # 7
Генерал-майор
Группа: Администраторы
Сообщений: 322
Репутация: 4
Статус: Offline
Я бы предложил поиграть в их игры. Выйти с красивой идеей, поработать годик-другой, потом сказать что нужна новая идея и тд...
Начать можно с:
http://docs.oracle.com/cd....ce.html
Это ПС решение для эмуляции не z/OS, но работы JCL в связке с Cobol. Звучит красиво.
 
AlexVДата: Пятница, 24.05.2013, 11:58 | Сообщение # 8
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Цитата (XOpen)
Это ПС решение для эмуляции не z/OS, но работы JCL в связке с Cobol.


Спасибо, посмотрю. Хотя не понятно, как быть с базой и прочим хозяйством...
 
GregoryДата: Пятница, 24.05.2013, 12:58 | Сообщение # 9
Генерал-майор
Группа: Доверенные
Сообщений: 304
Репутация: 7
Статус: Offline
Цитата (AlexV)
Когда встал вопрос, каким образом будем миллионы строк Кобола конвертировать в С#, стали искать конверторы. Немного погодя выяснилось, что конверторы конвертят не сильно хорошо.
не реально smile

Цитата (AlexV)
Решили писать всё с "нуля".
абсолютно не реально biggrin

Цитата (AlexV)
возник вопрос с персоналом, кто будет этим заниматься и кто будет разрабатывать спецификации.
У авторов новой концепции отношения со специалистами по работающей системе не сложились.
вот именно это ставит крест на всей дальнейшей деятельности, а не различия в используемых языках/системах/платформах. Доказано не раз. Результат предсказуем - денег потратят немеряно, а разработанное ПО, даже если таковое появится, будет не в состоянии заменить существующее со всеми вытекающими последствиями.


Сообщение отредактировал Gregory - Пятница, 24.05.2013, 12:59
 
AlexVДата: Пятница, 24.05.2013, 13:25 | Сообщение # 10
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Цитата (Gregory)
Результат предсказуем - денег потратят немеряно, а разработанное ПО, даже если таковое появится, будет не в состоянии заменить существующее со всеми вытекающими последствиями.


"И я того же мнения..." (с)
Однако руководству компании крепко эта идея засела в голову. В смысле - уход от МФ. Не знаю, может проблема с финансированием, може специалисты уходят на пенсию, а новых нет...
Так или иначе, нам рисуют перспективу закрытия проекта, после перехода "куда-то там". Под это дело уже сейчас сокращают финансирование...
А всё идёт к тому, что из этих попыток либо вообще ничего не получится, либо получится "чёрт те что и с боку бантик".
 
В общем, нужно грамотно объяснить нашим другам-американцам пагубность подобных телодвижений.
Вот пока что пробую собрать необходимую инфу.
 
drblezДата: Суббота, 25.05.2013, 12:42 | Сообщение # 11
Сержант
Группа: Доверенные
Сообщений: 37
Репутация: 2
Статус: Offline
Цитата (Gregory)
Результат предсказуем - денег потратят немеряно, а разработанное ПО, даже если таковое появится, будет не в состоянии заменить существующее со всеми вытекающими последствиями.

плюспицот...

Я сталкивался пару раз с таким. К нам пришли пупсики и предложили перенести  проектирование форм для литья с 1046 на 386-е. По производительности они были явно лучше. И одну задачу решали достаточно быстро. Но то, что делалось параллельно на 1046, приходилось делать последовательно на 386-й, ибо не справлялось. Ну а про недостаток функционала и постоянное допиливание -- промолчу ))

Потом я уволился, и дальше знаю, что 1046 поменяли на 3 (ТРИ) персоналки и проектирование форм зачахло )) но тогда и завод зачах, видимо им хватало
 
artДата: Пятница, 31.05.2013, 01:57 | Сообщение # 12
Лейтенант
Группа: Доверенные
Сообщений: 60
Репутация: 3
Статус: Offline
Цитата (AlexV)
Работает IMS. Приложения на Коболе.
Я так понял это какой-то американский заказчик. Если есть желание то могу попробовать пробить по своим каналам кто там с ними работает и в чем конкретно проблема. Тогда в ЛС.

По поводу Tuxedo. Эта идея, как правильно сказали, нужна только чтобы осваивать бюджеты. IBM в свое время наглядно показывал, что не работает это нормально. Появляются какие-то ошибки памяти, при этом дебажить практически невозможно в виду отсутствия тулзов. Может Оракл конечно дописал чего - давно не смотрел.

Если клиента сильно заботит проблема персонала, а не какие-то другие политические аспекты, и они не готовы обучать людей (кобол очень простой язык ведь по факту, куда проще всяких объектников), то вариантом может стать разворачивание iLOG BRMS (Business Rule Management System) или EGL. Чтобы писать и поддерживать код на очень верхнеуровнем языке (даже не языке, а наборе бизнес правил) могли бы даже полные ИТ-идиоты, а потом бы это автоматически разворачивалось в эффективный язык платформы.
 
GregoryДата: Пятница, 31.05.2013, 18:48 | Сообщение # 13
Генерал-майор
Группа: Доверенные
Сообщений: 304
Репутация: 7
Статус: Offline
как я уже высказывался в посте #9, проблема вовсе не в смене платформы и инструментов разработки, а в том, что разработка будет делаться заново в условиях отсутствия требований. Если даже какие-то требования и спецификации для старого ПО удалось найти, они, скорее всего, неактуальны, то есть работающее ПО ими не
описывается. И в то же время у менеджмента, да и у разработчиков тоже, имеется ложное представление, что этап управления требованиями (requirement management) не нужен и его можно пропустить.

Дальнейшая схема будет выглядеть примерно так: разработчики смотрят кобольные исходные модули, чтобы выудить из кода спецификации, а затем выразить их на каком-нибудь c#, java и т.д. Очень быстро выясниться, что получается это плохо, а ответы на любые вопросы типа "почему это так?", "зачем это вообще?" и т.д.
получить негде, так как даже если и доступны люди, которые могли бы на эти вопросы ответить, они по совершенно понятным причинам отвечать на них не будут...  Воспроизведение непонятной логики закономерно приведет к печальным результатам.


Сообщение отредактировал Gregory - Суббота, 01.06.2013, 11:54
 
AlexVДата: Среда, 26.06.2013, 09:45 | Сообщение # 14
Лейтенант
Группа: Проверенные
Сообщений: 57
Репутация: 0
Статус: Offline
Заказчик выбирает один из двух вариантов:
 
MicroFocus Enterprise Server
Dell BPE/TPE formally known as Unikix (Clerity).
 
Пока изучаю первый вариант.
А кто-то близко знаком (имел дело) с этими?

Добавлено (26.06.2013, 09:45)
---------------------------------------------
Мимоходом возник дурацкий вопрос.
Допустим, перенесли Зосю под умулятор... А с лицензией как быть?

 
GregoryДата: Среда, 26.06.2013, 14:26 | Сообщение # 15
Генерал-майор
Группа: Доверенные
Сообщений: 304
Репутация: 7
Статус: Offline
Цитата (AlexV)
Мимоходом возник дурацкий вопрос.
Допустим, перенесли Зосю под умулятор... А с лицензией как быть?
Вопрос вовсе не дурацкий, а ответ зависит от эмулятора. Для 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." То есть, такую траву нельзя не только курить, но даже и хранить sad


Сообщение отредактировал Gregory - Среда, 26.06.2013, 14:36
 
Форум » Технические форумы » Hercules » Эмулятор для промышленной системы
Страница 1 из 212»
Поиск: