Демократизация мейнфреймов

[zVlad]

2zVlad
а можно я нарвусь уже на беспощадный игнор с вашей стороны ? ваша манера общения и нравоучения достали ...

Конечно можно, но Вы, извините, сами упорно нарывались.
Такая манера общения и нравоучительство, к которым Вы сами вынудили меня, мне неестественны и я тоже как все нормальные люди не люблю такие манеры и нравоучительство. Поверьте на слово, в жизни это так. Вообще то я человек толлерантный и много могу понять и пропустить, но в определенный момент дискуссий (гораздо реже в жизни) мне вдруг становится очевидным что с этим человеком бесполезно толлерантничать и можно не сдерживаться, тем более что сдерживание сродни насилию над собой, а это нездоровый фактор.
Ну и учтите как смягчающий фактор моей вины что мне, в свою очередь, тоже приходится много негативно читать в отношении себя и Вы не единственный манеры общения которого и нравоучительство меня тоже уже порядком достали. А еще больше и уже давным давно меня достало дремучее невежество в вопросах крупных ИТ архитектур, качественно иного уровня чем уровень ПС-ков.
Подходы с писюковым мышлением меня не только здесь на форуме достали но гораздо больше на работе, где, как наверное в большенстве контор, я опутан этими писюковыми решениями, которые затрудняют мне доступ к МФ, работа на которых собственно и является моей задачей. Это еще при том что мне удается выкручиваться и делать этот доступ короче чем требуется официально. Мне это удается потому что я умею находить подход к людям и угововаривать их делать для меня исключение и поблажки. Моя коллега, которая более покладиста и менее требовательная, постоянно стонет и плачет от официально предусмотренного доступа к МФ, который проходит через паутины из Citrix серверов, часть из которых вообще находятся в США, в то время как мы и наши МФ здесь в Канаде. Я считаю это просто вредительство.

[Dmitry67]

zVlad, у вас действительно странная риторика. Вот вы удивлялись что менеджеру вдалбливали, что мейнфремы лучше, а они поступили по своему. А вот я бы не удивился, что именно пообщавшись с вами они приняли противоположное высказываемое вами решение. Вот пример:

Багов в виртуальной машине нет и быть не может. Если бы они были то они бы уже себя давным давно проявили бы. Баги могут быть в каких нибудь других службах и сервисах входящих в zVM.

вы понимаете что после такого заявления любой адекватный менеджер, связанный с IT, у себя в голове сразу выставит галочку "мнению данного специалиста по сравнению систем доверять нельзя изза явной тенденциозности"?

[Zombie416]

качественно иного уровня чем уровень ПС-ков.

О. Так в чем же именно состоит "качественно иной уровень", на который вы постоянно ссылаетесь? Все время кажется что под PC и x86 вы подразумеваете IBM PC AT x286 образца 1984 года.

Воды с тех пор утекло много, и в x86 уже приехала и виртуализация, и MCA, и hot-swap/hot-plug/.., и т.д. А с чистой производительностью так и вообще дела обстоят лучше чем у МФ, и при этом дешевле.

Так что осталось такого качественно иного в МФ? Ну кроме системы сбора денег с пользователей основанной на MIPS-ах, до реализации которой продавцы Intel/AMD пока не дошли (хотя слухи ходили).

[zVlad]

качественно иного уровня чем уровень ПС-ков.

О. Так в чем же именно состоит "качественно иной уровень", на который вы постоянно ссылаетесь? Все время кажется что под PC и x86 вы подразумеваете IBM PC AT x286 образца 1984 года.

Воды с тех пор утекло много, и в x86 уже приехала и виртуализация, и MCA, и hot-swap/hot-plug/.., и т.д. А с чистой производительностью так и вообще дела обстоят лучше чем у МФ, и при этом дешевле.

Так что осталось такого качественно иного в МФ? Ну кроме системы сбора денег с пользователей основанной на MIPS-ах, до реализации которой продавцы Intel/AMD пока не дошли (хотя слухи ходили).

