SergSuper,

Ну это вообще-то было ответом IgorK, почему я не вижу перспектив широкого внедрения Z в текущих российских условиях.
Реальная задача? автоматизиваронные банковские системы крупнейшего россиянсекого банка.
Или не так - фигли мелочится - что там говорил наш Президент?
Нам необходима отечественная национальная платёжная система!
Зачем - не важно, ему видней.
Мы технари.
Как?
Как мы её построим?
Вот здесь - IMS есть место.
Чем оно лучше и чем хуже - так я об этом и писал.
Читать не пробовали?

IgorK
Ответить - почему это не так! Хотя бы вкратце - я, например, не в курсе в чем разница и ЧТО там не так.
--
Упоминалось, что обычно рядом DB2 стоит, вопрос - напуркуа? Что делают на нем, как перегружают данные, структуру данных меняют (сложность перегруза возрастает тогда) ?
1. Ответить почему не так - провести курс IMS Fundamentals прямо здесь? Описать архитектуру, назначение состав и взаимодействие частей и механизмов? Ну можно попробовать. Местами даже уже.
Местами.
Состав.
Структура. В том числе и данных.
Но ведь ВСЁ это в открытом доступе.
2. Почему рядом с IMS DB2? Хороший вопрос.
DB2 как RDBMS универсальна. Может выполнять все задачи. Но часть задач IMS выполняет лучше, по ряду своих характеристик она к ним лучше походит. Но она не универсальна - она только для OLTP систем. Только!
Что такое OLTP система?
Ну давайте попробуем сформулировать признаки.
- Все запросы известны заранее, отсутсвие ad-hoc запросов
- запросы затрагивают малые порции данных, редко всю запись, чаще часть.
- большая доля запросов на изменение мелких порций данных
- большое количество этих мелких запросов в единицу времени.
Что там ещё? Наверняка что-то забыл
Критические системы
- высокие требования к надёжности, выраженной в том числе и изоляцией запросов между собой, отказоустойчивостью, прочее
- высокие требования к безопасности - в широком смысле, а не проверки пароля. можно я не буду безопасность описывать, из чего состоит и что это есть?
- высокие требования на время реакции, то есть на время выполнения запросов
- большая цена простоя, отсутсвие окон для планируемого простоя, в том числе на смену версий и прочее.
Почему IMS в OLTP лучше? Ну я уже про это много писал - накладные расходы на выполнение одних и тех же задач в IMS банально меньше, чем в RDBMS (в условиях OLTP только!!!). Отсутсвие необходимости в JOIN и использование ссылок, отсутсвие в дублировании данных, более компактные структуры данных.
Типичное позиционирование - финансово-учётные системы, платёжные системы, с очень высоким SLA (пардон, но когда пол дня сбербанк г.Москва не обслуживает свои банкоматы, и это повторяется из раза в раз... и за это никого не уволили... ну я не знаю... но это не уровень)
Но кроме задач быстро и надёжно проводить платежи есть и другие задачи - анализировать, а чего там наплатили?
Аналитика, все BI, OLAP. и всё прочее. Я читал, что Cognos и с IMS теперь работаеть умеет, но это уж если по принципу - ну теперь вот и так даже можно! Всё таки нецелевое использование. Кроме того множество второстепенных задач - CRM, ERP, MDM, что там ещё... Да их валом.
Одни задачи на IMS решать будет дорого - аналитические, тогда придётся к каждому аналитику сажать программиста, и будет убиваться куча времени, на то, что любой (почти) оптимизатор RDBMS сделает на раз и вернёт данные.
Другие - второстепенные - тоже решать на IMS будщет дорого, в мире Z принцип платежей такой.
Поэтому ставится связка IMS+DB2, аттачменты специально для них разрабатываются, в обе стороны, что с хранимок DB2 в IMS, что из транзакций IMS к DB2 ( транзакция - программа, процедура, а перевод базы из одного консистентного состояния в другое - Unit of Work, в IMS и в CICS - транзакции, финансовые - транзакции, а в базах данных - UoW, welcome to IBM терминологию)
Кроме того все эти DataStage (с которыми свои проблемы, их ещё применять надо уметь, то есть три человека - спецы по IMS, DataStage, и по DB2 должны встретится, чтобы решение получилось хорошим, а не как всегда)
фух.
если что подробнее - давайте углублятся, а то широко замахнулись.

