Мы уходим с майнфрайм.

[zVlad]

.... них ведь вроде есть свой клауд (OCI?), который теоретически соптимизирован под их же БД. ...

Интересно как может быть облако соптимизироваno под какую угодно БД и что не могло бы быть сделано в другом облаке? Облако, в моем понимании, это груда комодити серверов (сервисов, приложений) которые продаются в розницу под запросы покупателя услуг облака. Можно конечно преставить себе облако с услугами Oracle БД на SUN технике. Тоже самое с услугами DB2 for zOS и других МФ компонент на МФ. Облако для DB2 for zOS не на МФ представить не возможно. Но можно представить DB2 for LUW в любом облаке с комодити серверами, от кого угодно. Но это не оптимизация, а использование платформы облака на котором может выполнять то или иное ПО.

[iDesperado]

Интересно как может быть облако соптимизироваno под какую угодно БД и что не могло бы быть сделано в другом облаке?

oracle exadata и его хитровывернутый сторидж никто другой не сделает.

[mskmel]

oracle exadata и его хитровывернутый сторидж никто другой не сделает.

flashgrid например, да это не exadata, но тоже очень быстрое:
https://www.flashgrid.io/news/oracle-ra ... t-55-gb-s/

Официально ораклом не поддерживается, но видимо есть способы как-то это всё "эксплуатировать".

[iDesperado]

flashgrid например, да это не exadata, но тоже очень быстрое:
https://www.flashgrid.io/news/oracle-ra ... t-55-gb-s/

фишка exadata в том, что превращает оракл в субд с элементами mpp. там сторидж размазывает чтение по узлам, фильтрует блоки при фулскане например. т.е. ценность exadata не в железячке, а скорее в софте.

[zVlad]

Только что пришло сообщение что проект перехода с МФ остановлен до особого распоряжения. Целевая дата переносится на 2022-ой год.
По тому как это делалось до сих пор меня нисколько не удивляет. По-моему люди не имевшие дел с МФ деградировали настолько что они не способны даже перенести то что на МФ куда-нибудь еще. Я не за всех людей, а только тех с кем общаюсь по этому проекту. Их кстати вовлечено неразумно много. На митингах видишь 10-12 человек из которых только 3-4 о чем то могут вещать. Остальные молчат, но якобы участвуют в проекте.
Помню давно на форуме бытовала мысль о способности выносить как можно больше денег из IT проектов. Похоже эти способности только и остаются, работу работать уже разучились вообще. Опять же не за всех говорю, но за тех с кем довелось сталкиваться (не могу сказать "работать") по этому проекту.
Доложить больше не о чем.

[deev_a_v]

Только что пришло сообщение что проект перехода с МФ остановлен до особого распоряжения. Целевая дата переносится на 2022-ой год.
По тому как это делалось до сих пор меня нисколько не удивляет. По-моему люди не имевшие дел с МФ деградировали настолько что они не способны даже перенести то что на МФ куда-нибудь еще. Я не за всех людей, а только тех с кем общаюсь по этому проекту. Их кстати вовлечено неразумно много. На митингах видишь 10-12 человек из которых только 3-4 о чем то могут вещать. Остальные молчат, но якобы участвуют в проекте.
Помню давно на форуме бытовала мысль о способности выносить как можно больше денег из IT проектов. Похоже эти способности только и остаются, работу работать уже разучились вообще. Опять же не за всех говорю, но за тех с кем довелось сталкиваться (не могу сказать "работать") по этому проекту.
Доложить больше не о чем.

У меня сложилось ощущение, что если ваш МФ просто выключить из розетки, то никто и не заметит.

[zVlad]

Только что пришло сообщение что проект перехода с МФ остановлен до особого распоряжения. Целевая дата переносится на 2022-ой год.
По тому как это делалось до сих пор меня нисколько не удивляет. По-моему люди не имевшие дел с МФ деградировали настолько что они не способны даже перенести то что на МФ куда-нибудь еще. Я не за всех людей, а только тех с кем общаюсь по этому проекту. Их кстати вовлечено неразумно много. На митингах видишь 10-12 человек из которых только 3-4 о чем то могут вещать. Остальные молчат, но якобы участвуют в проекте.
Помню давно на форуме бытовала мысль о способности выносить как можно больше денег из IT проектов. Похоже эти способности только и остаются, работу работать уже разучились вообще. Опять же не за всех говорю, но за тех с кем довелось сталкиваться (не могу сказать "работать") по этому проекту.
Доложить больше не о чем.