Нет я не подразумеваю IBM PC AT x286 образца 1984 года, не надо меня выставлять идиотом, пожалуйста. Наоборот это о МФ регулярно приходится здесь читать - это компьютер с перфокарточным вводом. И на МФ много воды утекло с 1964 года.

Да, для меня было в нове узнать о MCA, и hot-swap/hot-plug/. И я почитал даже больше чем мне было предложено и привел ссылку где это читал в надежде что если этого окажется недостаточно, но мне на это укажут. Не указали. Но из этой ссылки следует что по сравнению с МФ эта тема находится в самом своем зачаточном виде и выглядит очень непрактично (только dedicated процессора и только кратно 4-м полность с их памятью не больше и не меньше, процессора для замены выбывших "отбираются" у менее привелигированных систем) и вряд ли (поправьте) широко используется. Совсем иначе обстоят дела на МФ. Там все это используется всегда и везде без исключения. Потому что реализованно весьма практично и удобно, а это потому что работы в этом напралении на МФ ведутся уже лет двадцать. Все просто, надо только понять.

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

[zVlad]

zVlad, у вас действительно странная риторика. Вот вы удивлялись что менеджеру вдалбливали, что мейнфремы лучше, а они поступили по своему. А вот я бы не удивился, что именно пообщавшись с вами они приняли противоположное высказываемое вами решение. Вот пример:

Багов в виртуальной машине нет и быть не может. Если бы они были то они бы уже себя давным давно проявили бы. Баги могут быть в каких нибудь других службах и сервисах входящих в zVM.

вы понимаете что после такого заявления любой адекватный менеджер, связанный с IT, у себя в голове сразу выставит галочку "мнению данного специалиста по сравнению систем доверять нельзя изза явной тенденциозности"?

Когда я это писал, поверьте мне Дима, я знал о чем пишу и что мне найдут пример бьющий не в бровь а в глаз.

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

Вас, Дима, такое объяснение удовлетворяет или Вы будет повторять как заклинание что нет программ без багов с которым в принципе я согласен если мы говорим о программах вообще?

[zVlad]

zVlad, у вас действительно странная риторика. Вот вы удивлялись что менеджеру вдалбливали, что мейнфремы лучше, а они поступили по своему. А вот я бы не удивился, что именно пообщавшись с вами они приняли противоположное высказываемое вами решение. Вот пример:

Багов в виртуальной машине нет и быть не может. Если бы они были то они бы уже себя давным давно проявили бы. Баги могут быть в каких нибудь других службах и сервисах входящих в zVM.

вы понимаете что после такого заявления любой адекватный менеджер, связанный с IT, у себя в голове сразу выставит галочку "мнению данного специалиста по сравнению систем доверять нельзя изза явной тенденциозности"?

Касательно того как я с менеджерами работаю. Ваш пример не релевантен просто потому что с менеджерами мы совсем на другом уровне разговариваем, и совсем о другом. И Ваше преположение что я всего лишь пытаюсь "вдалбливать, что МФ лучше" тоже не имеет никакого отношения к тому что на самом деле происходило там. Ну и наконец, Дима, если бы я в самом деле обладал таким мощным влиянием на мнение менеджеров, то я бы наверно догадался вдалбливать им что МФ хуже и как результат они бы поступали по своему, т.е. диаметрально противоположно мне, и я был бы доволен.
Наивно это все, Дима, очень наивно. Уж извините другого ничего сказать не могу.

[zVlad]

....
2. проблемы перехода с IBM видел не раз: берут CABOL в без переделок забубенивают на оракл, а потом долго удивляются чего это блокировочный подход IBM так хренового работает на версионном оракле.

.....
2. Что такое CABOL и какое отношение он имеет к блокировочникам или версионникам?

.....

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

[iDesperado]

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