Ggg_oldппм, интересно читать. Но вы пока больше рассказываете как IMS устроено, а я так понимаю, что основная фишка не сколько в ней, сколько в связке IMS+железо. И эта связка дает результат по производительности, которых у других нет. Это наверное как с грузовыми машинами, их много классных и удобных, но если надо возить руду из карьера - то Белаз и пофиг насколько там удобный руль и рычаги управления.
И если уникальные фичи платформы раскрываются на этом стыке, то было бы интересно, что-бы вы немного просвятили на эту тему. Я например про мэйнфреймы ничего путнего сказать не могу с технической точки зрения, кроме того, что это большое железо. Но какие там заложены инженерные фишки я не знаю. Слышл когда-то давно, что одно и тоже вычисление может выполнятся двумя блоками параллельно, а потом результат сравнивается. И если вдруг он отличается(например из-за ошибки в процессоре), то происходит повторное вычисление. И это типа один из многих механизмов отказоустойчивости.
Если ест хорошие ссылки про то, что есть Z без маркетинговоой шелухи, то поделитесь пожалуйста.
охохо, больная тяжёлая тема.
Прекрасная платформа - и ноль знаний, одни слухи, хорошо, хоть вы это понимаете.
Я коротко по пунктам, потом подробнее если надо пробежимся.
Если не понятно что - не надо сразу обзывать, я тезисами, раскрывать широко не буду - пока.
IMS и сама по себе софтово интересна (имхо) но и отрицать тесной зависимости от железа - глупо.
Пример, все (надеюсь) знают что есть VSAM. Многие даже знают, что это основной метод доступа.
ЧТо даже DB2 свои данные хранит в VSAM, что само по себе даёт ништяки, ибо аппаратура заточена на работу с ними, да и сам VSAM это типа foxpro, что ли.
Но для IMS был разработан свой метод доступа - OSAM, который на аппаратном уровне - в канале, канальной программой (канал - не только путь доступа, не только замена шине, у unix шина одна, а каналов, чтоб не соврать, то ли 2048, то ли 1024, нехилое так количество шин, но канал - это больше, это по сути дела компьютер выполняющий специализированные программы по работе и обработке данных, не только их извлечению) - так вот OSAM способен определять способ доступа клиентской программы к данным IMS, и если они со случайных становятся последовательными - начинает упреждающее чтение. Само по себе - фигня вопрос, но реализованно аппаратно, что есть преимущество.
Мэйнфрейм - это сам по себе кластер из разных вычислительных комплексов в одном устройстве. Поэтому сравнение с любыми другими платформами - не корректно.
- постоянная работа с 100% загрузки GPU, которые ЦПУ
- каналы, катастрофически большой ввод вывод, множественность путей к одному устройству I/O
- 16 адресных регистров, 16 адресных пространств могут работать на GPU без переключения контекста
- офигительная скорость переключения контекста, не с чем сравнивать
(это позволяет на одном ящике совмещать кучу разнородных задач более эффективно, чем на других
от z/OS
- address space - аналогов нет
- изначальная многозадачность и многопользовательскость, это лезет изо всех щелей, сквозной контект безопасности всем задачам, а не так - тут безопасность оракла, тут WebSphere, тут DB2
- WLM workload manager, это нечто, управляется бизнес целями, а не технологическими понятиями
- простота админстрированя громадных комплексов на фоне сложности по сравнению с другими, если комплекс мелкий
Фух,
Да, в GPU реализован механизм проверки результатов вычислений, дублировано всё, включая конвейеры.

Я всегда говорю - у нас мудрые партия и правительство.
Мы не вступаем в ВТО бездумно.
Польша вступила.
Праткически потеряла свою национальную банковскую систему - всё скупили на корню
С другой стороны по развитости ИТ Польша обходит Россию. Иностранцы принесли свои системы, свои бизнес-процессы, свои критерии.
С одной стороны плохо для России потерять свою национальную банковскую систему.
С другой стороны и в таком состоянии её оставлять нельзя...
как чемодан без ручки.

другая точка зрения.
Система работает на двух ЦПУ писюка. Ну юникса, не вопрос.
Что такое в таких условиях увеличение производительности в два раза?
Да, по-большому счёту, ничего заметного по деньгам. Даже с учётом лицензирования по ядрам (что само по себе заговор вендоров, жестоко наказывающих лопухов за десятилетия веры в безостановочный опережающий рост вычислительной мощности компов, и расхлябаный подход к проектированию и программированию - а, фигли, всё одно быстро будет - ну на эту тему ещё много можно, но если коротко - лицензирование по ядрам резко аукнулось, а специалистов потеряли, выросли поколения кодеров, а не программистов, живущих по принципу "а фигли думать? DB2 и WebSPhere и вперёд!")
А если система работает на 64 ЦПУ Z?
Что даст увеличение производительности в два раза?
Это большие деньги.
А если вспомнить, что ряд софта на z/OS лицензируются на основе по-месячных платежей, то с течением времени это будут просто очень большие деньги.
Если решение даже части задач выполнить с ускорением в два раза - на этой платформе это уже имеет смысл, как бы дико нам это не казалось, даже разношёрстность софта и специалистов покроется экономией.
Так, мысли вслух.
С другой стороны вспомним ситуацию с каналами связи 10 лет назад? Стоимость/доступность/качеством?
Произошли изменения?
А вспомним ситуацию с доступностью/качеством/стоимостью специалистов 10 лет назад?
Произошли изменения?
Были характерные жалобы - нет, наша платформа только windows, только выучишь специалиста на AIX, и он через месяц в Москве.
Спросите, какое это отношение имеет к IMS?
А подумать?
8 немцев тянут 700 банков....

кстати, кто-то тут упрекнул меня в анонимности - пардоньте, email я дал, кто хотел бы - написал.
мимо кассы.

по поводу - что IMS, что Cahe - одно дерьмо.
Я знаю, что Cashe храниет данные в глобалях, и что "хранить данные в объёме удобнее, чем на плоскости".
Было тут такое, на форуме, годы назад.
Но можно разобрать, в чём хранит данные IMS.
Я говорил - в сегментах.
А сегменты в VSAM или OSAM.
Ну для начала сам сегмент.
вот рутовый сегмент.
Занимает 85 байт, это данные, доступные приложению.
Плюс префикс с указателями TwinForward & Backward.
То есть два указателя по по 4 байта.
Плюс два служебных байта - байт типа сегмента и DC - deletion byte.
Никаких "обёмов", всё плоско. расписано до байта.
Это то, что будет элементом операции ввода-вывода.
минимальная обрабатываемая порция информации.
Теперь нечто интересное, если выше более-менее понятно, то вот это может вызвать шквал негодования у неокрепших мозгов.
По условиям работы с сегментом, мы чётко знаем, что в операциях поиска будет учавствовать только один сегмент - CODE. Ну задача такая.
В таких условиях вот это определение сегмента предпочтительнее.
Данные сегмента просто загрузятся в I/O Area приложения, которое в приложении является, допустим, COBOL структурой.
Или C структурой.
И всё - приложение имеет доступ ко всем полям, а базу фигнёй не перегружаем, у неё и так забот по горло - тысячи таких дураков обслуживать.

Прям как сейчас вижу - ну один к одному Cahe.
Ага, вот ещё до OSAM/VSAM дойдём...
Так там ну просто близнецы, полная аналогия.
И Logical References между иерархиями.
Мне так кажется, не все поняли что это такое, а из скромности молчат...
Ну чтобы реноме не уронить.
Хотя, по-большому счёту...
Может в той же каше и круче. Во всяком случае - загадочней, это уж точно - "объём", он жеть не плоскость...

SergSuper,

и вам спасибо.
я от вас массу нового и полезного узнал

iv_an_ru,

ну так они скомуниздили.
Это с 1968 года
http://img824.imageshack.us/img824/5980/formatv.png
ну вот, к примеру, так на диске.

Кстати, по структуре - если обратили внимание на START - поля вполне могут пересекатся.

iv_an_ru,

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

iv_an_ru,

ой, народ, ну а на основании чего сделан вывод что она НЕ используетися?
Если она выполнена аппаратно, и в софтовом слое не представлена - это что, не кошерно?
Вот нельзя было по-другому - спросить "а компрессия не используется?"
вместо утверждения, что она не используется....
не конструктивно.
Кстати, DB2 L/U/W и DB2/Z имеют компрессию, но в последней опять же не в софтовом слое, а в аппаратном.
Стратьс IBM к реализации фич на самом нижнем уровне.
Вот к примеру сортировка - с z/OS опционально поставляется подсистема DFSORT, которая предоставляет сервис сортировки всему, начиная COBOLу и заканчивая DB2.
Если кто-то забудет купить эту опцию, то DB2/Z сильно разочаруется :)

[quot iv_an_ruСтех пор отношение скорости процов к скорости чтения с жёсткого диска увеличилось настолько, что стало выгодно сжимать данные, причём выгодно и по деньгам и по производительности.[/quot]
прям создаётся впечатление, что вы уверены - в IBM об этом не знают.
То есть ни процов не создают, ни технологий не создают, которые потом все остальные процестроители покупают у IBM...
Отстали ну просто совсем..

iv_an_ruВот нельзя было написать "так представляется каналом ввода-вывода" вместо "так на диске"?
ээ, нет :)
так на диске!
Декомпрессия происходит после извлечения из VSAM/OSAM, и перед отдачей приложению :)
А компрессия, соответственно, после получения от приложения, и перед записью на диск в структуре VSAM/OSAM.
Так что структура VSAM/OSAM, на рисунке, вполне справедливая - сегмент там уже пожатый.
Это всё ваше предвзятое мнение, что IBM ничего толкового сделать не может, и хреновый IBM маркетинг, который допустил такое ваше предвзятое мнение :)
Если серёзно - то не могу же я сразу во всех подробностях, очень много деталей приходится опускать.
Но это не повод!
Можно и нужно спрашивать! :)