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

[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 то эти всплески будут прожовываться не заметно. Но клиент, посльку собрася уходить, на это не идет. Не идет даже зная что миграция данных будет происходить с этого же МФ. Верит в чудо наш клиент, и это чудо я ему обеспечу. Благодаря МФ, ну и немножко мне конечно.

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