Мы идем на z14.

[Flash-04]

в итоге все опровергли их вброс и сам Блумберг начал "путаться в показаниях". Учитывая последние события, не могу исключить что вброс был проплачен, так как тот же Supermicro обьявил о переносе производства компонентов в США из Китая.

[zVlad]

Bкак всегда последнее время с запозданием я узнал что ИБМ анносировали новое семейство мэйнфрэйм - z15.
Если почтитать эту тему то там где-то говорилось (мою, мною) что z14 это последнее семейство, но оказалось что это не так. Говорил то я со ссылкой на некого аналитика более приближенного чем я к истокам. В принципе я был с ним согласен, казалось что кроме физического роста больше нет причин. А вон как получилось, выдали таки z15.
Я с этим очень поверностно пока ознакомился - много житейских проблем - но из того что видел вижу только физический рост, а именно, 190 коров в одной упряжке, 40 терабайт. Ввод-вывод конечно тоже в облака улетел, но и риторика стала сунубо облачная. Последнее меня скорее огорчает чем радует. Эти облака на мф с начала 70-х имеются.

Короче чисто коммерческое движение на данный момент это самое семейство z15. Ничего нового лично я не вижу, но кто я?

[zVlad]

Не прошло и года и слухи начали таки материлизоваться. Вчера ИБМ запросили данные с наших систем чтобы правильно сформироватт капасити новых мэйнфрэймов.
Это будут две z14, в замен двух z12.
Так что лет на пять работа моя сохраняется. И развлечься в ближайшие месяцы будет чем. Может наконец то сподобятся дать добро на переход на новые версии zOS и DB2. А то уже стыдно людям в глаза глядеть с теми версиями что у нас.

[Palych]

. Может наконец то сподобятся дать добро на переход на новые версии zOS и DB2. А то уже стыдно людям в глаза глядеть с теми версиями что у нас.

А как часто ваше приложение меняется?
(в смысле новых релизов)

[zVlad]

. Может наконец то сподобятся дать добро на переход на новые версии zOS и DB2. А то уже стыдно людям в глаза глядеть с теми версиями что у нас.

А как часто ваше приложение меняется?
(в смысле новых релизов)

Приложение последний раз обновлялось в смысле релизов в 2012 году. Новее релиз тоже весьма древний.
По ОС мы лет 6 отстаём, по БД еще больше. ОС обновляется раз в два года. База данных тоже регулярно.
Хард у нас самый молодой по релизу. И вот опять обновляется.

[Palych]

Приложение последний раз обновлялось в смысле релизов в 2012 году. Новее релиз тоже весьма древний.
По ОС мы лет 6 отстаём, по БД еще больше. ОС обновляется раз в два года. База данных тоже регулярно.
Хард у нас самый молодой по релизу. И вот опять обновляется.

Логично: когда хард обновляется - ожидается что он должен работать точно так же как и старый, только быстрее.
А база после обновления гарантировано будет что-то по другому делать.
А приложение поди подпиливать некому...

[deev_a_v]

. Может наконец то сподобятся дать добро на переход на новые версии zOS и DB2. А то уже стыдно людям в глаза глядеть с теми версиями что у нас.

А как часто ваше приложение меняется?
(в смысле новых релизов)

Приложение последний раз обновлялось в смысле релизов в 2012 году. Новее релиз тоже весьма древний.
По ОС мы лет 6 отстаём, по БД еще больше. ОС обновляется раз в два года. База данных тоже регулярно.
Хард у нас самый молодой по релизу. И вот опять обновляется.

А вы бы среди коллег- админов пустили бы шапку по кругу - глядишь и насобирали бы на апгрейд. На общее дело же не жалко, пусть этом менеджерам стыдно будет!

[zVlad]

Приложение последний раз обновлялось в смысле релизов в 2012 году. Новее релиз тоже весьма древний.
По ОС мы лет 6 отстаём, по БД еще больше. ОС обновляется раз в два года. База данных тоже регулярно.
Хард у нас самый молодой по релизу. И вот опять обновляется.

Логично: когда хард обновляется - ожидается что он должен работать точно так же как и старый, только быстрее.
А база после обновления гарантировано будет что-то по другому делать.
А приложение поди подпиливать некому...