да я не обижаюсь, просто мне не приятно общаться с людьми которые на форумах решают какие-то свои психологические проблемы. вам явно нужно доказать свою правоту и вам пофигу на технические аспекты и аргументы. может у вас есть свои причины так вести разговор, но мне честно говоря в них разбираться не интересно, я кому считал это важно все, что хотел доказал. на самом деле мне бы многое было бы интересно поспрашивать о МФ, но от вас за последние пару лет я не услышал ни одного внятного пояснения. вы сыпите какими-то не нужными подробностями и терминами но не можете элементарно разьяснить чем RACF принципиально лучше банального LDAP.
что касается версионника то прикладухи под db2 всегда заточены на пессимистичный блокировочный режим. db2 как и все блокировочники в поисках компромисса между скоростью и concurrency изобрели тьму видов блокировок, от блокировок намерения до shared. в оракле такого зоопарка блокировок нет, поэтому если логику приложения переносить на версионный оракл в лоб, результат гарантированно окажется хреновым. если халтурить и не проводить редизайна логики прикладухи, то можно запросто получить дурное приложение которое будет фиговое на современных платформах, хотя и ворочилось на стареньком МФ.

[Dmitry67]

zVlad, то что вы написали относится к ядру VM. Vm же программный продукт, который содержит кучу всего, а не только собственно 'железную эмуляцию', про которую вы говорили. А в программном коде всегда бывают ошибки.

[zVlad]

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

.....
что касается версионника то прикладухи под db2 всегда заточены на пессимистичный блокировочный режим. db2 как и все блокировочники в поисках компромисса между скоростью и concurrency изобрели тьму видов блокировок, от блокировок намерения до shared. в оракле такого зоопарка блокировок нет, поэтому если логику приложения переносить на версионный оракл в лоб, результат гарантированно окажется хреновым. если халтурить и не проводить редизайна логики прикладухи, то можно запросто получить дурное приложение которое будет фиговое на современных платформах, хотя и ворочилось на стареньком МФ.

А можно было обойтись без неуместного эпитета "старенький"? Ладно хрен с ним пропустим.

Весь этот как Вы говорите заоопарк блокировок в приложениях никак не выражается, просто для них нет в языке конструкций, - это внутренне дело ДБ2, который сам их так или иначе разруливает. При переносе на версионник включается внутренний механизм версионника и в общем случае нужды переписыват логику не должно возникать. Если Вы не согласны приведите пример таких трудностей и как бы следовало с ними поступать. И мы на этом примере может и разберемся.
Другое дело когда мы делаем обратный перенос. Поскольку версионник - это оптимистический режим, то, как я понимаю, при таком переносе действительно требуется что-нибудь поделать, например, добавить коммитов, которых так не любят, точнее забывают о них, программисты на МФ (как поступают программисты на Оракл я не знаю).

А вопросы по МФ задавать не стесняйтесь. Я постараюсь как-нибудь изменить свой стиль объяснения чтобы сделать это более доходчиво.

[Dmitry67]

Я приведу пример.
Имеем два процесса. Процесс A меняет чтото в документе. Процесс B в этот момент пытается создать копию.

Блокировочник:
А начинает менять документ
B начинает читать его и останавливается изза блокировки
A делает commit
B копирует измененный документ

Версионник:
А начинает менять документ
B начинает читать его и читает оригинальную версию
A делает commit
B не дожидаясь этого делает копию документа ДО изменений

В итоге при переходе на версионник поведение меняется

[iDesperado]

2zVlad