У меня сложилось ощущение, что если ваш МФ просто выключить из розетки, то никто и не заметит.

Из чего это интересно такое ощущение сложилось? Может просто поерничать захотелось.

[Palych]

Из чего это интересно такое ощущение сложилось? Может просто поерничать захотелось.

Мне тоже раньше глядя на старые системы хотелось их пристрелить, чтобы не мучились...
Сейчас я понимаю что многие из них практически бессмертны, весьма полезны, могут ещё не одно поколение инженеров прокормить. Хотя, когда сталкиваюсь с ними - желания молодости просыпаются иногда... Психологический феномен однако.

[zVlad]

Из чего это интересно такое ощущение сложилось? Может просто поерничать захотелось.

Мне тоже раньше глядя на старые системы хотелось их пристрелить, чтобы не мучились...
Сейчас я понимаю что многие из них практически бессмертны, весьма полезны, могут ещё не одно поколение инженеров прокормить. Хотя, когда сталкиваюсь с ними - желания молодости просыпаются иногда... Психологический феномен однако.

У меня тоже имеется подобный психологический феномен. Только в обратную сторону. И именно эта, пока неудачная попытка, меня особенно добила. Полгода работы в ватаге коллег, где я был единственный мф-щик, и результат - мигрированна 1/4 базы данных с МФ, даже не продакшн, а делелоперская. Потрачена куча денег (из-за превышения бюджета собственно проект остановлен) и скопировано всего один террабайт данных с Мф в Azure. Полгода!

Не знаю о каких ты старых системах говоришь. Я в прошлом году сделал упграйд со старого (2013 год) МФ на новый (2017). Есть еще новее вариант - 2019 года. Все это не эммуляции на x86 как VAX, а естественные железки. Софт базовый - OS, DB, WebServer-а и т.п. существуют в текущих версиях и постоянно ообновляюстя. Можно было бы языковую платформу - COBOL назвать "старым". Но во первых COBOL тоже имеет текущие версии, он давно уже обьектно-ориентирован и webservice-ы в нем поддерживаюста. a во-вторых, что такого нового в Java на которую вендор переписал кобольные программы в их новой версии сохранив ту же структуру БД и ту же, на 90%, логику? Java поддерживается, и уже давно, в мф-ском сервере приложений в CICS.