Про хард согласен. Так и было, всегда. Новый хард работал быстрее. Но, поскольку и хард и софт в случае мф это дело одного вендора, то без нового софта, на новом харде всего что даетчя выжать нельзя. Т.е. невозможно, т.к. изменения в харде, кто примитивных повышений ттх, требуют изменений в софте, потому что новая функциональность появляется.
По базе данных тоже самое. Поскольку все это от одного вендора, то все идет нюх к нюху, не может новая база вести себя хуже чем старая, тем более на новом железе. Обратного я не наблюдал ни разу, речь идет конечно о мэйнфрэйм, на других платформах будет как говорите Вы. Db2 в новых версиях имеют два режима, совместимости (compatibility) и new functions. Это чтобы старые приложения могли работать пока их не подтянут и доя тех кто осознал.
Приложение наше постоянно подпиливают. У нас есть исходные тексты. Но главным образом идет добавление нового, а не переписывание старого. Со старым воюем по производительности в основном на уровне админа. Индексы, статистика, архивация. Как раз сегодня началчя у нас новый путь - архивация. До этого времени, с 1997 года, данные копились в таблицах без спецудаления, т.е. они удалялись только по логике прилоления, а не как фактор повышения производительности. Сегодня же я впервые за все время с 1997 выполнил удаление данных в архив из одной таблицы. На лету, без просьбы позьзователям подождать. Это было лишь начало, обкатка технологии архивации, создание, освоение, базовых средств для дальнейшей работы с многими таблицами логически связанными. Эта тема старая, но у нас она впервые (после начала 2000-х, тогда ее просто отбросили) снова поднимается. Просто дальше без архивации жить нельзя, морально нельзя.

[Palych]

Про хард согласен. Так и было, всегда. Новый хард работал быстрее. Но, поскольку и хард и софт в случае мф это дело одного вендора, то без нового софта, на новом харде всего что даетчя выжать нельзя. Т.е. невозможно, т.к. изменения в харде, кто примитивных повышений ттх, требуют изменений в софте, потому что новая функциональность появляется.
По базе данных тоже самое. Поскольку все это от одного вендора, то все идет нюх к нюху, не может новая база вести себя хуже чем старая, тем более на новом железе. Обратного я не наблюдал ни разу, речь идет конечно о мэйнфрэйм, на других платформах будет как говорите Вы. Db2 в новых версиях имеют два режима, совместимости (compatibility) и new functions. Это чтобы старые приложения могли работать пока их не подтянут и доя тех кто осознал.
Приложение наше постоянно подпиливают. У нас есть исходные тексты. Но главным образом идет добавление нового, а не переписывание старого. Со старым воюем по производительности в основном на уровне админа.

Для харда есть объективное ограничение: он стареет со временем, если ничего не менять - рано или поздно оно упадет.
Софт в этом смысле вечен.
Потому, если система справляется с задачами - зачем менять то, что работает и так?

[zVlad]

Про хард согласен. Так и было, всегда. Новый хард работал быстрее. Но, поскольку и хард и софт в случае мф это дело одного вендора, то без нового софта, на новом харде всего что даетчя выжать нельзя. Т.е. невозможно, т.к. изменения в харде, кто примитивных повышений ттх, требуют изменений в софте, потому что новая функциональность появляется.
По базе данных тоже самое. Поскольку все это от одного вендора, то все идет нюх к нюху, не может новая база вести себя хуже чем старая, тем более на новом железе. Обратного я не наблюдал ни разу, речь идет конечно о мэйнфрэйм, на других платформах будет как говорите Вы. Db2 в новых версиях имеют два режима, совместимости (compatibility) и new functions. Это чтобы старые приложения могли работать пока их не подтянут и доя тех кто осознал.
Приложение наше постоянно подпиливают. У нас есть исходные тексты. Но главным образом идет добавление нового, а не переписывание старого. Со старым воюем по производительности в основном на уровне админа.

Для харда есть объективное ограничение: он стареет со временем, если ничего не менять - рано или поздно оно упадет.
Софт в этом смысле вечен.
Потому, если система справляется с задачами - зачем менять то, что работает и так?

В общем Вы правы. Такая политика вполне оправдана если пользователь не видит перспектив платформы и/или приложения.
Тут надо поделить анализ на две ветки.

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

- приложения. Их можно в весьма широких пределах модифицировать если имеются исходные тексты и знание как оно устроено. Тем более если это приложение "бЭкЭнда". Наши програмисты в рамках версии уровня нулевых много чего прикрутили. Да и вендор в планы развития этого приложения все годы 21 века в основном игрался с фрондэндом. Доигрался же до того что исключил zOS, DB2 for zOS, and CICS из поддерживаемого ими набора инфрасструктуры. Хотя хард МФ, поскольку они полностью перешли на Линукс, использоваться может. В худшем из возможных вариантов однако. У вендора просто нет, как говорят, специалистов для поддержки нормального набора. Да и клиентуру они за многие годы запугали тем что МФ поддерживать не будут и видимо народ разбежался кто куда (не обязательно с МФ, но и с этого приложения тоже) и из серьезных возможно остались мы одни. Наш клиент возможно понимает значение МФ для их стабильности и хард обновляет, оставляя старую версию приложения и развивая по необходимости его своими силами. Однако в движении на новые версии ОС, БД остается консервантивным. Нет у меня выходов на ключевых персон клиента, иначе я бы им быстро все объяснил.