старенький это именно возраст. т.е. заточенная на блокировочник прикладуха может неплохо работать на db2 и железе 10 летней давности, но при этом плохо на новом железе с ораклом.
пример: в дб2 я часто встречаю при организацию oltp нагрузки схему по разводу читателей и писателей. например у нас таблица accounts в нем поле balance, и таблица payments. в оракле у меня все просто, пишем в таблицу payments и в той же транзакции обновляем поле balance. поскольку оракл версионный это не создает никаких проблем любой читатель ради отчета может хоть несколько часов читать таблицу acounts не создавая проблем остальным. в db2 такой подход не приемлим, т.к. если читатель начнет читать таблицу accounts он не сможет получить консистентный отчет на уровне Read Commitedd, а более высокий уровень стопорнет пишушие транзакции, т.к. те буду ждать пока отчет с более высоким уровнем изоляции чем RC отпустит блокировки. в db2 я регулярно встречаю такой финт. вводится понятие закрытый период, асинхронный процесс, допустим раз в сутки "закрывает день" вычитывая payments поступившие за день и обновляет поле balance таблицы accounts. дальше что бы получить консистентный отчет на определенное время (на время Ч) читатель составляющий отчет читает на уровне RC balance и прибавляет к ним сумму payments за этот день зафиксированных до времени Ч. как видите оптимальные подходы db2 и оракла совершенно разные.
что плохо проэмулируется в оракле элементарно - оператор открывает окошко и db2 накладывает shared блокировку на запись (не дает изменить другим), не продумав последствия в оракле в лоб это можно проэмулировать SELECT FOR UPDATE, т.е. установкой эксклюзивной блокировкой, но тогда все открыватели должны открывать окошко последовательно.

[Zombie416]

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

В DB2 нет способов управления блокировками? Ну и при переходе на версионник проблемы именно что должны возникать.

Элементарный пример, работающий (медленно) в блокировочнике:

SELECT @x=Balance FROM UserBalance WHERE UserName='John'
...
UPDATE Balance=@x-1

В версионнике может запросто приводить к порче данных, если запустить 2 запроса параллельно.

Давайте лучше все-таки про достоинства МФ как класса, без баз. Базы это так, прикладная программа. Да, весь этот hotswap CPU появился в x86 недавно, и врядли используется сильно чаще чем МФ, поэтому людей щупавших это руками не так много. А людей которым это реально было надо, еще меньше (часто у вас на МФ процессоры практически горели?). Но факт - это сегодня есть в x86, а в Itanium-ах было давно. И сбойная память на лету обнаруживается и отключается, в том числе до того как это дошло до приложения, и т.д.

Лучше-хуже оно сделано чем в МФ - второй вопрос, а размер ячейки и отбираются ли ресурсы у менее привилегированных работающих систем, или менее привилегированные системы всегда простаивают в резерве, вообще бессмысленный в отрыве от цены. И современные x86 сервера - это тоже много серверов в одном, т.к. загрузить 96+ потоков даже обычного 4х процессорного сервера без многих VM крайне сложно.

Есть какие-то действительно принципиальные отличия?

[iDesperado]

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

я привел базы просто как элементарное объяснение почему миграция с МФ в unix/оракл могла хреново окончиться и причем там cobol.

[zVlad]

2zVlad

старенький это именно возраст. т.е. заточенная на блокировочник прикладуха может неплохо работать на db2 и железе 10 летней давности, но при этом плохо на новом железе с ораклом.
....

Мы в прошлом году летом перешли на z10, которое было аннонсированно за год полтора до этого. Это что по Вашему старое железо? db2 как впрочем и Оракл появились лет тридцать назад. То что Вы называете "новым" железом тоже в основном сформировалось пару десятков лет назад и лишь увеличивалась его производительность. Я честно хочу Вас понять, но всегда говорите такие вещи, которые просто шокирует своей непродуманостью. Как так получается?
Какие механизмы давно стандартизованного SQL могут мешать прикладухам "неплохо работать на db2 и ....но при этом плохо на .... оракл"? Объясните. То что Вы написали в Вашем примере не имееет никакого отношения к тому что Вы заявляете абстрактно. Я это Ваш пример еще поизучаю, но уже видно что Вам просто не нравится некая модель данных и Вы пытаетесь обяснить ее происхождения какими то недостатками ДБ2. На самом же деле моделирование данных в реляционных БД - это теория абстрагированная от любой конкретной реализации DBRM. Я изучал эту теорию в начале 90-х по книжке Дэйта "DB2 руководство по реляциооной БД". По ней же учились наши ребята пишущие для Оракл.