Меня в этой истории больше люди чем железки удивляют и интересуют. Люди взросшие на "новом". Я с ними, разными, за эти полгода много общался и ничего хорошего про их способности сказать не могу. Но я не могу их винить как людей, я сам такой же. Дело все в той, "новой", платформе в рамках которой их умственный аппарат сформирован. Выпругнуть за него они не могут. В итоге я слышу такие вещи как "сервер под QA будет такого же размера как Production. Причем они говорят не "server" на самом деле, а "Virtual Machine". Почему они должны быть одинаковые? Разве нагрузка на них будет одинакова. Нет конечно. На QA никогда не будет столько пользователей сколько на Production. Ну и главное, цена! в Azure цена зависит от параметров сервера и вот они готовы платить двойную цену с ходу там где нормально соотношение должно быть 1 к 10 как минимум. Я думаю за полгода уже потрачено больше денег чем нузно для упгрэйда существующего, не сильно старого МФ. Кстати, на МФ-ской стороне оба инстанса и пара других бегут на одном и том же МФ.
Это лишь один пример, у меня больше. Думая с чем можно было сравнить то что я вижу - ограниченность мышления моих коллег из "новых" песочниц я вспомнил про африканское племя где мальчикам младенцам привязывали к головам дощечки чтобы череп формировался особым образом - так в том племени считается правильно и важно. Вот и мои коллеги через такие виртуальные дощечки проведены. А так в принципе нормаль[ные люди и их можно понять - нет у них в распоряжении того что есть на МФ и это не их вина. Иногда правда они тупят вне связи с этим. Например, считается что перед cut-over нужно сделать 5-6 миграций "в сухую". Другой, сервер под Production будет заказан непосредственно перед cut-over. Наверно хотят сэкохомить на Azure, который по счетчику веремени калькулирует цену.
Вот такие дела уважаемый Палыч. А ты говоришь "старые". Windows-ы, Unix-ы, и прочие Linux-ы тоже не молоды уже давно. И что? Oracle и DB2 появились можно сказать одновременно, на самом деле DB2 раньше, гораздо. И мои коллеги по этому проекту хороших слов про Oracle не говорят. И это не только наши DBAs, но и непосредственно из Oracle ехперт из Texas и его манагер работают с нами. Они говорят "ну это же Oracle", что мол вы хотите. На моей стороне - DB2 все не просто хорошо, а класно несмотря на то что мой DB2 действительно старый - версия 9 (на дворе уже 12-ая). И я один на стороне МФ и не только с DB2 но вообще со всей МФ-ской инфраструктурой, включая железо. А на другой стороне, куда идет переход, десятки людей трудятся, только на миграции данных из БД в БД до десяти голов, включая эксперта из Oracle, и незнамо сколько на сторонe собственно приложения.
Вся эта ватага плус Azure уже напрягла нашего клиента по деньгам и проект остановлен. А сделано то всего ничего - одна миграция 1/4 (по размеру) БД и конвертация ее на новую версию БД от вендора. И это еще без кастомизаций приложения сделаных нашими програмистами. Я думаю это, в лучшем случае, не более 20% от того что надо. Да меньше. За полгода! Получается до моих 70 лет работа на МФ для меня еще будет.

[alex_127]

у вас может нет мейнфреим форевер а RDBMS форевер... от нас не уйдешь...

[Palych]

Строг говоря "старые" системы могут быть и на Java написаны.
Это системы, в основе которых принципы, которые не понятны. А если нам что-то непонятно: нам сильно хочется либо понять это, либо сделать так чтобы это куда-нибудь исчезло.
Мы делаем мощный бросок, стараясь захватить своим могучим интеллектом новую территорию. Быстро продвигаемся вперед, вроде бы почти достигаем цели... И тут инспектор Коломбо оборачивается и говорит: "oh, one more thing...".
Нас отбрасывает на позиции близкие к исходным. И мы вызываем авиацию, переходим к тактике выжженной земли.

[liamkin]

У меня тоже имеется подобный психологический феномен. Только в обратную сторону. И именно эта, пока неудачная попытка, меня особенно добила.

Держитесь! Очень многие банки и правительства штатов на вас надеются!
Я лет 10 работал на контракте Дженерал Моторз а до этого Форд. Там довольно много мэйнфрэймов. И хотят от них избавиться из-за "платежей за использование", плюс Кобольцев все меньше. Наблюдал несколько проектов, многие провалились. В одном случае тупо не хватило производительности нового софта плюс железа - на мэйнфрейме-то люди на Ассемблере кое-что писали, и сабсеконд респонс был нормой! А тут Ява и Юникс - не потянули. В других случаях не произошел быстрый успех, или кончились деньги - им бы довести до ума, доплатить, доделать, ан нет - просто закрывают проект. Кто-то (вендоры) наварился!
У нас правда в этих случаях кучу высокопоставленного народа выпиннули. Простых тоже в аут.
Вам, зВлад, надо подмастерье взять, и обучить его премудростям ремесла. Чтобы нить не оборвалась!

[Flash-04]

Ученик чародея

[Мальчик-Одуванчик]

На QA никогда не будет столько пользователей сколько на Production.

Вот это, кстати, странно. У нас наоборот, тестируется как минимум в 10-100 раз большая нагрузка чем даже в пике бывает на работающей версии.

[zVlad]

У меня тоже имеется подобный психологический феномен. Только в обратную сторону. И именно эта, пока неудачная попытка, меня особенно добила.

Держитесь! Очень многие банки и правительства штатов на вас надеются!
Я лет 10 работал на контракте Дженерал Моторз а до этого Форд. Там довольно много мэйнфрэймов. И хотят от них избавиться из-за "платежей за использование", плюс Кобольцев все меньше. Наблюдал несколько проектов, многие провалились. В одном случае тупо не хватило производительности нового софта плюс железа - на мэйнфрейме-то люди на Ассемблере кое-что писали, и сабсеконд респонс был нормой! А тут Ява и Юникс - не потянули. В других случаях не произошел быстрый успех, или кончились деньги - им бы довести до ума, доплатить, доделать, ан нет - просто закрывают проект. Кто-то (вендоры) наварился!
У нас правда в этих случаях кучу высокопоставленного народа выпиннули. Простых тоже в аут.
Вам, зВлад, надо подмастерье взять, и обучить его премудростям ремесла. Чтобы нить не оборвалась!

Спасибо за интереснюы инфу. Я проработал на всего одном месте в Америках и не имею широкого круга контавтов по МФ на других местах. Лишь один переход с МФ был на моих глазах когда меньшая часть нашего клиента ушли с МФ. Им было тыжело, долго, плохо, но они удержались. До этого их перехода приложение выполнялось на МФ с двумя CPU и считанными гигабайтами.
Оставшаяся, бОльшая, часть этого бизнеса тоже не велика. МФ на котором все инстансы стоят весьма не велик, можно даже сказать очень и очень не велик. Может и им удастся удержаться в Azure, закидают ядрами и гигабайтами аппликуху. Но вот уже спотыкнулись. А всего то прошли малую часть пути.
Я видел много уходов с МФ в России. Но это было в условиях экономического коллапса и весьма незначительного исползования IT в бизнесах. Если осталось в России пара-тройка мест на МФ то это будет удивительно.

[zVlad]

На QA никогда не будет столько пользователей сколько на Production.

Вот это, кстати, странно. У нас наоборот, тестируется как минимум в 10-100 раз большая нагрузка чем даже в пике бывает на работающей версии.

Роботами тестируете? Ну, ну. Знаем мы эти роботы осбенно сконфигирированные по идеальным моделям нагрузки.
Я знаю нашу нагрузку и знаю что смоделировать ее невозможно если не знать некоторых особенностей. Например, дипазон количества транзакций выполняемых за день от 350 до 460 тысяч. Но состав транзакций может быть настолько разным что в один день 460 пролетают со свистoм, в другой на 420 тысуачах может произойти затык пропускной способности. Затык, по нашему, это когда больше 10-20 minut CPU стабильно на 100% загружен. Но никогда не бывает чтобы система "сдулась" просто выполнение работы затормаживается. Такой затык последний раз был на прошлой неделе. Пользователь клиента два раза запустил одну транзакцию которая непрерывно выполнялась больше 1.5 цахас и отжирала 7-10% CPU. Никто не жаловался. Я обнаружил это анализируя некоторые параметры постфактум.

Нагрузочные тесты могут иметь смысл только на простых, детерминированных моделях. Коротких, однотипных транзакциях. Наш случай очень недетрминирован, одна и та же транзакция может выполнять субсеконд, а может растянуться на жасы. С ними можно было бы успешно бороться, есть механизмы и методы, но у нашeго клиента и наших программистов нет желания. А я один. И подмастерьев мне не дают.

Пожалуйста, не комментируйте приведенные числа. Они ни о чем не говорят.

[iDesperado]

да понятно, что пенсионеры ничего путного не намигрируют. это ясно как божий день.
понятно что в лучшем случае они построят RAC на шаред виртуалках, RAC понятно, что такое порно не осилит и все они разойдутся на пенсию.
это ясно.

Вся эта ватага плус Azure уже напрягла нашего клиента по деньгам и проект остановлен. А сделано то всего ничего - одна миграция 1/4 (по размеру) БД и конвертация ее на новую версию БД от вендора. И это еще без кастомизаций приложения сделаных нашими програмистами. Я думаю это, в лучшем случае, не более 20% от того что надо. Да меньше. За полгода! Получается до моих 70 лет работа на МФ для меня еще будет.

я был прав
инвалиды пол года пару таблиц скопировать не могут, но клиент мужественно это шоу оплачивал ... не знаю, я не верю в такие басни. у нас к олдам очень настороженно относятся и уже через неделю бы заместили джунами умеющими квадратики в ETL расставлять.

В одном случае тупо не хватило производительности нового софта плюс железа - на мэйнфрейме-то люди на Ассемблере кое-что писали, и сабсеконд респонс был нормой! А тут Ява и Юникс - не потянули.

если был нормой, творчество этих людей не выкинули бы на свалку истории. в том числе и с МФ. у Влада та же ява, как у всех. просто платформа ущербная, требующая еще тучи костылей типа ziip процессоров, за немерянные деньги, что бы хоть как-то перформить. нет смысла запускать ява на 24 гб, если можно ее же запускать на 64 гб в сотни раз дешевле. Влад мигрирует на 1/8 современного процессора, на 8 vcpu и 64 Gb ram. такая виртуалка в азуре стоит менее $100 в месяц.

[Мальчик-Одуванчик]

На QA никогда не будет столько пользователей сколько на Production.

Вот это, кстати, странно. У нас наоборот, тестируется как минимум в 10-100 раз большая нагрузка чем даже в пике бывает на работающей версии.

Роботами тестируете? Ну, ну. Знаем мы эти роботы осбенно сконфигирированные по идеальным моделям нагрузки.

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

[Мальчик-Одуванчик]

Влад мигрирует на 1/8 современного процессора, на 8 vcpu и 64 Gb ram. такая виртуалка в азуре стоит менее $100 в месяц.

Про Азур не в теме, но у нас какое-то простенькое отладочное говнище из трех маломощных железяк в Амазоне за полгода сожрало денег, как если бы просто купить три компа каждый мошностью как вся эта конфигурация.

[zVlad]

На QA никогда не будет столько пользователей сколько на Production.

Вот это, кстати, странно. У нас наоборот, тестируется как минимум в 10-100 раз большая нагрузка чем даже в пике бывает на работающей версии.

Роботами тестируете? Ну, ну. Знаем мы эти роботы осбенно сконфигирированные по идеальным моделям нагрузки.

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

На МФ отказов не бувает под любой нагрузкой. Это тестируется в IBM. А какие отказы, интересно, Вы симулируете?
Наша нагрузка (нашего клиента) такова что день на день не похож. Но за послeднии месяца выявилась тенденция раз в месяц, обычно в начале, происходит продолжительный всплеск нагрузки на фоне общего высокого уровня когда ожидаемые времена выполнения транзакций заметно возрастают (без влияния на систему). Реакция пользователей при этом такова что они пытаются повторить что затягивает процес выхода из всплеска. В принципе понятно что если добавить мощи МФ (CPU, только CPU) процентов на 20 то эти всплески будут прожовываться не заметно. Но клиент, посльку собрася уходить, на это не идет. Не идет даже зная что миграция данных будет происходить с этого же МФ. Верит в чудо наш клиент, и это чудо я ему обеспечу. Благодаря МФ, ну и немножко мне конечно.

В тестовой среде надо проверять ту модель которая в рабочей. Других там не будет по определению. Мой поинт в том что наша модель стохастическая, а под такую, в Вашем случае, нет решения. Вы это можете решать только подбрасыванием дровишек. А на МФ есть более интелектуальные решения, без дров.

[Мальчик-Одуванчик]

На МФ отказов не бувает под любой нагрузкой. Это тестируется в IBM. А какие отказы, интересно, Вы симулируете?

Разумеется что проверяются приложения, а не железо.
Например, для того же приложения, написанного на Джаве, поведение сборщика мусора, работа с потоками и тд может отличаться в зависимости от нагрузки.
И это приложение весело рухнет вне зависимости от того, на каком железе оно работает - будь то захудалый писюк или продвинутый мейнфрейм.
Куча сторонних библиотек, написанных за долгое время дают этому широкое раздолье.
И я даже полагаю что на мейнфрейме эти приложения будут падать чаще просто потому что система исполнения джавы под экзотическое железо всяко оттестирована не лучше, нежели на типовом.

Поэтому интересно как наша система справится с отказом одного или нескольких приложений.
Под нагрузкой.
Сюда так же входит отказ базы данных или потеря связи.

[Palych]

В одном случае тупо не хватило производительности нового софта плюс железа - на мэйнфрейме-то люди на Ассемблере кое-что писали, и сабсеконд респонс был нормой! А тут Ява и Юникс - не потянули.

если был нормой, творчество этих людей не выкинули бы на свалку истории. в том числе и с МФ.

Вообще-то здесь обсуждаются неудачные попытки перенести работающие системы. Стало быть они по определению не на свалке. Может быть рядом с ней, да и то спорно.
И даже если их пытаются выкинуть, то на мой взгляд явно не за то что они не обеспечивают быстрый ответ.

[zVlad]

На МФ отказов не бувает под любой нагрузкой. Это тестируется в IBM. А какие отказы, интересно, Вы симулируете?

Разумеется что проверяются приложения, а не железо.
Например, для того же приложения, написанного на Джаве, поведение сборщика мусора, работа с потоками и тд может отличаться в зависимости от нагрузки.
И это приложение весело рухнет вне зависимости от того, на каком железе оно работает - будь то захудалый писюк или продвинутый мейнфрейм.
Куча сторонних библиотек, написанных за долгое время дают этому широкое раздолье.
И я даже полагаю что на мейнфрейме эти приложения будут падать чаще просто потому что система исполнения джавы под экзотическое железо всяко оттестирована не лучше, нежели на типовом.

Поэтому интересно как наша система справится с отказом одного или нескольких приложений.
Под нагрузкой.
Сюда так же входит отказ базы данных или потеря связи.

Я Вас понимаю. Мне приходилось иметь дело с приложениями на Java и я много могу сказать, но скажу меньше - формат форумa не предполагает долгих речей.
Есть у нас приложение, работающее на сервере в контакте с DB2 на МФ, прямом контакте. И вот когда МФ нагружен тем о чем я писал выше (но может быть и по другой причине. Я это оставляю не доказаным достоверно) то это приложение начинает "бомбиыь" конекциями. Количество одновременных активных коннекций, которое обычно не выходит за пару десятков начинает превышать число 200 - йето условный максимум, свыше которого запросы на присоедение ставятся в очередь.
Пару месяцев назад это же приложение в подобных условиях достигало другого предела - 1000 неактивных коннекций. Тогда вендор заявил о баге и пофиксал его. Эта проблема ушла, проблема с неконтролируемым ростом активных осталась. Я вижу это из данных мониторинга, сообщаю - никакой реакции. Будь[ это в рамках МФ я бы уже докопался, но это на серверах.
Отказов БД на МФ - DB2 не было никогда у нас (был один, лет 17 назад, из-за бага. Был устранен с помощью IBM за пару-тройку дней). Потеря связи, особенно после перевода серверов в Azure - обычное явление, сегодня репликация рухнула из-за этого. Решение - перрезапуск репликации и самосинхронизация. Можно легко автоматизировать, но из-за редкости этого остается неавтоматизированно. Возможно из-за Azure придется автоматизировать.

[zVlad]

В одном случае тупо не хватило производительности нового софта плюс железа - на мэйнфрейме-то люди на Ассемблере кое-что писали, и сабсеконд респонс был нормой! А тут Ява и Юникс - не потянули.

если был нормой, творчество этих людей не выкинули бы на свалку истории. в том числе и с МФ.

Вообще-то здесь обсуждаются неудачные попытки перенести работающие системы. Стало быть они по определению не на свалке. Может быть рядом с ней, да и то спорно.
И даже если их пытаются выкинуть, то на мой взгляд явно не за то что они не обеспечивают быстрый ответ.

Никто ничего не выкидывает. То на что пытаемся перенести приложение с МФ есть в точности тоже самое переписанное нa Java с COBOL. Модель данных та же (косметические изменения не в счет), алгоритмы те же, вендор тот же. Программы дописанные нашими программерами на COBOL уже полгода перетряхиваются и подготавливаются для переписывания один-к-одному в Java. Смысл?!
На Ассемблер на МФ програм нет в этом приложении, но COBOL все равно гораздо эффективнее любой Java.
Причины ухода с МФ просты как виноград - вендор не в состоянии поддерживать приклад на разных платформах. Привлекалово вендора (из их же презентанции- мы даем решение на бесплатных (Open source - WildFly), но в тоже время дорогой Oracle в качестве БД и дорогой GoldenGate для миграции получается).

[zVlad]

.....
Например, для того же приложения, написанного на Джаве, поведение сборщика мусора, работа с потоками и тд может отличаться в зависимости от нагрузки.
И это приложение весело рухнет вне зависимости от того, на каком железе оно работает - будь то захудалый писюк или продвинутый мейнфрейм.
...

Я знаю историю Java на MF. До Java v4 движок на МФ писали в Sun, с v5 пишется в IBM. Разница как небо и земля. Для Java на МФ есть Specialty CPU - zIIP. Если коротко с Java на МФ сейчас все в шооколаде.