Comments 136
Как и с другими статьями о мейнфреймах, основной вопрос который остался после прочтения — "зачем"?
Ну то есть реально интересно, какие задачи сегодня все еще требуют разработки на мейнфреймах, и не могут быть решены в облаке (более эффективно)? Понимаю, что статья не об этом, но мне правда любопытно.
Часть компаний не может уйти с мейнфреймов, потому что любая миграция с одной платформы на другую — дорогое удовольствие и затратное по времени. Просто представьте вам нужно поменять железо, уволить/переобучить старых специалистов, нанять новых и т.п.
Часть компаний патылись и у них не вышло (списка историй нет, но, например, помню, в каком-то штате в США отделение полиции по выдаче водительских прав пытались уйти с мейнфреймов, в итоге имели очень много проблем с этим и вернулись обратно).
Т.к. всё ещё есть крупные компании, использующие мейнфреймы, существуют и ПО мониторинга (сети, хранилища данных, базы данных, самой z/OS и т.п.). Это ПО тоже разрабытывается.
Часть компаний патылись и у них не вышло (списка историй нет, но, например, помню, в каком-то штате в США отделение полиции по выдаче водительских прав пытались уйти с мейнфреймов, в итоге имели очень много проблем с этим и вернулись обратно).
Т.к. всё ещё есть крупные компании, использующие мейнфреймы, существуют и ПО мониторинга (сети, хранилища данных, базы данных, самой z/OS и т.п.). Это ПО тоже разрабытывается.
Немного напоминает на переход с ЕС на персоналки. Тянули пока можно было найти специалистов и запчасти для поддержания в состоянии. Потом наконец дошли что ни того ни другого. При переезде оказалось что процентов 90 задач н кому не нужны и табуляграммы использовались исключительно в хозяйственных целях.
Легаси код поддерживают в основном по экономическим причинам. Но экономика легаси кода на php или питоне мне понятна. Компаниям дешевле нанять студентов на entry level зарплату, чем переписывать.
Но с теми проблемами которые вы описали в статье (в том числе нехватки кадров), неужели выгоднее находить программистов мейнфреймов, чем переучивать или нанять новых итд?
Тот же пример с водительскими правами. Я, конечно, не в курсе всех деталей, но мне почему то кажется, что это симптом плохого управления, а не конкретных технических решений. Зачем вообще локальному DMV свои кастомные решения? Почему нельзя воспользоваться готовыми? А если нельзя, то я уверен, что талантливая команда ребят с горящими глазами, и опытным лидом, может написать систему управления выдачи водительских прав на современном стэке, за несколько месяцев. Зачем им свои программисты, почему нельзя нанять подрядчика? Да и какие там задачи требуют вычислений на мейнфреймах? Это же же обычный CRUD.
Нехватка кадров для мейнфреймов — проблема частично надуманная.
Там где мейнфреймы исторически более распространены: США, отдельные страны Европы — специалистов больше. В России — постепенно становится меньше, ибо и самих мейнфреймов, особенно современных, очень мало.
Да и новых специалистов обучить — не космически сложная задача. Выпускник после ИТ-вуза, который ни разу не сталкивался с платформой вполне осваивается за полгода-год.
Насчет миграции. Не зная конкретной задачи и всех ее взаимосвязей очень сложно оценить затратность миграции на другую платформу и другой стек софта. И совсем не факт, что после смены платформы стоимость эксплуатации останется такой же или снизится.
Насколько я знаю, многие конечные пользователи (компании) вполне довольны мейнфреймами и их возможностями и не собираются менять платформу в обозримой перспективе.
Да, любой бизнес считает стоимость владения и пытается ее снизить. Миграция на другой стек/платформу — один из вариантов.
Лично видел несколько проектов, когда руководству компании «заносили» идею что на другой платформе/стеке все станет гораздо быстрее/эффективнее/дешевле. И ни один раз видел что после выстраивания аналогичного решения на другой платформе оно не давало достаточных преимуществ и принималось решение остаться на мейнфрейме.
Там где мейнфреймы исторически более распространены: США, отдельные страны Европы — специалистов больше. В России — постепенно становится меньше, ибо и самих мейнфреймов, особенно современных, очень мало.
Да и новых специалистов обучить — не космически сложная задача. Выпускник после ИТ-вуза, который ни разу не сталкивался с платформой вполне осваивается за полгода-год.
Насчет миграции. Не зная конкретной задачи и всех ее взаимосвязей очень сложно оценить затратность миграции на другую платформу и другой стек софта. И совсем не факт, что после смены платформы стоимость эксплуатации останется такой же или снизится.
Насколько я знаю, многие конечные пользователи (компании) вполне довольны мейнфреймами и их возможностями и не собираются менять платформу в обозримой перспективе.
Да, любой бизнес считает стоимость владения и пытается ее снизить. Миграция на другой стек/платформу — один из вариантов.
Лично видел несколько проектов, когда руководству компании «заносили» идею что на другой платформе/стеке все станет гораздо быстрее/эффективнее/дешевле. И ни один раз видел что после выстраивания аналогичного решения на другой платформе оно не давало достаточных преимуществ и принималось решение остаться на мейнфрейме.
Нехватка кадров для мейнфреймов — проблема частично надуманная.
Хотелось бы дополнить. У нас рыночная экономика, поэтому за исключением каких-то совершенно космически редких случаев, вопрос всего лишь в цене. То есть, всегда к «не хватает специалистов» нужно приписывать «за такие-то деньги».
Так ведь очевидно, что можно же нанять людей напрямую из IBM. Правда платить им придётся чудовищно дорого, но специалисты там всегда есть.
Нехватка кадров — она для задач, а не для компьютеров. Если у вас задача требует мейнфрейма (или пары тысяч машин в кластере), специалиста вы будете искать долго. И выращивать — тоже.
На моей памяти, мне приходили письма от хедхантеров между 2009-2014годах, и, судя по приватной беседе, в 2019-ом, что-то шевелилось, но человек был из другого проекта; свежее информации нет. Один немаленький банк всё пытался переписать процессинговую софтину с мейнфреймов на что-то современное. Собственно преблемы (было?) две.
— управленческая (смена проджект менеджеров, смены приоритетов, т.п.)
— сложность проекта: как это переписать так, чтобы и старое жило, и на новое переключить, и перформанс старого вцелом ок;
Я, когда собеседовался туда в эээ… 2013 (или '14), и разговаривал с одним из ПМов, было грустно — проект переписывания сложный, система живёт и работает, писать много.
(Могу поинтересоваться, как там сейчас, если интересует).
— управленческая (смена проджект менеджеров, смены приоритетов, т.п.)
— сложность проекта: как это переписать так, чтобы и старое жило, и на новое переключить, и перформанс старого вцелом ок;
Я, когда собеседовался туда в эээ… 2013 (или '14), и разговаривал с одним из ПМов, было грустно — проект переписывания сложный, система живёт и работает, писать много.
(Могу поинтересоваться, как там сейчас, если интересует).
Облако — не панацея от всех бед.
Везде есть своя стоимость внедрения и сопровождения и под конкретную задачу нужно много разных факторов учитывать.
Опять, же современный мейнфрейм вполне себе интегрируется в облако.
Ну и большой вопрос, а что именно значит «эффективнее»?
Если мейнфрейм(ы) в компании уже есть, есть коллектив который сопровождает существующее ПО, есть своя команда или партнеры, которые разрабатывают что-то новое (или модернизируют существующее ПО), то может запросто оказаться, что разработать или внедрить что-то новое, что будет работать «рядом» на той же платформе, гораздо более эффективно (по времени реализации, по времени внедрения, по стоимости сопровождения), чем пытаться это сделать на другой платформе.
Кроме того, автор статьи описывает проблемы, с которыми сталкивается далеко не каждый разработчик ПО для ОС z/OS. Работа в нулевом ключе, это по сути работа с правами «ядра» системы. Это весьма привилегированный режим, который дает доступ к памяти других процессов/приложений. Обычному прикладному ПО, которое занимается обработкой данных или обслуживанием веб-запросов это не требуется.
Соответственно и «тяжелая артиллерия» для специфичной отладки требуется тоже далеко не всегда и не всем. Для той-же Java например, инструментарий отладки/трассировки тот же самый что и для других платформ.
Везде есть своя стоимость внедрения и сопровождения и под конкретную задачу нужно много разных факторов учитывать.
Опять, же современный мейнфрейм вполне себе интегрируется в облако.
Ну и большой вопрос, а что именно значит «эффективнее»?
Если мейнфрейм(ы) в компании уже есть, есть коллектив который сопровождает существующее ПО, есть своя команда или партнеры, которые разрабатывают что-то новое (или модернизируют существующее ПО), то может запросто оказаться, что разработать или внедрить что-то новое, что будет работать «рядом» на той же платформе, гораздо более эффективно (по времени реализации, по времени внедрения, по стоимости сопровождения), чем пытаться это сделать на другой платформе.
Кроме того, автор статьи описывает проблемы, с которыми сталкивается далеко не каждый разработчик ПО для ОС z/OS. Работа в нулевом ключе, это по сути работа с правами «ядра» системы. Это весьма привилегированный режим, который дает доступ к памяти других процессов/приложений. Обычному прикладному ПО, которое занимается обработкой данных или обслуживанием веб-запросов это не требуется.
Соответственно и «тяжелая артиллерия» для специфичной отладки требуется тоже далеко не всегда и не всем. Для той-же Java например, инструментарий отладки/трассировки тот же самый что и для других платформ.
Очевидные банки, например.
Затем что linux и x86 платформа не справится с потоком данных. К примеру сейчас на рынке нет realtime менеджера сообщений способного пережевать то что проходит через наш мэйнфрейм
Кластер кафки?
кафка не реалтайм и если не править настройки — может потерять сообщение(а оно может ой как много стоить), а если править — кластер кафки по цене будет как весь мейнфрейм на котором еще и бд работает. еще пожалуй стоит упомянуть что кафка это не менеджер, а очередь сообщений — в брокера превращается легко, а в менеджера очень не просто
По умолчанию там семантика at-least-once, и если не пожадничать с репликацией, то вроде бы не должна терять сообщения.
Насчёт реалтайм тут больше вопрос к консьюмерам, чтобы успевали всё вычитывать и процессить, скорее.
«вроде бы не должна», когда вопрос стоит о потерях сопоставимых с твоей зарплатой за полжизни — очень неуверенная формулировка. кафка по умолчанию не синхронизирует запись на диск, сразу помечает как принятое
«Насчёт реалтайм тут больше вопрос к консьюмерам», нет, если сделать из кафки менеджера сообщений — вопросы будут именно к ней. вы видимо не понимаете различий:
очередь — передает в том же порядке как и поступило, конечные точки неизменны
брокер — может менять конечные точки сообщений
менеджер — способен менять порядок, тело сообщений, конечные точки
основы можете прочесть тут: www.oreilly.com/library/view/understanding-message-brokers/9781492049296
для более глубокого понимания google и comparison message broker
«Насчёт реалтайм тут больше вопрос к консьюмерам», нет, если сделать из кафки менеджера сообщений — вопросы будут именно к ней. вы видимо не понимаете различий:
очередь — передает в том же порядке как и поступило, конечные точки неизменны
брокер — может менять конечные точки сообщений
менеджер — способен менять порядок, тело сообщений, конечные точки
основы можете прочесть тут: www.oreilly.com/library/view/understanding-message-brokers/9781492049296
для более глубокого понимания google и comparison message broker
Ну как уже отметили раньше — достаточно сложно уйти с этой инфраструктуры.
Вот причины:
Многие компании уже влили достаточно денег на этот мейнфреймовый ад. (Речь идёт не о десятках тысяч УЕ, и даже не о сотнях) — а все благодаря (практически) безграничному вертикальному масштабированию.
Носители — отдельная проблема. Тейпы используются активно, а перегон архива — это не просто загнать данные на флешку.
Ходят ещё мнение среди мейнфрейм-адептов что мейнфрейм предоставляет недостижимый уровень безопасности, что достаточно часто является правдой, но с ньюансом — когда есть непопулярная архитектура — сторонних адептов в ней будет не так много.
А ещё система которая работает 30 лет, конфиги трогались 25 лет назад последний раз по мануалу 40-летней давности — это прекрасно (нет). Страшно трогать.
Но, минусы… Про них нужен отдельный пост. Лицензирование, интерфейсы, особенности разработки, процессы и кастомер-сервис.
Имхо. Это просто айти в общем понимании, только наоборот.
Хочу добавить — безопасность совмещенная уровнем производительности
Я считаю большим плюсом менфреймов и z/OS то, что код, написанный и скомпилированный десятки лет назад можно исполнять на современных мейнфреймах и современном уровне ОС/ПО. Для бизнеса это вполне себе выгода, что софт не придется «внезапно» переписывать или перекомпилировать при апгрейде железа/ОС.
Если система работает 30 лет и почти не требует обслуживания — с точки зрения бизнеса это прекрасно. Если даже за это время сменилось поколение специалистов, но есть документация, по которой вновь пришедшие специалисты могут конфигурацию починить или поменять — тоже отлично.
А вот если знания о том как работает система успешно «потеряны» — то это вопрос к тому же бизнесу и менеджменту и тут сама платформа не принципиальна. Любое «давно и стабильно работающее» решение можно превратить в черный ящик который «страшно трогать» если не позаботиться о сохранности документации и хранении/передаче знаний о системе/решении. Это один из рисков, который бизнес должен учитывать.
Почему все таки «мейнфреймовый ад»?
Если речь про операционную систему (z/OS) — там действительно очень много особенностей, которые изначально непонятны при наличии Windows/Linux/Unix бекграунда.
Но, если принять «правила игры» в архитектуре системы, она становится вполне понятной, предсказуемой и управляемой.
Некоторые особенности накоплены исторически, сейчас выглядят архаично, но как раз обеспечивают долговременную совместимость, что востребовано у клиентов.
Уже настроенная система/комплекс как правило работает стабильно и не требует существенных усилий по поддержке. Как отмечено в статье, можно годами не ставить апдейты и спокойно эксплуатировать то что есть.
Если система работает 30 лет и почти не требует обслуживания — с точки зрения бизнеса это прекрасно. Если даже за это время сменилось поколение специалистов, но есть документация, по которой вновь пришедшие специалисты могут конфигурацию починить или поменять — тоже отлично.
А вот если знания о том как работает система успешно «потеряны» — то это вопрос к тому же бизнесу и менеджменту и тут сама платформа не принципиальна. Любое «давно и стабильно работающее» решение можно превратить в черный ящик который «страшно трогать» если не позаботиться о сохранности документации и хранении/передаче знаний о системе/решении. Это один из рисков, который бизнес должен учитывать.
Почему все таки «мейнфреймовый ад»?
Если речь про операционную систему (z/OS) — там действительно очень много особенностей, которые изначально непонятны при наличии Windows/Linux/Unix бекграунда.
Но, если принять «правила игры» в архитектуре системы, она становится вполне понятной, предсказуемой и управляемой.
Некоторые особенности накоплены исторически, сейчас выглядят архаично, но как раз обеспечивают долговременную совместимость, что востребовано у клиентов.
Уже настроенная система/комплекс как правило работает стабильно и не требует существенных усилий по поддержке. Как отмечено в статье, можно годами не ставить апдейты и спокойно эксплуатировать то что есть.
Уже настроенная система/комплекс как правило работает стабильно и не требует существенных усилий по поддержке
Имею мнение, что дело тут далеко не в мейнфрейме. Любая система настроенная правильным образом позволит наращивать производительность и при этом не требовать обслуживания.
«Я считаю большим плюсом менфреймов и z/OS то, что код, написанный и скомпилированный десятки лет назад можно исполнять на современных мейнфреймах и современном уровне ОС/ПО».
Это как бы половина истории, мед.
Однако, полуправда — это не правда, ведь так?
Код написанный и откомпилированный хх лет может и работает. Но написан он на древнем синтаксисе языков с использованием приемов и практик, которые сегодня не просто устарели — многие просто запрещены для использования в новых программах.
В результате, поддержка такого кода становится малоприятным и бесперспективным занятием. В том смысле, что навыки полученные на такой работе не получиться применить в чем то новом, потому что теперь подобные вещи делаются по-другому и, зачастую, гораздо проще. Рекомендовать такую работу молодым я бы не стал. Те кто ожидают пенсии — пусть занимаются. Все равно этот код по-хорошему надо переписывать.
Ну, и, конечно, гладко все миграции проходят только на бумаге и в рекламных проспектах. В реальности, можно просто побраузить список ошибок в RETAIN на эту тему чтобы увидеть что далеко не все так гладко.
Кроме того, надо посмотреть какими силами обеспечивается эта совместимость. А цена за это — жесткий вендор лок по всему начиная от железа и заканчивая компиляторами. Потому и очень ограниченный список софта. Если уж так сравнивать, то программы написанные под MS DOS можно запускать на Win10 :-).
Это как бы половина истории, мед.
Однако, полуправда — это не правда, ведь так?
Код написанный и откомпилированный хх лет может и работает. Но написан он на древнем синтаксисе языков с использованием приемов и практик, которые сегодня не просто устарели — многие просто запрещены для использования в новых программах.
В результате, поддержка такого кода становится малоприятным и бесперспективным занятием. В том смысле, что навыки полученные на такой работе не получиться применить в чем то новом, потому что теперь подобные вещи делаются по-другому и, зачастую, гораздо проще. Рекомендовать такую работу молодым я бы не стал. Те кто ожидают пенсии — пусть занимаются. Все равно этот код по-хорошему надо переписывать.
Ну, и, конечно, гладко все миграции проходят только на бумаге и в рекламных проспектах. В реальности, можно просто побраузить список ошибок в RETAIN на эту тему чтобы увидеть что далеко не все так гладко.
Кроме того, надо посмотреть какими силами обеспечивается эта совместимость. А цена за это — жесткий вендор лок по всему начиная от железа и заканчивая компиляторами. Потому и очень ограниченный список софта. Если уж так сравнивать, то программы написанные под MS DOS можно запускать на Win10 :-).
Эмм, но это же «перпендикулярно».
Совместимость — это хорошо. Позволяет меньше «бояться» апгрейдов ОС и прикладного ПО. Но, никто не мешает параллельно, при необходимости, планово обновлять и заменять прикладной код, если он чему-то не соответсвует.
Миграции прикладного ПО со старых версий z/OS и старого железа периодически выполнял своими руками или участвовал в команде, которая этим занималась.
Да, мир не идеален и проблемы бывают, но обычно так или иначе решаются. Специальными опциями операционной системы или прикладного ПО, небольшими ухищрениями или обращением в поддержку IBM, если это «баг».
В современную версию z/OS портировано много опенсорсного ПО и ЯП (Java, Python, Perl и т.д.), даже докер-контейнеры (внутри которых линукс) можно внутри z/OS запускать.
Совместимость — это хорошо. Позволяет меньше «бояться» апгрейдов ОС и прикладного ПО. Но, никто не мешает параллельно, при необходимости, планово обновлять и заменять прикладной код, если он чему-то не соответсвует.
Миграции прикладного ПО со старых версий z/OS и старого железа периодически выполнял своими руками или участвовал в команде, которая этим занималась.
Да, мир не идеален и проблемы бывают, но обычно так или иначе решаются. Специальными опциями операционной системы или прикладного ПО, небольшими ухищрениями или обращением в поддержку IBM, если это «баг».
В современную версию z/OS портировано много опенсорсного ПО и ЯП (Java, Python, Perl и т.д.), даже докер-контейнеры (внутри которых линукс) можно внутри z/OS запускать.
«В современную версию z/OS портировано много опенсорсного ПО и ЯП (Java, Python, Perl и т.д.), даже докер-контейнеры (внутри которых линукс) можно внутри z/OS запускать.»
И смысл запускать докер контейнеры в специфической архитектуре на супердорогом железе, если это можно делать гораздо проще и сильно дешевле в Linux/AMD64/ARM/Power?
И смысл запускать докер контейнеры в специфической архитектуре на супердорогом железе, если это можно делать гораздо проще и сильно дешевле в Linux/AMD64/ARM/Power?
Потому что это позволяет запускать очень много «docker-based» ПО и решений без прямого их портирования в z/OS и при этом «рядом» с нативными z/OS приложениями. Ну как банальный пример — это может быть веб-приложение на любом современном фреймворке, которое будет «ходить» за данными к z/OS приложениям (DB2, MQ, CICS, IMS и т.д.) по очень короткому маршруту, т.е. с минимальными задержками.
При этом коллектив, сопровождающий приложения внутри докера, будет работать с привычными для них кросс-платформенными инструментами, возможно даже не зная того, что докер-инстанс работает как один из процессов внутри z/OS.
Т.е. это опять же про совместимость, оптимизацию и совместное существование того, что уже работает на платформе System z, с новыми/популярными технологиями и методиками.
При этом коллектив, сопровождающий приложения внутри докера, будет работать с привычными для них кросс-платформенными инструментами, возможно даже не зная того, что докер-инстанс работает как один из процессов внутри z/OS.
Т.е. это опять же про совместимость, оптимизацию и совместное существование того, что уже работает на платформе System z, с новыми/популярными технологиями и методиками.
Ну т.е. как костыль для дедушки.
Покупать Z чтобы запускать на нем только контейнеры смысла нет.
То же относится к приложениям на Java, Python и т.д.
Покупать Z чтобы запускать на нем только контейнеры смысла нет.
То же относится к приложениям на Java, Python и т.д.
Можно конечно и так это воспринимать.
Я не знаю, обосновано ли сейчас покупать новый мейнфрейм под контейнеры. Это нужно смотреть задачу, узнавать стоимость решения и считать стоимость покупки и владения.
Я точно знаю, что IBM продает мейнфреймы для «Linux-only» решений и цена на них может быть весьма привлекательной.
Читал что есть кейсы, когда определенное количество x86 серверов вместе с сопутствующим оборудованием (коммутаторы, маршрутизаторы и т.п.) заменялось одним мейнфреймом и это приносило выгоду. Меньшее потребление электроэнергии, меньше задержек, больше резерв по мощности.
У меня самого таких проектов не было, но вполне допускаю, что приобрести один мейнфрейм определенной конфигурации может оказаться дешевле, чем пачка X86-серверов и смежного оборудования.
Я не знаю, обосновано ли сейчас покупать новый мейнфрейм под контейнеры. Это нужно смотреть задачу, узнавать стоимость решения и считать стоимость покупки и владения.
Я точно знаю, что IBM продает мейнфреймы для «Linux-only» решений и цена на них может быть весьма привлекательной.
Читал что есть кейсы, когда определенное количество x86 серверов вместе с сопутствующим оборудованием (коммутаторы, маршрутизаторы и т.п.) заменялось одним мейнфреймом и это приносило выгоду. Меньшее потребление электроэнергии, меньше задержек, больше резерв по мощности.
У меня самого таких проектов не было, но вполне допускаю, что приобрести один мейнфрейм определенной конфигурации может оказаться дешевле, чем пачка X86-серверов и смежного оборудования.
Хех, учитывая что IBM продает сервера на Power для этих целей, я не то чтобы сомневаюсь в ваших словах, но это как минимум странно.
Может запросто оказаться что подразделения IBM по продаже System p (Power) и System z конкурируют между собой за потенциальных клиентов. Но — это уже мои догадки фантазии. Я не работал внутри IBM и не знаю как там устроена внутренняя кухня.
System p уже давно нет, больше 10 лет. Их сменили IBM Power Systems, которые одинаковые для i, aix и linux.
А мне так нравилось тогда именование: System p, System z, System i, System x.
Ок, спасибо, запомню, Power Systems :)
Да, System z теперь тоже именуется IBM Z. Никак не привыкну.
Ок, спасибо, запомню, Power Systems :)
Да, System z теперь тоже именуется IBM Z. Никак не привыкну.
Хех, а я все живу в мире S/390, AS/400 и RS/6000 :-).
Но тут смысл в том, что сегодня Power — это общее железо для 3-х oc (если не считать разные версии Linux).
IBM перманентно хочет унифицировать вообще все железо, в том числе и для Z сфокусировавшись на Power. Пока c Z не получилось, но, я так думаю, попытки не оставят. Просто слишком дорого продолжать делать процессор для одной специфической машины. Думаю, в конце концов, сделают какой нибудь оптимизированный транслятор с z в Power или что нибудь в этом роде и таким образом разрешится.
Но тут смысл в том, что сегодня Power — это общее железо для 3-х oc (если не считать разные версии Linux).
IBM перманентно хочет унифицировать вообще все железо, в том числе и для Z сфокусировавшись на Power. Пока c Z не получилось, но, я так думаю, попытки не оставят. Просто слишком дорого продолжать делать процессор для одной специфической машины. Думаю, в конце концов, сделают какой нибудь оптимизированный транслятор с z в Power или что нибудь в этом роде и таким образом разрешится.
«При этом коллектив, сопровождающий приложения внутри докера, будет работать с привычными для них кросс-платформенными инструментами, возможно даже не зная того, что докер-инстанс работает как один из процессов внутри z/OS».
У меня закрадывается устойчивое подозрение, что вы никогда в жизни не создавали контейнер, признайтесь, а повторяете тексты из рекламы, не совсем понимая о чем речь ;-). Потому что как бы «подозревать» на какой платформе будет крутиться контейнер разработчик начинает еще на этапе его создания ;-).
У меня закрадывается устойчивое подозрение, что вы никогда в жизни не создавали контейнер, признайтесь, а повторяете тексты из рекламы, не совсем понимая о чем речь ;-). Потому что как бы «подозревать» на какой платформе будет крутиться контейнер разработчик начинает еще на этапе его создания ;-).
Ну вообще мы с коллегой как раз недавно разворачивали z/CX у себя в системе и собирали Docker-образы для публикации туда.
Нюанс конечно есть, образ нужно собрать для архитектуры s390x (Linux for z).
На docker-hub готовых образов для этой платформы (IBM Z) сейчас чуть более 7300.
Redhat, Suse, Ubuntu имеют готовые дистрибутивы и пакеты для платформы.
Т.е. собрать докер-образ точно не сложнее чем под любую другую платформу.
А если приклад написан на чем-то более «высокоуровневом», Java, Node.js и т.п., то при наличии «базового» образа с бинарными зависимостями от платформы поверх него построить образ с прикладным приложением — в принципе ровно те же действия что и для других платформ. Скрипты, Javascript-код или Java-классы будут ровно те же самые.
И точно докер-контейнеру не будет заметных глазу различий между докером на Linux for z и докером работающим внутри z/OS.
Нюанс конечно есть, образ нужно собрать для архитектуры s390x (Linux for z).
На docker-hub готовых образов для этой платформы (IBM Z) сейчас чуть более 7300.
Redhat, Suse, Ubuntu имеют готовые дистрибутивы и пакеты для платформы.
Т.е. собрать докер-образ точно не сложнее чем под любую другую платформу.
А если приклад написан на чем-то более «высокоуровневом», Java, Node.js и т.п., то при наличии «базового» образа с бинарными зависимостями от платформы поверх него построить образ с прикладным приложением — в принципе ровно те же действия что и для других платформ. Скрипты, Javascript-код или Java-классы будут ровно те же самые.
И точно докер-контейнеру не будет заметных глазу различий между докером на Linux for z и докером работающим внутри z/OS.
Вот, вот, уже ближе к реальности ;-). Но, согласитесь, есть же разница между «не сложнее чем» и «даже не зная».
Что касается сложности, то это сильно зависит от приложения. Да, c Java и JS будет попроще.
Но вот с приложениями на C и CPP все может быть гораздо интереснее. Линукс под платформу — это одно. А вот куча зависимостей — это совсем другое. А собирать либы самому под очень специфическую архитектуру — это ой какое интересное занятие. И это еще до всяких контейнеров.
А дальше, когда изрядно помучившись, вы все соберете, и оно даже заработает, окажется, что скорость работы как на не самом свежем лаптопе :-). И вот тут начинаются настоящие танцы с бубном.
Да, сейчас глянул на докере действительно 7340 образов под Z. Для сравнения, на x86-64 — 4,182,380.
Что касается сложности, то это сильно зависит от приложения. Да, c Java и JS будет попроще.
Но вот с приложениями на C и CPP все может быть гораздо интереснее. Линукс под платформу — это одно. А вот куча зависимостей — это совсем другое. А собирать либы самому под очень специфическую архитектуру — это ой какое интересное занятие. И это еще до всяких контейнеров.
А дальше, когда изрядно помучившись, вы все соберете, и оно даже заработает, окажется, что скорость работы как на не самом свежем лаптопе :-). И вот тут начинаются настоящие танцы с бубном.
Да, сейчас глянул на докере действительно 7340 образов под Z. Для сравнения, на x86-64 — 4,182,380.
Cогласен, нужно было выразиться точнее, «не зная» в разрезе «докер в Linux on z» или «докер в z/OS».
А часто приходится сталкиваться с самостоятельной сборкой библиотек? Правда любопытно.
Да, там бывают интересности иногда, например с ассемблерными вставками. Но, по моему, процесс компиляции/сборки для s390x будет не особо отличаться от такого же для, например, ARM или PowerPC. Компилятор для s390x вполне стандартный gcc, никакой «проприетарщины».
В моей нынешней «практике» практически всегда пользуюсь уже готовыми пакетами от Redhat/Suse/Ubuntu, но и собственно Linux-ов у меня в «ведении» мало, поэтому не показатель конечно.
А часто приходится сталкиваться с самостоятельной сборкой библиотек? Правда любопытно.
Да, там бывают интересности иногда, например с ассемблерными вставками. Но, по моему, процесс компиляции/сборки для s390x будет не особо отличаться от такого же для, например, ARM или PowerPC. Компилятор для s390x вполне стандартный gcc, никакой «проприетарщины».
В моей нынешней «практике» практически всегда пользуюсь уже готовыми пакетами от Redhat/Suse/Ubuntu, но и собственно Linux-ов у меня в «ведении» мало, поэтому не показатель конечно.
Ну вы попробуйте просто даже код из какого нибудь среднего размера проекта на CPP перекомпилировать под Z с x86-64 и потом позапускать.
Лет 7 назад точно собирал «свежий» на тот момент PostgreSQL, так как в доступных бинарных пакетах была более старая версия.
С одной стороны — раз были бинарные пакеты, значит работу по портированию кто-то когда-то уже выполнил.
С другой стороны — новая версия собралась и заработала без каких-то особых усилий.
А вот собрать Java (по моему это был Oracle JDK) у меня в свое время не получилось. В коде попадались вставки ассемблера X86. Моих познаний в ассемблере было точно недостаточно чтобы «сконвертировать» это в ассемблер IBM z, поэтому тогда бросил эту затею.
Я хочу сказать что усилия по портированию проекта C/C++ на платформу s390x (Linux for IBM Z) будут сравнимы с такими же усилиями по портированию на другие платформы (Linux на ARM например).
При этом, портирование такого же проекта в z/OS уже будет гораздо сложнее, так как архитектура системы значительно отличается от Linux.
С одной стороны — раз были бинарные пакеты, значит работу по портированию кто-то когда-то уже выполнил.
С другой стороны — новая версия собралась и заработала без каких-то особых усилий.
А вот собрать Java (по моему это был Oracle JDK) у меня в свое время не получилось. В коде попадались вставки ассемблера X86. Моих познаний в ассемблере было точно недостаточно чтобы «сконвертировать» это в ассемблер IBM z, поэтому тогда бросил эту затею.
Я хочу сказать что усилия по портированию проекта C/C++ на платформу s390x (Linux for IBM Z) будут сравнимы с такими же усилиями по портированию на другие платформы (Linux на ARM например).
При этом, портирование такого же проекта в z/OS уже будет гораздо сложнее, так как архитектура системы значительно отличается от Linux.
1. Просто PG делает официальную версию под Z, поэтому в их код уже внесены нужные патчи.
2. Нет, не будут, потому что ARM поддерживается гораздо лучше в библиотеках.
2. Нет, не будут, потому что ARM поддерживается гораздо лучше в библиотеках.
1. Да, я про это и говорил.
2. Т.е. только потому, что готовых библиотек под ARM скорее всего больше?
Я имел в виду, что если взять проект, написанный на C/C++ для Linux/X86, который имеет зависимости от готовых библиотек, входящих в стандартный «пакет» дистрибутивов (Redhat, Ubuntu, Suse), то затраты на адаптацию этого проекта под новую для проекта платформу будут примерно одинаковы для разных Linux-платформ, включая Linux/IBM z.
2. Т.е. только потому, что готовых библиотек под ARM скорее всего больше?
Я имел в виду, что если взять проект, написанный на C/C++ для Linux/X86, который имеет зависимости от готовых библиотек, входящих в стандартный «пакет» дистрибутивов (Redhat, Ubuntu, Suse), то затраты на адаптацию этого проекта под новую для проекта платформу будут примерно одинаковы для разных Linux-платформ, включая Linux/IBM z.
Ну там же еще и версии имеют значение. Вообщем, не простое это дело — портировать на другие платформы. Но чем более популярна платформа — тем больше шансы что решение (в виде фиска, например) уже имеется. Менее популярна — все хуже. С компиляторами, опять же. Например, есть CLang для z?
Да, есть.
Для Linux/z, пакеты Ubuntu: clang s390x.
Для z/OS clang идет в составе продукта «XL C/C++ V2.4.1». Ссылочка: XL C/C++ V2.4.1 for z/OS V2.4
Для Linux/z, пакеты Ubuntu: clang s390x.
Для z/OS clang идет в составе продукта «XL C/C++ V2.4.1». Ссылочка: XL C/C++ V2.4.1 for z/OS V2.4
UFO just landed and posted this here
Не лучший настрой для проекта по миграции :-).
Таким проектом должны рулить полные энтузиазма и уверенности в своих способностях люди. А тут слышится крайний скепсис и недоверие к новым технологиям.
Ну и MФ — это, конечно, не облако. Расширяемость МФ ограничена конкретным физическим железом в вашем вц. А по времени добавление новой z системы в энвайромент — это месяцы (если не годы) от начала переговоров и оформления требований, закупки, поставки, тестирования и т.д.
Таким проектом должны рулить полные энтузиазма и уверенности в своих способностях люди. А тут слышится крайний скепсис и недоверие к новым технологиям.
Ну и MФ — это, конечно, не облако. Расширяемость МФ ограничена конкретным физическим железом в вашем вц. А по времени добавление новой z системы в энвайромент — это месяцы (если не годы) от начала переговоров и оформления требований, закупки, поставки, тестирования и т.д.
UFO just landed and posted this here
Разница не в том, что у вас есть дополнительные мощности. А в том, как быстро вы эти мощности можете расширять по необходимости за пределы имеющегося железа (2 МФ в вашем случае). Т.е. сколько времени у вас займет покупка, доставка, настройка третьего, например.
Насчет InfoSpere. Я не знаю человека, который сталкивался и его бы не тошнило от всего, что связано с IBM WebSphere. Я, конечно, допускаю, что конкретно с z у оракла были проблемы. Ну в целом, мой опыт использования DataStage на проектах по миграции в не в пользу этого продукта. Но, в любом случае, если есть компетенции, так и использовали бы DataStage. Это же не проблема облака. Я уверен, что в облаке серверов x86-64 DataStage будет работать не хуже чем на z.
Насчет InfoSpere. Я не знаю человека, который сталкивался и его бы не тошнило от всего, что связано с IBM WebSphere. Я, конечно, допускаю, что конкретно с z у оракла были проблемы. Ну в целом, мой опыт использования DataStage на проектах по миграции в не в пользу этого продукта. Но, в любом случае, если есть компетенции, так и использовали бы DataStage. Это же не проблема облака. Я уверен, что в облаке серверов x86-64 DataStage будет работать не хуже чем на z.
Не знаю, каков REXX на мэйнфреймах, но на PC DOS и OS/2 я его постоянно использовал. Не могу сказать, что он сложный или непонятный.
Судя по количеству представленных решений на REXX с ресурса rosettacode.org (1,082 total) то вполне практичный язык.
http://rosettacode.org/wiki/Category:REXX
P.S. Некоторый выборочный «рейтинг» по языкам и количеству представленных решений на rosettacode.org (в порядке убывания)
http://rosettacode.org/wiki/Category:REXX
P.S. Некоторый выборочный «рейтинг» по языкам и количеству представленных решений на rosettacode.org (в порядке убывания)
Go — 1,346, Julia — 1342, Raku — 1,324, Perl — 1,274, Python — 1,218, Kotlin -1,122, C — 1,117, Wren — 1,108, Rexx — 1082, Haskell — 1,012, Java — 1,098, Nim — 1,076, Racket — 1,058, C++ — 1,013, Zkl — 1,011, Ruby — 1,008, D — 966,, Tcl — 962, C sharp — 883, Factor — 874, Rust — 816, PicoLisp — 826, Ada — 812, Lua — 788, Mathematica — 759, FreeBASIC — 737, Ring — 729, Common Lisp — 720, JavaScript -713, F Sharp — 676, Delphi — 628,, PureBasic — 595, OCaml — 589, AWK — 588, Fortran -582, Swift — 529, Forth — 524, Pascal — 515, Erlang — 502, R — 499, PHP — 447, Prolog — 424, Maple — 406, VBA -399, Visual Basic .NET — 387, MATLAB — 381, XPL0 — 377, Scheme — 367, Smalltalk — 319, Oforth — 308, UNIX Shell — 302, Wolfram Language — 259, Euphoria — 234, ZX Spectrum Basic — 212,, Maxima — 211, Logo — 205,… Min — 111, Retro — 101, 8th — 89, PostScript — 89, МК-61/52 — 84, False — 56, LSE64 — 12
REXX вообще весьма простой язык. Иногда даже слишком, поэтому некоторые алгоритмические конструкции на нем получаются несколько «многословные».
Применительно к z/OS — весьма удобен для автоматизации и для него есть готовые API к многим системным функциям.
Применительно к z/OS — весьма удобен для автоматизации и для него есть готовые API к многим системным функциям.
UFO just landed and posted this here
Я использую REXX практически повседневно, ибо основная деятельность — сопровождение систем z/OS, коих на текущем месте работы больше ста штук.
Да, REXX это вполне удобный повседневный инструмент.
Но, не хватает в нем периодически языковых возможностей.
Первое что сразу вспомнилось — нет встроенного поиска/сравнения по регулярным выражениям. Да, есть внешняя библиотека для этого, но она доступна не везде и не у всех, а свои скрипты периодически нужно применять в «чужих» системах.
Комментарий мой предыдущий был все таки о том, что освоить REXX вообще не проблема, язык очень несложен и осваивается легко.
Да, REXX это вполне удобный повседневный инструмент.
Но, не хватает в нем периодически языковых возможностей.
Первое что сразу вспомнилось — нет встроенного поиска/сравнения по регулярным выражениям. Да, есть внешняя библиотека для этого, но она доступна не везде и не у всех, а свои скрипты периодически нужно применять в «чужих» системах.
Комментарий мой предыдущий был все таки о том, что освоить REXX вообще не проблема, язык очень несложен и осваивается легко.
UFO just landed and posted this here
zVlad101, если Вам сомому интересно — то давайте разберём спорные для Вас утверждения.
Я всего лишь описал свой опыт, опыт своей команды и опыт смежных с нами команд.
Я всего лишь описал свой опыт, опыт своей команды и опыт смежных с нами команд.
UFO just landed and posted this here
Пока что вы только пустые слова написали. Но мне интересно ваше мнение по поводу сильных сторон архитектуры 360(z).
Я бы выделил три составляющие: разделяемая память(да, это именно плюс а не минус), XCF, GRS. Это дает нам быстрое переключение контекстов, быструю дисковую подсистему, легкое масштабирование — основные(опять же на мой взгляд) проблемы для linux
Я бы выделил три составляющие: разделяемая память(да, это именно плюс а не минус), XCF, GRS. Это дает нам быстрое переключение контекстов, быструю дисковую подсистему, легкое масштабирование — основные(опять же на мой взгляд) проблемы для linux
UFO just landed and posted this here
до zEnterprise, гибридной архитектуры объединяющей z, x86 и RISC. Задайте себе вопрос почему именно z смогла быть основой гибрида, а не х86 и не RISC(p).
ну это очевидно, что бы продавать ненужную никому платформу в нагрузку с полноценными x86.
когда z идет вместе с x86 есть шанс замедлить миграцию с устаревшей платформы на x86. впарить одинокий z уже не реально, слишком убогий там софт, полноценных баз данных нет от слова совсем. db2 z/os проигрывает даже своему luw собрату, который совершенно неконкуретноспособен в эпоху облаков. баз данных уровня oracle, casandra или hadoop нет на z платформе.
баз данных уровня
hadoop— да вы дядя тот еще троль… gfs сравнивать с database =)
конечно, у нас DB2 тянет 60ТБ и большую часть логики на хранимках — нет там ничего уровня столь низкого как все то что вы перечислили
был бы уровень низкий, вы бы не остались последними с этим динозавром. тому что большие и успешные выкинули мф платформу есть совершенно объективные причины. и куцость блокировочного db2 одна из главных причин. db2 блокировочник и никому не интересен в эпоху облаков. а ничего, кроме еще более старых субд на мф нет.
хотя вру, наркоманы из ibm на полном серьезе предлагают в мф запускать hadoop. кстати показатель уровня…
зы. hadoop сегодня вполне замещает реляционные dwh, наши пользователи гоняют sql и не подозревают что там под низом давно уже не оракл, а hadoop. и что характерно, там много, много, много больше чем 60 гб
хотя вру, наркоманы из ibm на полном серьезе предлагают в мф запускать hadoop. кстати показатель уровня…
зы. hadoop сегодня вполне замещает реляционные dwh, наши пользователи гоняют sql и не подозревают что там под низом давно уже не оракл, а hadoop. и что характерно, там много, много, много больше чем 60 гб
А можно все таки конкретику?
В чем именно DB2 for z/OS актуальной версии (12.0) проигрывает DB2 for LUW актуальной версии (11.5)?
И желательно заодно чем «уровень» DB2 for z/OS несравним с Oracle DB?
В чем именно DB2 for z/OS актуальной версии (12.0) проигрывает DB2 for LUW актуальной версии (11.5)?
И желательно заодно чем «уровень» DB2 for z/OS несравним с Oracle DB?
что там актуально вот прямо сейчас не знаю, уже многие десятилетия фишки luw сильно выигрывает. тот же cost based optimizer делали для rs/6000, а в мф долго и мучительно портировали. всякие xml type с опозданием в мф завезли, сейчас уверен, что костыли в стиле Currently committed semantics не завезли в zOS версию.
что касается оракл, оракл лучший из версионников. одно это уже next level. в мире mysql, postgress, azure sql остаться блокировочником и плодить костыли типа Currently committed semantics — бесперспективное занятие. далее у оракла несопастовимо более навроченный язык pl/sql, начиная с пакетов и разделением на body и header. там отслеживание зависимостей в коде. у кода есть понятие invalid. всякие автономные транзакции и т.п. оракл блокирует ровно столько строк, сколько требует логика, нет костылей в виде lock escalation. в оракле более навороченный оптимизатор, есть bitmap index, есть тип хранения cluster, где джойнятся данные нескольких таблиц. можно очень долго продолжать
что касается оракл, оракл лучший из версионников. одно это уже next level. в мире mysql, postgress, azure sql остаться блокировочником и плодить костыли типа Currently committed semantics — бесперспективное занятие. далее у оракла несопастовимо более навроченный язык pl/sql, начиная с пакетов и разделением на body и header. там отслеживание зависимостей в коде. у кода есть понятие invalid. всякие автономные транзакции и т.п. оракл блокирует ровно столько строк, сколько требует логика, нет костылей в виде lock escalation. в оракле более навороченный оптимизатор, есть bitmap index, есть тип хранения cluster, где джойнятся данные нескольких таблиц. можно очень долго продолжать
ну так и db2 давно уже может в грязное чтение. а то что не спешат всякие свистоперделки вносить — так это требуется только тем кто пытается завоевать себе рынок.
отличный пример — mongo, который вроде бы как жив и даже вытеснил своего конкурента с рынка, хотя технологии под ним были на порядок хуже чем у конкурента. сейчас на рынке такое кредо — «релизимся почаще и почаще добавляем блестяшек, а то какого качества релизы пофигу — никто ничего не понимает все равно»
отличный пример — mongo, который вроде бы как жив и даже вытеснил своего конкурента с рынка, хотя технологии под ним были на порядок хуже чем у конкурента. сейчас на рынке такое кредо — «релизимся почаще и почаще добавляем блестяшек, а то какого качества релизы пофигу — никто ничего не понимает все равно»
Смотрю я на Ваш комментарий и не вижу смысла пытаться дальше обсудить тему СУБД здесь. Вы абсолютно уверены в своей правоте, ОК.
Но, утверждения сами по себе весьма категоричные и ничем особо не подтвержденные. Такому комментарию «встречно» можно выдать только примерно такой же по составу список категоричных утверждений но в другую сторону. Я так делать не хочу и не буду.
Однако, я сильно сомневаюсь что есть универсальная «золотая пуля» в мире СУБД. У каждой СУБД есть свои сильные и слабые стороны и границы применимости. Было бы одно решение которое «на голову» превосходит все остальные существующие аналоги во всех существующих сценариях — было бы просто замечательно и большинство достаточно быстро перешло на это решение. Посмотрим, что будет в будущем.
Но, утверждения сами по себе весьма категоричные и ничем особо не подтвержденные. Такому комментарию «встречно» можно выдать только примерно такой же по составу список категоричных утверждений но в другую сторону. Я так делать не хочу и не буду.
Однако, я сильно сомневаюсь что есть универсальная «золотая пуля» в мире СУБД. У каждой СУБД есть свои сильные и слабые стороны и границы применимости. Было бы одно решение которое «на голову» превосходит все остальные существующие аналоги во всех существующих сценариях — было бы просто замечательно и большинство достаточно быстро перешло на это решение. Посмотрим, что будет в будущем.
Смотрю я на Ваш комментарий и не вижу смысла пытаться дальше обсудить тему СУБД здесь. Вы абсолютно уверены в своей правоте, ОК.
мои слова ничего не значат, правоту определяет рынок. рынок решил, что db2 не нужен, версионные субд начиная с mysql и postgres, заканчивая ораклом и azure sql вытеснили блокировочники с рынка.
Было бы одно решение которое «на голову» превосходит все остальные существующие аналоги во всех существующих сценариях — было бы просто замечательно и большинство достаточно быстро перешло на это решение.
так и произошло, оракл сделал версионность, остальные быстро переняли. db2 не перенял и ушел на покой вместе с мф платформой. на плаву остались лишь те кто переняли.
Мейнфреймы «хоронили» уже тогда, когда я только с ними познакомился, это был 1999 год. И до сих пор «хоронят» с завидным упорством. А они есть, продаются, развиваются, обрастают новыми возможностями. IBM инвестирует в их развитие очень серьезные суммы денег. И это при том, что IBM без особых сожалений расстается с направлениями, которые не приносят достаточного дохода.
Что будет дальше — посмотрим.
Насчет DB2, оно уже очень давно не является чистой воды «блокировочником». Если интересуют подробности, то искать по ключевым словам «DB2 currently commited» и «DB2 Optimistic locking».
Вот статья на тему, весьма и весьма давняя: Concurrent Access Resolution on LUW and DB2 for z/OS.
Что будет дальше — посмотрим.
Насчет DB2, оно уже очень давно не является чистой воды «блокировочником». Если интересуют подробности, то искать по ключевым словам «DB2 currently commited» и «DB2 Optimistic locking».
Вот статья на тему, весьма и весьма давняя: Concurrent Access Resolution on LUW and DB2 for z/OS.
UFO just landed and posted this here
вы спорите с какими-то голосами в вашей голове, постарайтесь сосредоточится на том что я утверждал. cost based optimizator делали для rs/6000 в середине 90х, когда ветка luw называлась db2 common server. во документ от 1996 года
dsf.berkeley.edu/papers/sigmod96-magic.pdf
т.е. уже в середине 90х z/OS был в дали от прогресса, а прорывные вещи для db2 создавались на unix платформе.
dsf.berkeley.edu/papers/sigmod96-magic.pdf
т.е. уже в середине 90х z/OS был в дали от прогресса, а прорывные вещи для db2 создавались на unix платформе.
UFO just landed and posted this here
Это называется «байки из склепа». Что-то когда-то 20 лет назад слышал, то ли в лабе, то ли возле нее…
Факт остается фактом: DB2 LUW была написана на C. За основу брался код для OS/2. О каком заимствовании кода с МФ может идти речь?
Факт остается фактом: DB2 LUW была написана на C. За основу брался код для OS/2. О каком заимствовании кода с МФ может идти речь?
в 1995-1997 я работал с DB2/2. К чему Вы клоните?
я клоню к тому что вам 66 и вы разговариваете с какими-то голосами в вашей голове.
факты и ссылки на исторические документы вам не интересны, думаю на этом лучше закончить. если честно мне вообще не интересно, что вы там путаете. мф ушел, подходы устарели. все что делалось на мф, сейчас делается ровно в противоположном ключе. никто не станет сейчас делать единый пул блокировок на CF узле, как это сделано на db/zOS. никто не будет строить кластер со сложной i/o подсистемой распаянной в железе.
вобщем все что вы можете рассказать уже не интересно. простите.
Какие однако новости здесь узнаешь.
DB2 для LUW сделали на основе C версии для OS/2, которая в свою очередь писалась с чистого листа в рамках программы SAA. Тогда же оформили в виде стандарта и перенесли на другие платформы DRDA. Который, к слову, никогда до этого на MФ не было, а существовал в виде DDM на S/38/36/400.
DB2 для LUW сделали на основе C версии для OS/2, которая в свою очередь писалась с чистого листа в рамках программы SAA. Тогда же оформили в виде стандарта и перенесли на другие платформы DRDA. Который, к слову, никогда до этого на MФ не было, а существовал в виде DDM на S/38/36/400.
DB2 на МФ появилось раньше Оракла. Оракл слизал идей реляционных баз данных из журнала где ИБМ-вцы о них рассказывали. В то время Боинг уже использовал System R* — предтечу, опытный вариант реляционной базы данных на МФ. Потом появилась SQL/DS — BD for VM. Потом Оракл, и почти сразу DB2 for MVS. Речь идет о коммерческих продуктах, не опытных.
DB2 Version 1 Release 1 was announced on June 7, 1983, and it became generally available on Tuesday, April 2, 1985.
Although they created a commercial version of RDBMS in 1977, it wasn't available for sale until 1979 with the launch of Oracle version 2.
Так что не раньше, а позже, аж на 6 лет.
UFO just landed and posted this here
Кто, где и когда придумал RDBMS и SQL знает любой. Факт в том, что первый релиз конкретно DB2 стал коммерчески доступным только через несколько лет после аналогичного у Oracle (каким бы он не был). А в 85-ом оракл вообще был уже 5-ой версии.
UFO just landed and posted this here
Я всего лишь ненавязчиво предложил Вам воспользоваться Вашим же советом «проверьте факты», но, видимо, Вы советы умеете только раздавать, а заодно разводить soviet-style-демагогию (чувствуется «старая школа») на ровном месте
Похоже Вам действительно пора на заслуженный отдых. За сим откланиваюсь и убегаю «щелкать семечки и обсуждать девах».
Похоже Вам действительно пора на заслуженный отдых. За сим откланиваюсь и убегаю «щелкать семечки и обсуждать девах».
UFO just landed and posted this here
от весьма простой S/360 (простой но с правильно спроектированным фундаментом)
Таки вброшу. Я мало что знаю про z, но я многое помню про S/360. И то, что я помню, не позволяет мне, не покривив душой назвать этот фундамент правильно спроектированным.
Потому, например, что S/360 имела ровно одно адресное пространство (Model 67 я в стороне оставлю, OK?) в котором каждая задача отжирала часть его (а доступ к адресному пространству контролировался «ключами памяти»). И эта архаичная архитектура препятствовала, к примеру многозадачности, основанной на параллельных взаимодействующих процессах в стиле Unix (все же fork() и макрокоманда ATTACH — это две большие разницы). Конечно, дальнейшее развитие убрало эти ограничения, но необходимость поддерживать совместимость — она постоянно висела гирей на ногах у новых, более современных версий ПО (как пример — опиция V=R для ОС ЕС 7/СВМ (и VM/SP, откуда она взята была), использовать которую можно было, по понятным причинам, ровно для одной VM).
А ещё — потому что S/360 имела далеко не стековую архитектуру, аппартного указателя стека в ней (в отличие от PDP/11 или x86) не было. Адрес возврата из подпрограммы аппаратно писался не в стек, а в регистр (см. описания команд BAL/BALR), и для реализации, например, рекурсивных вызовов приходилось поддерживать весьма непростые структуры данных на уровне компилятора (до сих по вспоминаю PL/1 Optmizer: мне каким-то образом удалось получить копию докуменатции его внутренних структур(в СССР это было нетривиально), после чего я, как минимум, зарубил себе на носу, что ассемблерные подпрограммы, вызываемые из PL/1 (а я их любил, да) не должны трогать R12, а вообще-то читал я эту документацию с немалым интересом).
И PSW, насколько я помню, сохранялось при прерываниях отнюдь не в стек (которого не было), а в фиксированное место, окуда его надо было скопировать. Короче — архаика. И пусть она лично мне нравится — архаикой она от этого быть не перестанет.
Короче, как выяснилось, глобально развитие архитектуры после S/360 пошло несколько в непредусмотренном направлении. Это нормально, разработчиков S/360 в неправильных решениях винить нельзя — ибо невозможно прдвидеть будущее. Но гирю совместимости они для бущих архитекторов МФ, тем не менее, оставили.
UFO just landed and posted this here
Философский вопрос что считать архаикой. Вы считаете механически — раз что появилось раньше (или просто давно) значит это архаика.
Нет, вопрос что считать архаикой — он чисто эмпирический: то что раньше использовалось широко, а сейчас если где и осталось — то только кое-где, то и архаика. В этом смысле стековая архитектура — ни в коем случае не архаика, а самый что ни на есть мейнстрим. А вот многозадачность с общим адресным пространством пользовательского режима и аппартной защитой памяти отдельных залдач ключами памяти — таки архаика.
Достаточно их правильно сохранять на входе и восстанавливать перед возвратом управления. Этому учат на первых уроках по Ассемблеру.Учат, да. Но где сохранять-то, если аппаратного стека нет — этому на первых уроках не учат. Потому как это — нетривиальное решение по управлению памятью, особенно — когда от подпрограммы требуется реентерабельность (рекурсия и т.д.).
ATTACH создает новую задачу — объект для диспетчирования на ЦПУ как отдельный, самостоятельный процесс.По современным понятиям процесс — это сущность, имеющая свое адресное пространство, а не только объект диспетчеризации. В OS/360 с созданием таких объектов пользователем было сложно AFAIK. Впрочем, я тут не совсем в курсе, потому как работал почти полностью только с CMS из VM/SP, а там все было просто — система была практически чисто однозадачная.
Сохранение PSW в префиксной области ничуть не хуже чем в аппаратном стеке, а может быть и лучше. И тот и другой способ позволяет решать задачу многозадачности и как мне кажется является предметом вкуса разработчика процессора.
Сохранение состояния процессора в стеке решает задачу изящнее, и позволяет быстрее разрешить следующие прерывания. Впрочем это все сильно уже зависит от ОС. А очевидный выигрыш сохранение состояния процессора в стеке при прерывания дает, наверное, только в простейших однозадачных микропроцессорных системах — в многозадачных все равно требуется делать много другой работы.
общая шина из той же оперы и она до сих пор висит как гиря несмотря на DMAНу, не знаю, не знаю — насколько архитектуру современных, к примеру, x86/64 процессоров можно считать «архитектурой с общей шиной»: у процессора там свой контроллер памяти, например. Короче, прежде чем спорить, надо с понятиями определиться.
Адрессных пространств уже с 70-х, с MVS, может быть сколько угодно и 15 значений ключей памяти уже тоже давно, задолго до z, несуществуетНу, я как бы в курсе, потому как архитектуру S/370 изучал в объеме всей «Principals of Operation». Но изначально-то, в том самом фундаменте, про который вы говорили, этого ведь не было.
Никакого глобального развития архитектур компьютеров нет и никогда не было. Каждый производитель делал так чтобы к его архитектуре прилипали навечно.
Ну, что вам на это сказать? Ведь когда-то (и мы знаем когда) не было тех самых общепринятых сейчас вещей: ни байтовой адресации памяти, ни прерываний ввода/вывода, ни страничной переадресации памяти и прерываний по отсутствию страницы (основы виртуальной памяти), ни прерываний таймера (основы вытесняющей многозадачности), ни аппартной защиты памяти… Все это кто-то когда-то изобрел (и по понятным причнам чаще всего это было на больших компьютерах — там можно было себе больше позволить), а потом остальные внедрили. В результате сейчас и z не похожа на S/360, и совремнные Xeon с Opteron — на 8086. В общем, развитие идет. А что до стандартов — с этим, таки да, сложно.
Мне часто приходилось общаться с людми имевшими давний опыт с ЕС ЭВМ. Могу сказать одно. Современный МФ — z15 это процентов на 90% новая архитектура, только 5-10% в ней от S/360.
Дык, с этим я не спорю. У меня вызвало возражение ровно одно утверждение:
с правильно спроектированным фундаментом
Не было «правильного проектирования фундамента», так чтобы были целеноправлено приняты решения на полвека впередю А было — весьма непростое историческое развитие, с решением задач, возникающих на каждом его этапе. И как всякая большая система, мейнфреймы развивались исторически. И как мы видим резльтат, решения эти оказались более-менее успешным: менфреймы IBM с рынка не вылетели.
Ну а про детали развития и про сегодняшнее положение я лучше помолчу — потому что тут знаю маловато.
UFO just landed and posted this here
Я так понимаю что Вы уже не утверждаете что ОС МФ уже давно, очень давноИ не утверждал — т.е. изначально либо я неудачно выразил мысль, либо вы неправильно меня поняли. А так-то про существование MVS я ещё в 80-х годах был в курсе.
Кстати если под адресным пространств понимать пространство физической памяти
Нет, под адресным пространством традиционно понимается то, как видит память программа (причем я имел в виду прикладную пользовтаельскую программу).
Вы работали в CMS (VM/CP) и утверждаете что это однозадачная система. Но через то что у каждого пользователя, каждой подсистемы в VM была своя машина это все в совокупности образовывало по крайней мере многопользовательскую среду.
Именно что «по крайней мере». А, например, чтобы запустить параллельно две программы нужно было две отдельных ВМ.
Мне тогда это было нужно — одна программа в фоне сутками моделировала некий физический процесс (от загрузки до зависания, записывая раз в пару часов промежуточные результаты в постоянную память: изначально — по очереди на две ленты, лишь потом мне выделили под это диск — а при старте считывая эти данные), а вторая программа запускалась для разных интерактивных нужд — для обработки результатов, подготовки заданий, ну, и для игры в Start Trek/Empire/Adventure и всякого мелкого хакерства.
Так вот, я сильно морально страдал от того, что у этих ВМ не было общей файловой системы: каждая поддерживала для своих виртуальных дисковых устройств (минидисков) свою. А у одной, интерактивной, минидиск был минимальный (3 цилиндра от ЕС-5066/67, т.е. 627 КБ), вторая же, с более крупным минидиском, постояннно была занята этими самыми рассчетами. AFAIK уже потом IBM сделала разделяемую файловую систему (на базе IUCV AFAIK) — но это было уже потом, ту ЕС, где я все это считал, к тому времни списали, вроде как.
Более того ряд подсистем разработах в CMS имели свою внутренную многозадачность.
Ну, МНИП это была примерно такая же многозадачность, как в MS DOS с использованием TSR: в памяти оставлялся модуль, он привязывался к чему-нибудь типа прерывания и взывался через него. Ну, а потом он должен был вернуть управление (и побыстрее!), чтобы основная программа продолжила выполняться.
Что касаемо фундамента 360. Возьмите Интел 8088 и сравните с х86. Где в х86 8088?
Реальный режим, например. И если на современном компьютере ОС стартует в из режима эмуляции BIOS, то ее загрузчик получает управление именно в реальном режиме, с его «фирменной» адресацией в пределах 1МБ с 64КБ сегментами. Дальше, конечно, загрузчик переключает режим адресации, но если он остается в 32-битном режиме (он довольно широко и сейчас используется, а уж во времена появления Z 64-битного режима и близко не было), то может запустить программу в режиме «виртуального 8086» (V86). Между прочим, Windows (которая не NT, а 3.x/9x) этим широко пользовалась все 90-е, используя BIOS и DOS в качестве своего рода драйверов: полная поддержка всего железа ПК в расширенном режиме (с помощью VxD) появлялась весьма постепенно, а то, что ее ещё не получило, поддерживалось вызовами кода реального режима (контролируемыми за счет того, что он выполнялся в V86 и имел доступ только туда, куда ему было позволено).
где программы написанные под 8088? Где программы написанные под Windows 3.4, Windows 95?
Например, у меня на диске, в игрушки, написанные под DOS, я и сейчас поигрываю: у меня для этого машина под XP (2008 года выпуска), и некоторая часть из игрушек (особенно — не работающих со звуковой картой, ибо для нее эмулятор аппартуры нужен) запускается в ней даже напрямую.
Ну, а коммерческие приложения, естественно, не дожили, они на x86 долго не живут: программы на ПК всегда были сильно меньше, цикл разработки — короче, потому их куда проще было обновлять. А обновлять — хотелось, потому как быстро развивающееся железо постоянно соблазняло новыми плюшками.
Ну, а уж игры, написанные для Win3.x/9x — в них я и нынче играю, причем — уже из под самой XP. Да и приложения — они тоже сохранились: работая несколько лет назад в некоем банке, я с удивлением обнаружил, что там в стандартный комплект установки входит BDE (это такое промежуточное ПО, обычно — для программ на Delphi, спроектировано оно было как раз под эти системы и несет на себе их «родимые пятна» (например, общую память внутри DLL, которая отображается во все процессы обязательно по одному и тому же адресу) — но этим тогда кто-то ещё пользовался, благо типовой ПК у них был под 32-битной системой (из-за экономии, наверное, памяти в нем что-то совсем мало было).
5-10% от 360 это не «виртуальная машина DOS» в х86. Это то что пронизывает z от и до, везде. Это и было предвидение на… уже более чем 50 лет, черз 3 года будет 60 лет.
Это как раз плохо, если «пронизывает», что нельзя локализовать и минимизировать влияние. В x86 оно тоже очень долго пронизывало, отказались от совместимости с 16-битными защищенными режимами только в x64 (который, кстати, моложе Z).
Но если изначально модель 360 была однозадачной, пакетной, однопроцессорной, пара каналов ввода-вывода, с сотнями КВ памяти (но уже 24 разрядной адресацией — 16МВ)
«16MB должно быть достаточно для каждого» ;-), древний вариант крылатых слов BG?
Что касаемо где сохранять регистры. Обратитесь хотя бы к автору статьи где мы общаемся и он Вам объяснит (я надеюсь) где.
Наличие специальной опции REENTRANT у процедуры на PL/1 намекает, что «здесь не все так однозначно»©, и что о том, чтобы можно было при вызове процедуры сохранить регистры общего назначения(в частности адрес возврата, он изначально в S/360 в регистр общего назначения писался) несколько раз в разные места, приходилось заботиться отдельно: в данном случае — компилятору, ну а если на ассемблере писать — программисту. Ну, а в стековой архитектуре адрес возврата, по крайней мере, всегда есть где сохранить — так же, как и остальные регистры, и чтобы отвести место новой копии локальных переменных.
Да и про stack machine. Это появилось не с появлением ПК.Ага, на мини-ЭВМ это уже было вовсю.
они выбрали то что выбрали и этот их выбор подтвержден почти 60 летним триумфомНу, триумфом я бы историю МФ IBM назвать постеснялся: монопольное-то положение на рынке вычислительных средств они упустили.
UFO just landed and posted this here
Минидиски CMS можно было использовать многими ВМ одновременно. А как по Вашем использовались резидентные диски CMS? Нельзя было один и тот же диск иметь по записи и писать — это разрушило бы файловую систему.
Так я, хоть и не написал недвусмысленно, но как раз имел в виду одновременное полноценное использование файловой системы, для чтения и записи из разных программ (каковыми по факту являлись ВМ). То, что для реальных компьютеров называется «кластерная файловая система». Базовая аппаратная поддержка для этого была ещё в S/360 — команды «Зарезервировать/освободить устройство»: в промежутке между этими командами доуступ со стороны другой ЭВМ к устройству был невозможен. И поддержка виртуализации этой команды для минидисков и VM на уровне CP — она тоже была (хотя мне она показалась довольно неэффективной).
А про чтение я был изначально как-то так в курсе: хотя бы потому, что одним и тем же 190-м минидиском (он же S, т.е. системный, там система лежала и все такое прочее) совместно пользовались все виртуальные машины под CMS.
Я могу рассказать куда больше — потому как я моральные страдания испытывать таки устал и совместное использование минидиска по чтению-записи из разных ВМ таки реализовал, полноценно, исключая возможные гонки — потому что был молодой, аспирантура в СССР давала время разной ерундой заниматься, исходники CMS были доступны, логика этой крайне простой ОС и ее работы с файловой системой была весьма не сложна, замечательный отладчик CP позволял удобно отлаживать и тестировать работу ОС виртуальной машины (например, для данного случая — воспроизводить ситуации гонок при одновременном обращении к файловой системе с разных ВМ)- и прочая, и прочая. А потом год или полтора этим пользовался, чисто для себя (откуда и про невысокую эффективность виртуализации команд резервирования знаю, в частности, впрочем, лично мне ее хватало). Но это всё, конечно, сейчас имеет разве что исторический интерес.
Но вот некоторыее недостатки концепции «персональных ВМ» — показывает хорошо.
PS Если чо, то тамошний ВЦ к VM/SP не от хорошей жизни пришел: там я, студентом еще, застал чудо в виде TSO на ОС ЕС 6 СВС — так вот, ничего более падучего я с тех пор больше в жизни не видел: средний аптайм посреди дня мог составлять 15 минут.
REENTRANT не имеет никакого отношения к области сохранения регистров.И к ней — тоже имеет. А ещё — к тому, где хранить локальные переменные, видимые только в этой процедуре (они в стековой архитектуре тоже хранятся в стеке, от которого для этого отбирается кусок нужного размера).
Поверьте, Вы не разобрались с этим и проблем с использованием регистров в программе на Ассемблер не было и нет. Но не будем углубляться.
Что не разобрался — не поверю. Потому как внутренние циклы своей программы моделирования переписал почти сразу на ассемблер (ну, раз было время развлекаться с патчами для ОС, то уж на это-то время, естественно, нашлось).
И в процессе отладки (я уже говорил, что отлачик в VM/SP был замечательный?) хорошо видел, что и как там происходит.
Потому вопросы — они сразу возникают. Вот, вызвали вы, допустим, подпрограмму, получили адрес возврата, как положено, в 14 регистре (потому как вызов традиционно делался командами BAL 14, подпрограмма или BALR 14,15) — и куда теперь 14 регистр девать, чтобы слдующую подпрограмму из этой вызвать? Простейший вариант — в статическую область памяти записать, но это — прощай та самая реентерабельность.
Хотя, я погдяел в гугль кажется понял причины того, почему вы меня не поняли: в MVS и дальше семантика этого OPTION, похоже, то ли поменялась, то ли расширилась. Разбираться с этим не хочу, Фролова-Олюнина искать, чтобы точно вспомнить, как это было конкретно на ЕС ЭВМ, искать откровенно лень, так что спор начсет REENTRANT вести не буду. Но вот вопрос, куда сохранять регистр с адресом возврата — он остается.
Но действительно, не будем, наверное, углубляться. Все это — уже далекая-далекая история.
PS А что до войны «IBM против всех» — мне это как-то до лампочки. Да и не в курсе я особо, как она там со всякими DEC/Sun и прочими воевала — я как-то от Wintel никода далеко в сторону не забирался.
И вообще, вести дальше эту дискуссию мне как-то скучно становится: уж больно она в холивар скатываться начинает, с аргументами в стиле rulezzz/suxxx. Я свое мнение высказал, вам оно, похоже, особо не интересно, другим — тем более, так что, думаю, на этом дискуссию пора прекращать.
Я, надеюсь, не обижу вас тем, что на ваш следующий ответ отвечать не буду?
UFO just landed and posted this here
Интересно что же Вы там такого напрограммировали против «гонок».
Ну, раз интересуетесь — отвечу.
Я, конечно, все детали сейчас уже не помню, но общая идея была вполне стандартная: при любом изменении дискового блока, используемого самой файловой системой (головной блок, блоки оглавления, таблица распределения дискового пространства) доступ других ВМ к минидиску блокируется (для чего как раз выдается команда резервирования), подлежащий изменению блок (или блоки) считывается заново, производятся изменения в памяти и измененные блоки записываются на место, так что файловая система оказывается в согласованном (ну, почти — см. ниже) состоянии, после чего блокировка минидиска снимается. А команды «зарезервировать/освободить устройство» в данном случае играли роль примитива синхронизации (типа мьютекса) для обеспечения эксклюзивного доступа к ресурсу(т.е. диску) на период изменения. Это — вполне типовой прием параллельного программирования — вплоть до того, что его иногда прямо в язык программирования вводят (оператор lock в C# к примеру).
Ещё помню, что одном месте понадобился трюк при синхронизации, потому что полностью согласованное состояние в этом месте получить за одну блокировку по каким-то причинам не удавалось (подробностей уже не помню). Конкретно это было при удалении записи файла в блоке оглавления файловой системы для каких-то случаев. Так что там пришлось временно оставлять дубликат последней записи в блоке оглавления на старом месте после первой блокировки (во время наложения второй блокировки дубликат удалялся). И в случае отказа ВМ (а это же была ЕС ЭВМ, там перезагруки всей ОС были нередки), случившейся в этом промежутке между блокировками, дубликат оставался на диске. Хотя к разрушению ФС это само по себе не приводило, но было оно, как минимум, некрасиво, да и последующая попытка удаления файла-дубликата могла к чему-то плохому привести. И это корректировалось путем обнаружения и удаления дубликата записи при считывании такого блока — так что в копию ФС в памяти ВМ, с которой шла работа, этот дубликат уже не попадал.
А вообще, при взгляде из нашего времени, решение было весьма ограниченным по сравнению с возможностями, кторые предоставляет общая файловая система.
Например, ничего, подбного блокировкам на уровне файлов (что сейчас есть в любой ФСв многозадачной ОС), в данной ФС не было, поэтому одновременно обновлять с разных ВМ один файл было нельзя: гарантии целостности данных файла, в отличие от ФС, не было. Но, поскольку пользователем был я один, это было терпимо.
По поводу «гонок» (race conditions): я тогда весьма аккуратно расмотрел все варианты конфликтущих изменений и вручную прошел их в отладчике параллельно на обеих ВМ по шагам, с остановками в потенциально опасных местах. Кончено, сейчас у меня нет уверенности, что я протестировал совсем все возможные конфликты, но тогда за год-полтора реальной личной работы с минидиском я ни на что так и не наткнулся.
А вообще-то, все эти мои, типа, заслуги (не имевшие, к тому же, никакого отношения к тому, чем я должен был официально заниматься) — они сейчас уже никакого предмета для гордости представлять не могут. Я тут рассказываю про них чисто для иллюстрации, как о картинке из «тех времен».
За сим откланиваюсь.
UFO just landed and posted this here
На вскидку (давно не держал шашек в руках) область сохранения предоставляется вызывающей программой.
Ну, тогда все проблемы просто переносятся в вызывающую программу. В частности, проблему в случае рекурсии придется-таки решать именно в вызываемой подпрограмме — потому что она же будет и вызывающей.
PS Надеюсь, что вы понимаете, что здесь речь фактически идет об управлении памятью, а не просто о «форме макрокоманд» (я вообще предпочитаю о макрокомандах не говорить, а говрить о командах, на которые макрокоманда разворачивается. Причем, поскольку заранее неизвестно, сколько именно памяти потребуется, управление памятью неизюежно должно быть динамическим. И стековая архитектура для такого вот простейшего случая динамического управления — использования памяти по стратегии LIFO — обеспечивает это динамическое управление аппаратно, в чем есть ее несомненное достоинство.
PS Посмотрел следующий ваш пост. Решение, в принципе, приемлемое, но менее универсальное, чем в стековая архитектура. А ещё — сложнее подбирать параметры распределения памяти: стек-то — он в обратную сторону растет, с другими потребителями памяти он не конкурирует, поэтому ему вмсете со всем остальным можно отвести один общий кусок памяти и не париться (до некоторого момента, конечено), сколько именно надо выделить.
UFO just landed and posted this here
В RG13 находится адрес Вашей области сохранения для вызываемых из Вашей программы программ
И тут сразу возникают два вопроса:
1. А откуда он там возьмется?
2. Если его туда положила вызывающая программа, то какого размера эта область, ее точно хватит? Подозреваю, что об этом должен позаботиться программист, указав какую-то дерективу компилятору (или редактору связей).
В общем, это похоже на какое-то соглашение для программ, принятое в рамках данной программной системы. Жить с этим можно, согласен. Но — только в рамках данной системы. Например — пользовательской программы на каком-то языке. А вот в другой системе программирования в ядре могли быть уже совсем другие соглашения. Короче — решение не универсальное. А вот аппартный стек — он универсален, т.к. поддерживается самой аппаратурой.
PS Лично у меня подобных проблем на практике не было просто потому, что мне рекурсивные вызовы не требовались.
UFO just landed and posted this here
Это «соглашение» называется «принципы работы» (руководство системного програмирования).
В данном случае это именно соглашение, т.е. оно не навязывается архитектурой компбютера или ОС, а определяется договоренностью программистов. Соглашения в разных системах программирования могут быть разными.
Я-то в ДОС ЕС с ассемблером работать начинал, причем — отнюдь не в прикладных программах, так что там все было «немного» иначе. Как вам, к примеру, такое соглашение о вызове: «в R4 помещается адрес кода, в который после вызова команды SVC 28 выполняется с ключом защиты 0, для завершение выполнения этого кода требуется восуществить возврат по адресу, полученному в R9 (или наоборот, сейчас уже точно не вспомню)» — а мы этим «соглашением о вызовах» во студентах немало попользовались для написания разных интересных программок — и ЕМНИП за это никто даже в деканат не попал.
Рекурсия и реентерабельность это не одно и тоже.
Я в курсе. Однако рекурсия требует реентерабельности, поэтому отсутствие реентерабельности (а возможность отсутствия следует как раз и того, что реентерабельность опциональна) в коде исключает рекурсию. Теперь вам понятна моя логика?
Для того чтобы делать такие сравнения, надо быть экспертом не только в z, а как минимум не хуже в том, с чем сравниваете.
Все вышесказанное — это некий эмоциональный поток, где главный аргумент в качестве обоснования — «я считаю».
Все вышесказанное — это некий эмоциональный поток, где главный аргумент в качестве обоснования — «я считаю».
UFO just landed and posted this here
Вы делаете громкие заявления, ничем их конкретно не подкрепляя.
Конкретно, речь про вот это заявление:
Я в корне не соглашусь. И подтверждением послужит хотя бы количество серверов в датацентрах, работающих под Linux.
Насчет универсальности — и в чем она заключается? Ничего универсального вообще — одна специфика, так что вы даже предлагаете новичкам с ходу забыть все, чему их учили в ВУЗе.
А насчет, мол, можно запускать. Так z/os можно запускать в геркулесе на под линкусом. Тоже вариант, многие используют. Другое дело, как это будет работать. То же применимо к портированию на Z кода C, который изначально писался по Unix — это потеря производительности. По хорошему, быстро на МФ работают только «родные» приложения на Cobol, ассемблере и т.д., которые изначально заточены под эту архитектуру. Там где подразумевается posix все сразу становится очень кисло.
Конкретно, речь про вот это заявление:
МФ самая универсальная платформа для выполнения любых серверных програм, написанных на любых языках и под любые ОС кроме Windows
Я в корне не соглашусь. И подтверждением послужит хотя бы количество серверов в датацентрах, работающих под Linux.
Насчет универсальности — и в чем она заключается? Ничего универсального вообще — одна специфика, так что вы даже предлагаете новичкам с ходу забыть все, чему их учили в ВУЗе.
А насчет, мол, можно запускать. Так z/os можно запускать в геркулесе на под линкусом. Тоже вариант, многие используют. Другое дело, как это будет работать. То же применимо к портированию на Z кода C, который изначально писался по Unix — это потеря производительности. По хорошему, быстро на МФ работают только «родные» приложения на Cobol, ассемблере и т.д., которые изначально заточены под эту архитектуру. Там где подразумевается posix все сразу становится очень кисло.
«выбросите из головы все что узнали в университете и начнете с чистого листа»
Вот что вы молодежи советуете? Зачем им выбрасывать эти знания? Они совершенно применимы для 99,9% всех сайтов и новых разработок. Ради одной устаревшей платформы, которую даже в голову не придет использовать для каких-то новых продуктов и которую держат исключительно с целью, чтобы запускать написанный во времена динозавров код на языках, которые давно морально устарели?
Вот что вы молодежи советуете? Зачем им выбрасывать эти знания? Они совершенно применимы для 99,9% всех сайтов и новых разработок. Ради одной устаревшей платформы, которую даже в голову не придет использовать для каких-то новых продуктов и которую держат исключительно с целью, чтобы запускать написанный во времена динозавров код на языках, которые давно морально устарели?
почему именно z смогла— потому что появилась позже, но развивалась из архитектур появившихся ранее x86
а что в х86 этого нет?— в каком-то виде есть, но не с теми возможностями и безопасностью как на процессорах z архитектуры
То что Sysplex это не тоже самое что кластерну да, тут есть проблемы=) в основном «разработчики» не видят потери в архитектуре, потому что не представляют а как оно еще может быть. но объяснить можно, просто это долго(человеку надо рассказать целый курс по архитектурам) и от того не интересно
Рассматривать архитектуру по кускам дело неблагодарное. Вам тут же приведут резонные контраргументы с других платформ— не приведут. нет больше нигде возможности, к примеру, копировать страницы памяти ядра по сети
ну да, тут есть проблемы=) в основном «разработчики» не видят потери в архитектуре, потому что не представляют а как оно еще может быть. но объяснить можно, просто это долго(человеку надо рассказать целый курс по архитектурам) и от того не интересно
не интересно потому что нигде не работает, кроме глупых маркетинговых материалов. db2 z/os хранит блокировки в CF, все узлы долбят в этот единственный CF по sysplex. это не может работать и нигде не работает. зачем тратить время на рассказы, если ни в одном облаке такой смешной архитектуры с единой точкой долбления не встретишь?
в эпоху облаков полно субд способных масштабироваться на тысячи узлов, но ничего, даже отдалено похожего на архитектуры мф в облаках не встречается. потому и никому не интеремно, раз ушло на покой и было заменено даже на уровне идеи.
полно субд способных масштабироваться на тысячи узловприведите пример реляционной СУБД
бигдата. impala позволяет гонять sql запросы на тысячах hadoop узлах, всякие spark sql поверх delta lake табличек от databriks, там тоже зачастую речь идет о тысячах узлах и вполне sql интерфейсе. mssql 2019 big data — построен вокруг хадупа, т.е. на тысячи узлов рассчитан. все это не совсем реляционный, но sql.
UFO just landed and posted this here
Что значит «появилась позже», но «развивалась из… ранее х86»
360 — 64, 86 — 70е, z(потомок 360) — 90е — вот и получилось что z может приспособится к 86, а не наоборот
создано для ПЕРСОНАЛьНОГОэто верно, еще бы найти возможность кратко это объяснять людям=) вот пока что лучше упоминания того что привел ранее и не нашел(это как раз к вопросу о том — зачем «Рассматривать архитектуру по кускам»)
360 — 64, 86 — 70е, z(потомок 360) — 90е — вот и получилось что z может приспособится к 86, а не наоборот
глупости детектед. x86 спсобен заместить абсолютно любой МФ. точнее уже заместил. тогда как МФ в принципе не может масштабироваться до необходимого уровня. даже не столь уж крупный яндекс не построить на МФ, вообще никак. всякие высоконагруженные биржи, типа нью-йорксой. никакой МФ такие нагрузки не вытянет.
UFO just landed and posted this here
Это весьма смелое заявление. Поставим рядом z и i и сравним, кто кого сделает по удобству, надежности, архитектуре?
i — это по большому счету улучшенная и кардинально переработанная версия z. Ну, т.е. люди, которые делали s/38, танцевали от 370 — это очевидно. И потому заложили и виртуальную машину и объктность и рациональную БД в ось.
Это как сравнивать 3270 с 5250. Познакомившись со вторым, не захочется возвращаться на первый.
i — это по большому счету улучшенная и кардинально переработанная версия z. Ну, т.е. люди, которые делали s/38, танцевали от 370 — это очевидно. И потому заложили и виртуальную машину и объктность и рациональную БД в ось.
Это как сравнивать 3270 с 5250. Познакомившись со вторым, не захочется возвращаться на первый.
UFO just landed and posted this here
Во-первых, странная постановка вопроса. Типа «поезжайте в Киев и спросите!».
При чем тут это?
Во-вторых, интересно было бы послушать, в каком месте IBM говорил, что z для них важнее power. Сейчас IBM вообще не фокусируются на железе, а позиционируют себя как middleware и cloud provider.
Я надеюсь, вы не хотите снова посмешить меня заявлениями о том что МФ=Cloud?
IBM купили RH. И теперь продвигают их продукты. И, хотя, возможно, наверное, запускать OpenShift на МФ, мне трудно представить себе, кто будет покупать Z специально и исключительно для того, чтобы запускать там RHEL и OS. Для этих целей есть Power сервера, они изначально затачивались под Uniх.
Суперкомпьютеры — это Power. AI — Power. Так что вот это флагман.
А то что i превосходит z по архитектуре — это легко и предметно доказывается:
Ну, и, да, современный РПГ — это просто технологии высшей цивилизации по сравнению с Cobol и PL/I от Z. Но это чисто мое личное субъективное мнение.
При чем тут это?
Во-вторых, интересно было бы послушать, в каком месте IBM говорил, что z для них важнее power. Сейчас IBM вообще не фокусируются на железе, а позиционируют себя как middleware и cloud provider.
Я надеюсь, вы не хотите снова посмешить меня заявлениями о том что МФ=Cloud?
IBM купили RH. И теперь продвигают их продукты. И, хотя, возможно, наверное, запускать OpenShift на МФ, мне трудно представить себе, кто будет покупать Z специально и исключительно для того, чтобы запускать там RHEL и OS. Для этих целей есть Power сервера, они изначально затачивались под Uniх.
Суперкомпьютеры — это Power. AI — Power. Так что вот это флагман.
А то что i превосходит z по архитектуре — это легко и предметно доказывается:
- Объектная OS
- Встроенная в ядро ос реляционная БД
- Встроенная виртуальная машина
- Современная универсальная платформа — Power
Ну, и, да, современный РПГ — это просто технологии высшей цивилизации по сравнению с Cobol и PL/I от Z. Но это чисто мое личное субъективное мнение.
А как у вас тестирование поставлено? Особенно регрессия. Есть какие-то инструменты сейчас для автоматизации? Когда я этим занималась ничего небыло, ручками сотни jcl запускали, очень тупо и долго.
У нас есть самописные фреймворки на питоне для того, что можно достать в ISPF. А так у нас 3 UI (3270, Java и WebUI).
С WebUI — всё, думаю понятно. Для 3270 и Java UI — написаны собственные фреймворки для доступа к данным, в итоге автоматизация проходит по всем view и там уже запускаются свои тесты. В целом всё работет на Python. Валидация данных в некоторых случаях: Python сабмитит JCL, ждёт завершения, вытягивает логи, парсит и проверяет с тем что в UI.
С WebUI — всё, думаю понятно. Для 3270 и Java UI — написаны собственные фреймворки для доступа к данным, в итоге автоматизация проходит по всем view и там уже запускаются свои тесты. В целом всё работет на Python. Валидация данных в некоторых случаях: Python сабмитит JCL, ждёт завершения, вытягивает логи, парсит и проверяет с тем что в UI.
UFO just landed and posted this here
Тут вопрос к Вашим специалистам, почему они не помогли автоматизировать процесс.
Задания (JCL) можно генерировать и запускать кучей разных способов очень давно (как минимум 20 лет). Привожу три варианта, но их на самом деле больше:
В более новых версиях z/OS (ветка 2.x) в комплекте идет специальный сервер с web-доступом (z/OSMF) который позволяет много чего делать в z/OS через HTTP/REST API. В том числе и выполнить запуск задания с последующим получением результатов выполнения.
Задания (JCL) можно генерировать и запускать кучей разных способов очень давно (как минимум 20 лет). Привожу три варианта, но их на самом деле больше:
- REXX или любой другой язык, умеющий что-то писать на вывод. Запись в выходной «файл» с именем INTRDR (JES2 Internal Reader) текста задания фактически отправит задание на выполнение.
- Через USS (z/OS Unix), стандартный Shell-скрипт с вызовом команд на генерацию и запуск задания.
- Через FTP-сервер, работающий в z/OS. Текст задания генерируется и отправляется как файл, результат исполнения скачивается назад как один или несколько файлов
В более новых версиях z/OS (ветка 2.x) в комплекте идет специальный сервер с web-доступом (z/OSMF) который позволяет много чего делать в z/OS через HTTP/REST API. В том числе и выполнить запуск задания с последующим получением результатов выполнения.
Key 0, SUPER MODE
Еще раз убеждаюсь что IBM просто монстры, в хорошем смысле этого слова, обратной совместимости. Это тоже самое что SVC MODESET KEY=0 который было еще на S/360?
Sign up to leave a comment.
Особенности разработки на мейнфреймах