А вот если клиент собирается вскоре (5 лет) уйти с МФ я бы на его месте ни хард ни ОС, ни БД не менял бы вообще. Думаю их ИБМ уломало с хардом тем что цена на новое станет ниже цены на старое. Это конечно работает сильно, но это не имеет никакого отношения к технической стороне вопроса.

[iDesperado]

Нет у меня выходов на ключевых персон клиента, иначе я бы им быстро все объяснил.

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

[Palych]

Работать все конечно будет но ... не так как могло бы. Так что софт тоже "стареет", функционально и по производительности.

Это все-таки не старение. Старение предполагает грядущую кончину. В случае харда это в принципе возможно (высыхающие электролиты, пыль в вентиляторах...)
А софт в принципе бессмертен.
...Интересно - есть ли реальные системы которые работают в production 50 лет? Думаю когда-нибудь будут и 100-летние приложения...

А вот если клиент собирается вскоре (5 лет) уйти с МФ я бы на его месте ни хард ни ОС, ни БД не менял бы вообще. Думаю их ИБМ уломало с хардом тем что цена на новое станет ниже цены на старое. Это конечно работает сильно, но это не имеет никакого отношения к технической стороне вопроса.

Тут согласен.

[zVlad]

Работать все конечно будет но ... не так как могло бы. Так что софт тоже "стареет", функционально и по производительности.

Это все-таки не старение. Старение предполагает грядущую кончину. В случае харда это в принципе возможно (высыхающие электролиты, пыль в вентиляторах...)
А софт в принципе бессмертен.
...Интересно - есть ли реальные системы которые работают в production 50 лет? Думаю когда-нибудь будут и 100-летние приложения...
....

Я поэтому и взял в кавычки. Софт бессмертен и конечно же есть и не мало кода написанного 50 лет назад. В 2014, шесть лет назад, была 50-ая годовщина анносирования ибм-ской системы 360. Что-то на нее переносили и с более древнего харда и за шесть лет до 1970 могли написать тоже немало. В нынешнем zOS есть утилиты написанные в 60-е годы.

[liamkin]

Работать все конечно будет но ... не так как могло бы. Так что софт тоже "стареет", функционально и по производительности.

Это все-таки не старение. Старение предполагает грядущую кончину. В случае харда это в принципе возможно (высыхающие электролиты, пыль в вентиляторах...)
А софт в принципе бессмертен.
...Интересно - есть ли реальные системы которые работают в production 50 лет? Думаю когда-нибудь будут и 100-летние приложения...
....

Я поэтому и взял в кавычки. Софт бессмертен и конечно же есть и не мало кода написанного 50 лет назад. В 2014, шесть лет назад, была 50-ая годовщина анносирования ибм-ской системы 360. Что-то на нее переносили и с более древнего харда и за шесть лет до 1970 могли написать тоже немало. В нынешнем zOS есть утилиты написанные в 60-е годы.

Вы в курсе про проблему 2030 года? Это когда Y2K решали, сделали если год 30-99 - то это 19хх годы, а если 00-29 - то 2000-е. Вам надо, батенька, дожить до 2030го - уже недолго, десяток лет еще.

[zVlad]

Работать все конечно будет но ... не так как могло бы. Так что софт тоже "стареет", функционально и по производительности.

Это все-таки не старение. Старение предполагает грядущую кончину. В случае харда это в принципе возможно (высыхающие электролиты, пыль в вентиляторах...)
А софт в принципе бессмертен.
...Интересно - есть ли реальные системы которые работают в production 50 лет? Думаю когда-нибудь будут и 100-летние приложения...
....

Я поэтому и взял в кавычки. Софт бессмертен и конечно же есть и не мало кода написанного 50 лет назад. В 2014, шесть лет назад, была 50-ая годовщина анносирования ибм-ской системы 360. Что-то на нее переносили и с более древнего харда и за шесть лет до 1970 могли написать тоже немало. В нынешнем zOS есть утилиты написанные в 60-е годы.

Вы в курсе про проблему 2030 года? Это когда Y2K решали, сделали если год 30-99 - то это 19хх годы, а если 00-29 - то 2000-е. Вам надо, батенька, дожить до 2030го - уже недолго, десяток лет еще.

На какой платформе это было сделано, и было ли это сделано так же на мэйнфрэйм?

P.S. Кстати, не 2030, а 2038. P.P.S. Вы вообще о чем то непонятном, несуществующем, рассказали.

[liamkin]

Работать все конечно будет но ... не так как могло бы. Так что софт тоже "стареет", функционально и по производительности.

Это все-таки не старение. Старение предполагает грядущую кончину. В случае харда это в принципе возможно (высыхающие электролиты, пыль в вентиляторах...)
А софт в принципе бессмертен.
...Интересно - есть ли реальные системы которые работают в production 50 лет? Думаю когда-нибудь будут и 100-летние приложения...
....

Я поэтому и взял в кавычки. Софт бессмертен и конечно же есть и не мало кода написанного 50 лет назад. В 2014, шесть лет назад, была 50-ая годовщина анносирования ибм-ской системы 360. Что-то на нее переносили и с более древнего харда и за шесть лет до 1970 могли написать тоже немало. В нынешнем zOS есть утилиты написанные в 60-е годы.

Вы в курсе про проблему 2030 года? Это когда Y2K решали, сделали если год 30-99 - то это 19хх годы, а если 00-29 - то 2000-е. Вам надо, батенька, дожить до 2030го - уже недолго, десяток лет еще.

На какой платформе это было сделано, и было ли это сделано так же на мэйнфрэйм?

P.S. Кстати, не 2030, а 2038. P.P.S. Вы вообще о чем то непонятном, несуществующем, рассказали.

Я думаю, это был Кобол. Мэйнфреймовский, естественно.

[zVlad]

...

Я думаю, это был Кобол. Мэйнфреймовский, естественно.

Чтобы не терять время на болтовню я Вам скажу, а Вы просто поверите что на мэйнфрэйме нет проблемы какого либо года кроме удаленного настолько сколько человечество не просушествует.
Может быть (а может и не быть) проблема с программами на С, работающими в USS, но это уже совсем другая история. Я не хочу ее касаться.

[liamkin]

...

Я думаю, это был Кобол. Мэйнфреймовский, естественно.

Чтобы не терять время на болтовню я Вам скажу, а Вы просто поверите что на мэйнфрэйме нет проблемы какого либо года кроме удаленного настолько сколько человечество не просушествует.
Может быть (а может и не быть) проблема с программами на С, работающими в USS, но это уже совсем другая история. Я не хочу ее касаться.

C Cи там на Юниксе. 32-бита под секундомер. Все Юниксы давно 64-битные. Плюс там программы активно обновляются.
https://en.wikipedia.org/wiki/Year_2038_problem

Вот еще интересная проблемка (на текстовых сообщениях телефонов)
https://en.wikipedia.org/wiki/Year_2000 ... 10_problem

А вот про что я говорю. Год представлен в базе данных в виде двузначного числа. А нужны все четыре цифры. Для определения века используется метод окна - https://en.wikipedia.org/wiki/Date_windowing

Вот нетипичный пример из Микрософтовского Экселя
https://docs.microsoft.com/en-us/office ... ar-numbers

[zVlad]

...

Я думаю, это был Кобол. Мэйнфреймовский, естественно.

Чтобы не терять время на болтовню я Вам скажу, а Вы просто поверите что на мэйнфрэйме нет проблемы какого либо года кроме удаленного настолько сколько человечество не просушествует.
Может быть (а может и не быть) проблема с программами на С, работающими в USS, но это уже совсем другая история. Я не хочу ее касаться.

C Cи там на Юниксе. 32-бита под секундомер. Все Юниксы давно 64-битные. Плюс там программы активно обновляются.
https://en.wikipedia.org/wiki/Year_2038_problem

Вот еще интересная проблемка (на текстовых сообщениях телефонов)
https://en.wikipedia.org/wiki/Year_2000 ... 10_problem

А вот про что я говорю. Год представлен в базе данных в виде двузначного числа. А нужны все четыре цифры. Для определения века используется метод окна - https://en.wikipedia.org/wiki/Date_windowing

Вот нетипичный пример из Микрософтовского Экселя
https://docs.microsoft.com/en-us/office ... ar-numbers

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

[zVlad]

На следущей неделе ИБМ подгонит новый мэйнфрэйм чтобы заменить старый. Причина замены весьма банальная. Этот мф был и есть DR сайт для другого мф, который менять не будут потому что уходят с мф совсем к концу следущего года (бог им в помощь), но поскольку некий срок закончился ДР станет невозможен. Вот поэтому только и меняют на новый.
В тоже время я плотно вовлечен в проект ухода с мф основного приложения. Стараюсь быть полезен по максимуму, но многие движения упираются в дибилизм Оракл на который собственно и переходится с нормального DB2.
Предпоследняя заморочка была в том что оракл символьное поле размером в 8 байт в дб2 воспринимал как поле 24 байта. Эту заморочку сегодня победили изменив какой-то параметр на стороне оракл (ОТG точнее).
Я с нашим дба оракла (москвич) дружу. Он мне столько страстей нарассказывал что мне его жалко стало.
Короче декабрь 2021 это дата когда я вновь должен буду потерять почву под ногами. Это будет (будет ли) второй раз в моей жизни. Первый был в 90-е в России из-за чего я оказался в Канаде и вот уже больше 20 лет проработал на мф.
В Канаде, или где угодно в мире, я бы работу на мф нашел. Но мне уже 65, да и если мф уйдут то мне уже предлагают дба позицию на оракл. Москвич уже жаловался что ему такое приложение что я тащу в дб2 совсем не хочется тащить как дба оракл. Мол возьми себе.

Неужели к концу следущего года я эту тему снова подниму как то? Вот будет круто!

[Flash-04]

Ты ж на пенсии уже. Можешь ходить и немного вредить (с)

[iDesperado]

солидная кантора. усилить дба, что не могли оракловый стедбай настроить, пенсионером, которому сложно различать processor cores и processor threads. причем отсутсвие у дба хоть каких нибудь сертификатов для конторы вообще не проблема.

[deev_a_v]

солидная кантора. усилить дба, что не могли оракловый стедбай настроить, пенсионером, которому сложно различать processor cores и processor threads. причем отсутсвие у дба хоть каких нибудь сертификатов для конторы вообще не проблема.

Сонная окологосударственная контора. Этим все сказано.

[zVlad]

Ты ж на пенсии уже. Можешь ходить и немного вредить (с)

По возрасту пенсинер, но работаю как работал и пенсию канадскую не получаю.
Зачем вредить? Я наоборот предлагал схему по которой уход с мф мог бы быть более успешным. Отказались. Теперь пусть сами заботятся об успехе.
Переходят они прямиком в Azure, кстати. С мф в облако! Более того с zos, db2, cobol на oracle, linux, java. Кастомеру надо чтобы те параметры sla что обеспечивал мф были обеспечены в Azure.
Мы уже перевели несколько серверов так или иначе завязанных на мф в Azure, и это уже создало проблемы не имевшиеся ранее, когда эти сервера были нашими. Прошлый викэнд я перезагружал реплику из db2 в sql. Одна таблице перезагружалась шесть часов, а их пять сотен. Да и причина перезагрузки была такой что за много лет без облака не случалась ни разу. Раз в неделю репликация останавливается по причине обрыва комминикации.
В плане перехода в облако надо будет определить потребные ресурсы в облаке. От этого будет зависить два важных параметра: sla, и цена облачной услуги. В принципе это будет процесс угадывания. Иным он и быть не может поскольку формулы пересчета параметров мф в параметры облачных ресурсов, тем более с одновременной, полной сменой софтвера не существует. Как быстро удастся подобрать облачные параметры чтобы удовлетворить требования sla и ожидания кастомера по цене одному богу известна.
Цель по срокам конец 2021, полтора года. Я уже заготовляю попкорн и предвкушаю сильные впечатления.

[zVlad]

В понедельник ИБМ подогнал мф. В среду его худо-бедно продиагностировали, худо-бедно подключили к сети. Вчера подключили диски.
Сегодня я попытался сконфигуривать мф как бы с нуля. Файрвол остановил эти попытки и оказалось что файрволщик сегодня в отпуске и никто другой ничем помочь не может.
Я подорвался и, несмотря на полный котедж гостей, поехал за 60 км в дата центр. В дата центре я зарядил конфигурацию, за руки держа парня занимающегося кабелями воткнул кабеля куда надо и загрузил сэндбокс систему. Она плохо загрузилась, крипто софтвэр для нового мф надо было бы обновить, но руки пока не дошли. Это было известно, но последние дни довелось бороться с кабельщиками, которые хотели затянуть на две-три недели процесс. Вот крипто и выпало из поля зрения.
Сегодня я долден был перенести девелопмент систему на новый мф, но уже сил не было бороться с проблемами, да еще и вернулся на котедж, последний этап на катере, голодный, злой. Послал все на хрен. До понедельника.
Но за две недели мы перенесем все, и дев и прод, на новый мф.