хорошая статья. разрешите добавить свои впечатления о IMS.
положительные:
- монитор транзакций IMS TM много проще CICS, но естественно, и возможностей у него меньше. Если распределенные транзакции не нужны, IMS TM в большинстве случаев вполне достаточен
- компонент OTMA позволяет IMS взаимодействовать с другими подсистемами и, в частности, c MQseries.
- как и говориться в статье, у IMS высокая эффективность.
отрицательные:
- примитивный язык запросов IMS DB да и сама IMS DB с упрощенной иерархической моделью это все же прошлое;
- крайне устаревший дубовый интерфейс;

выскажу свое мнение: целесообразно использовать IMS TM с DB2 а не с IMS DB, использовать IMS DB для новых приложений я бы не советовал. Архитекура приложения может быть, например, такой: java-клиент-MQseries-OTMA-IMS TM-серверная транзакция.

так с DB2 - теряется сила иерархической модели. я как понимаю, IMS DB - это как пушка или ракета... ее зарядили, спроектировали, нацелили. на каждом этапе ошибки сильно противопоказаны. и практически неисправимы, когда ракета полетела... зато как быстро летит)))

1) Функциональные возможности IMS TM постоянно совершенствуются, различие с CICS сглаживается, но остаётся. Может, это и правильно, если архитектурно позиционировать IMS TM как слой доступа к данным, а CICS - сервер приложений общего назначения.
2) IMS - не сложная система. Проще DB2. Менее известная - да.
3) Язык запросов нельзя назвать примитивным. Да, образно говоря, Get/Put и их вариации. Но так и должно быть. Вы ldapsearch/ldapadd не называете примитивным? А в ведь прямой аналог, в некотором приближении. Указали нужный PCB (грубо говоря, View, если сравнивать с реляционкой, то есть, содержание предложения FROM), указали (построили) SSA (Segment Search Argument (аналог предложения WHERE в реляционках), выполнили GU (Get Unique), по выходе из вызова "курсор" спозиционирован на первом сегменте, попадающем под условия выбора SSA. Дальше несколько вариантов, в отличие от ldapsearch. Можно выполнить GNU (Get Next Unique), и получить следующий сегмент, удовлетворяющий условиям выбора, который может быть где угодно, по отношению к предыдущему сегменту. А можно выполнить GN (Get Next), для выполнения обхода по иерархии (сверху вниз, спереди назад, слева направо). Учитывая разные типы указателей, которые могут быть в префиксе сегментов, перемещатся можно очень хитрыми путями. А добавив Secondary Indexes и Logical Reference можно выполнять обходы сетевых структур и выполнять прочие фантастически выглядящие вещи. Помечу, что индексами управляет сама DB. Но использовать их можно вполне самостоятельно, не делая разницы между ними и данными. Индексы удобны для захода в иерархию "сбоку" или "снизу". А Logical Reference - для связи иерархий между собой.
Так что язык доступа вполне адекватен возлагающимся на него задачам.
Ну и про упрощённую иерархическую модель - надеюсь, немного стало понятней, что она совсем не упрощённая. Позволяет строить как сложнейшие развитые сетевые модели, так и глубокие рекурсивные. Криво выразился, но, надеюсь, понятно.
3) Это не прошлое. Это настоящее и будущее. Финансово платёжных систем. Сюда же сложность разработки структур, негибкость структур (вы много видели изменения структур серйозных платёжных систем в RDBMS "на лету"? ага, щаз...), и полёт ракеты со снярядом.
Со времени принятия в финансовом учёте принципа double entry - двойной записи - принципиально ничего не изменилось. А это, на минуточку, 1452 год, монах Лука Пачоли. Совершенствовалисть инструменты. Пергамент, бумага, компьютеры. Но принцип не изменился. И, что интересно, нет предпосылок к его изменению.
Поэтому можно предположить, что если базовая, фундаментальная операция финансового мира, перевод денег со счёта на счёт, выполнена на IMS DB, то надстройку, окружение, составляющее всевозможнейшие банковские и прочие продукты, может менятся сколько угодно, и как угодно. Для этого постоянно и развиваются интерфейсы доступа. XML, Java, JDBC (с SQL, да-да) и далее везде. Ничто не мешает сторить композитные системы. Чем занимаются все. Кроме РФ.
4) В IMS DB можно точно знать, за сколько операций I/O будут получены данные. Подсчитать можно. Это даёт некую основу для планирования времени отклика. В отличие от. RDBMS.
5) В IMS TM каждая транзакция (приложение) выполняется в своём регионе. В отличие от того же CICS, в котором, в случае Multi Region можно настроить, что отдельные классы транзакций (приложений) работают в своих регионах. Но чтобы каждой отдельный?! Это к IMS. Что это значит - такая степень изолированности финансовых транзакций - пояснять не надо. Службы безопастности финансовых структур "горло перегрызут" предложившему уйти с IMS.
6) 6) Приятная особенность для организаций федерального уровня - возможность управление доступом к данным на уровне партиций. Можно партиционировать по регионам, и нарезать права доступа. База одна - права дсотупа - разные. Без накладных расходов.
7) IMS никоем обраом не серебрянная пуля. Просто есть ниша, где без неё не обойтись. Как бы она не называлась умершей и устарелой. Просто есть ниша, где по ряду нефункциональных требований, кроме IMS и аналогичных продуктов, просто не обойтись.

Как-то так.

Я бы сказал так: без IMS обойтись можно, просто для достижения нужных характеристик нужно более дорогой процессор, больше памяти и все такое.
Дело в том, что у нас оценки внедрения и владения строятся очень субъективно и непрозрачно. Поэтому решить, эффективно или нет внедрять IMS или нет (с учетом стоимости подготовки специалистов) очень сложно - ведь надо соотносить со стоимостью приложения.
А так - да. Система интересная.

Ну так архитектуру определяют нефункциональные требования.
Если функционал пересекается - то ясно, что без чего-то одного можно обойтись.
А если глянуть с не совсем функциональной точки зрения?
Той же пресловутой безопастности?
Чем заменить? То есть, чем достичь сравнимый уровень изоляции отдельных финансовых проводок?
Устойчивость, к примеру. Которая resilience. Ну вот превосходит IMS по этому показателю реляционки, и ничего с этим не поделать. За счёт простоты устройства
Вам же, наверное, русскоязычные американци приводили пример, как компания в штатах делает аутсорсинг платёжных систем для более чем 650 банков, это сотни тысяч отделений, коллосальная нагрузка.
За всё про всё - 8 (прописью - восемь!) администраторов.
Приложений на IMS для нашего рынка нет. Значит, плюсуем стоимость разработки.
Да, считать и считать.
С другой стороны, у нас практически нет централизованных систем с охватом всей РФ. Все системки размазаны тонким слоем более-менее равномерно по регионам - распределённые. Ну и все они как-то интегрированы друг с другом.
А сравните с централизованными западными системами, где одна система содержит данные ВСЕГО бизнеса, который, за частую, world wide?
Где наша Национальная Платёжная система?
Я лично о ней с 2005 года слышу.
Нету.
Да, всё-таки у нас мудрое руководство.
ну что не вступает в ВТО сломя голову.
Иначе если сюда придут банки, страховые, и прочие, опирающиеся на Единственную копию оперативных данных - то это уже само по себе громадное конкурентное преимущество, по сравнению с нашим бизнесомЮ построенным по областному принципу, распределённому.
Да мы просто не сможем так быстро и такие продукты выводить на рынок, как они!
Вот и имеем, что имеем.
Надо считать.
Что мы выигрываем, и что проигрываем.
И на каком уровне развития мы стоим.
Или, может, Национальную Платёжную Систему будем строить на .Net и Windows Data чего-то там эдишин?
Так что не всё упирается в денежный вопрос.
Не всё подсчитывается, наверное.
Как просчитать конкурентные преимущества - я не знаю.
Но ведь кто-то знает?

Конечно, не все определяется деньгами. И для национальной платежной системы IMS - самое оно. Только вот дадут ли делать общенациональный банковский продукт на несертифицированной чужой системе?)))
Я вот что хочу сказать. 1) Считать у нас не умеют. Пилить - да, а считать, соизмерять риски и проводить решения, особенно национального масштаба - нет 2) Я неоднократно заявлял - у нас непопулярны инвестиционные ИТ-решения. Ну такие, чтобы один раз заплатил, а потом спокойно работаешь и мягко поддерживаешь. Почему непопулярны - понятно, крутой откат один раз, а потом только работа.
Так вот создание централизованных решений вообще и на мейнфреймах в частности - это именно тот самый инвестиционный характер затрат. А децентрализованные дорогие доморощенные системы - это предсказуемо дойная корова. Да на ней менеджеры от ИТ будут жить вечно! А бизнес, который их должен подровнять, понимает - совсем не идеальная ИТ дает им конкурентное преимущество.
Вывод - если бизнес будет поставлен в условия, когда централизацованные ИТ-решения дает реальные преимущества перед конкурентами, и такие конкуренты будут, то тут же и IMS, и мейнфреймы весело побегут в работу.
Да это вы и сами знаете, мы же практически об одном говорим)).

1) Сертификация - а что мешает? Сертифицировать? Надо было сертифицировать MQ - ведь сделали? Не надо у нас это никому.
2) По поводу остального - согласен. Потому именно мы и имеем, что имеем.
Мы ведь даже и не спорим - мы ведь только соглашаемся
А правительство у нас мудрое - не пускает всяких конкурентов... Путём невступания куда не надо сломя голову. Консервируя таким образом ситуацию. При которой там хорошо всем живётся. И вендорам, между прочим, тоже. ПиСюки и Риски вагонами продавать... Да софт по-ядерно лицензировать... Золотое дно! (помним утилизацию тех процессоров...)
Все довольны. Кроме потребителей услуг, ну и нас, озабоченных...
Вот и имеем то, что имеем...
Вы здорово придумали - оценка развитости ИТ систем по признаку применения классического софта. Фундаментального.
Так здесь мы позади не только Польши, но и Египта.
А Китай - вообще недосягаемый пока Эверест для нас.
Там прекрасную платёжную систему национального масштаба на IMS строят, разнеся её, на всякий случай, в разные края Поднебесной.
Война ведь, или катаклизмы, не отменяют товарно-денежных отношений.
А значит, платежи должны проходить.
А значит, со счёта на счёт, по принципу, применявшемся ещё до древних греков, но зафиксированном в математическом труде Лукой. Не который Мудищев, а который Пачоли.
А значит, есть место. Для Z с IMS.
Правда, в штуках немного.
В выполняемой работе - гораздо больше.
Тут главное, выбрать правильно попугая для измерения.
Вам русскоязычные американцы не говорили, что 80% финансовых транзакций мира проводятся в IMS?
А в штуках - на уровне статистической погрешности, если, к примеру, с MS SQL или MySQL сранвить. Да хоть с чем.

Да, мне говорили американцы (и не только русскоязычные) о том, что 80% транзакций идет в IMS. И я им верю. А Вы верите, что в России будет самым конкурентным банк, который добьется минимальной стоимости транзакции при заданных, весьма приличных, показателях по скорости? Я - нет. На рынке ИТ погоду формирует бизнес. Он у нас такой, какой есть. Поэтому перспективу тех или иных решений я оцениваю с учетом своего представления о приоритетах менеджеров.
А мне IMS нравится. Именно тем, чем не нравится нашим менеджерам - инвестиционным характером вложений, консерватизмом, надежностью, скоростью и некоторой, кхм, негибкостью (в правильном понимании этого слова как необходимостью предварительного качественного проектирования).

1) У нас конкурентное преимущество меряется расстоянием к Телу. Но тем не менее, надо пытаться. Может, не банк, платёжные системы есть не только там. А в те федеральные организации, которые вынуждены строить системы. Которых по ряду причин просто нет. И такие места есть. Всё одно мы должны пройти тот путь, который прошли другие. И когда будут системы, тогда из них можно будет сделать сервисы (не означает web services), описав и стандартизовав интерфейсы, вот только тогда может стать актуально SOA. А не имея систем, то есть сервисов, какая нафиг SOA? Как сказал один специалист, "Да писали мы на Process Server, тормозит!". Вот и вся SOA. Ну кто сказал, что на нём надо "писать"?! А не управлять. Уже написанными системами... Если есть такая возможность - это не значит, что только так и надо делать...
2) Именно! Проектирование! Нынче уже почти ругательство... Я бы вам рассказал, про разговор Заказчика с Разработчиком, а я как третейский судья... Это было бы смешно, если бы не хотелось плакать. Открываешь документацию IBM - первым делом идёт глава Planning. По любым продуктам. Вы проверьте. (Загнул я, наверное. По любым "моим" продуктам). И что? Да все игнорируют! Переходят сразу или к администрированию, или к разработке, кому что.
И на Unix'ах такое прокатывает. А на Z - фигушки!
И это правильно!
"Мысль опережает действие" (с) Диверсанты.
Думать надо.
Но работа головного мозга очень энергоёмка. Затратна очень.
Ещё Джек Лондон, кажется, в "Белом Безмолвии", писал - человек не может одновременно согреваться и думать. Я с ним согласен - проверено на себе.
А у нас - страна северная. Нам думать - много калорий надо.
Лень, короче.
Зачем? В смысле, зачем экономить? Бюджетные деньги? Это же решение дешевле будет! Да вы что? Дальше самоцензура...

http://www.rbcdaily.ru/2010/06/03/finance/483384
Размах!
Как раз по нашей теме.

А то!
Неужели IBM пропустит и не примет участия в осчастливливании Сбербанка? А вообще - ребята они забойные. Один ребрендинг знака у McCann Erickson и у Fitch - это круто! (Пруфлинк) Так что полмиллиарда на ВЦ? Это попса. Явно недостаточно. И датацентр должен делать IBM, или Oracle, или другая пацанская компания.

в отсутсвии стратегии развития, и вообще понимания, что и как надо бы делать, дабы тостичь цели, то есть, отсутсвие Главного Инженера, или как-там-вы-его -зовёте, в присутсвии конфликта интересов, когда каждый начальничек каждого департамента имеет своё интерес, могу предположить, и можно делать ставки, что все эти немалые бюджеты окажутся размазаны по принципу "всем сёстрам по серьгам", то есть, каждому вендору по доле, с приличной долей интегратору на интегрирование.
И все будут довольны. Все при бюджетах.
То, что выхлоп будет хуже и дороже, чем мог бы быть, так "хотели как лучше, а получилось как всегда".
И ведь всё будет обосновано!

ну так это и есть наш бизнес, кому как не нам с вами знать. я вообще удивляюсь, как иногда технические решения внятные проскакивают.
по сути - поверьте на слово, даже наличие главного инженера ничего не гарантирует. потому как инженер (или проектировщик) должен быть грамотным, и его решения должны выполняться.
в качестве трепа. самый удачный проект по прокетированию-закупке-внедрению крупного ИТ-решения, где я принимал некоторое участие в конце 90-х, произошел на одном заводе в регионах. там главный инженер был сыном директора, а директор был мажоритарным акционером. так вот там мы убедили главного инженера, обосновали решение, и все пошло как по маслу, включая увольнение недовольных.

помимо моих бредовых мыслей, которые я в google buzz пихаю, на обкатку, вот
http://www.intuit.ru/department/os/ibmzos/14/
о необходимости централизации.
идея уже витает в воздухе.

и что вам тот buzz? помогает обкатать? пишите на этот сайт, я доступ открою, если есть желание.

это можно - более целевая аудитория
Желание есть, время тоже. Рабочее
Знаний маловато.
Вот, к примеру, к вопросу о централизации (вообще у меня это больное место, как и проблемы построения централизованных OLTP систем в РФ).
Есть стандартные complains против централизции, причём справедливые.
1) Дорогие каналы связи (отсутствие сюда же)
2) Дорогие специалисты (отсутсвие сюда же)
Данные по росту затрат компаний на специалистов я нашёл, случайно, у IDC. Эдакая задирающаяся кривая. Нехорошая, с точки зрения бизнеса кривая. Проблема. Надо что-то делать. Более того, в регионах просто специалистов нет - Москва высосала, с Калифорниями всякими. А обучишь - он тут же в ту же Москву свалит. Проблема.
А данных по каналам связи я не нашёл, хотя субъективно, из общения с многими - их есть в РФ. Всё больше, всё лучше, всё качественнее. Ну не везде - есть ещё жалобы. Но крупнейшие компании себя уже обеспечили. Хорошая такая кривая, понижающаяся.
Помещаем две кривые на график, по ординате затраты, по абциссе время в десятилетиях - одна на понижение стремительно, другая на повышение, пересекаются, точка пересечения в принципе даёт основание задуматься о централизации. Каждая организация может расчитать для себя. Затраты определить можно.
График я накидал.
А вот подтверждений ситуации по каналам не нашёл.
Сослаться не на что.
Остаётся моим частным мнением.
Естть ещё один красивый рисунок. По ординате как всегда затраты, а по абциссе очень интересная вещь. Возмём за постоянную размер бизнеса. Пусть хоть в количестве обслуживаемых пользователей, обрабатываемых данных, проводимых транзакций, или их компиляция. Достичь этого размера бизнеса можно по-разному - в РФ это множество областных систем, идентичных по функционалу, сопоставимых по объёму, на одной архитектуре, этакие типовые ПТК (Программно-Технические Комплексы). А можно одной большой централизованной системой. Так вот по абциссе затраты на сопровождение систем. И первый рассматриваемый случай, в котором растёт количество типовых систем, при постоянном объёме одной отдельной системы, а второй - растёт объём системы, при постоянном количестве - одна штука. Тоже очень красиво. Одна резко взлетает (иди обучи Z спеиалиста), переходя в горизонталь (от размера Z количество работы почти не меняется), а вторая, начиная с низкого старта (каждая домохозяйка), резко начинает взлетать при умножении количества систем. Эдакое пересечени е экспоненты с логарифмом.
Мда.
Тоже нарисовал.
Ещё бы фактуры, на подтверждение.
Да кто же даст!

так я же этот сайт и задумал - для целевой аудитории, и в то же время для частных мнений. потому он такой и есть - не на деньги работодателей, и не с их согласия, ибо частный ресурс.
а вот напишите, если не лень, такую статью с графиками. сунем сюда, кросспостинг пойдет в ЖЖ и blogspot.com, li.ru, ya.ru и прочие злачные места.

писать, оказывается, уметь надо...

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

да пишу

4) В IMS DB можно точно знать, за сколько операций I/O будут получены данные. Подсчитать можно. Это даёт некую основу для планирования времени отклика. В отличие от. RDBMS.
Да, именно так! это важный момент который я упустил...

3) Язык запросов нельзя назвать примитивным. Да, образно говоря, Get/Put и их вариации....
Подумал и решил что Вы правы, а мой тезис "примитивный язык запросов IMS DB да и сама IMS DB с упрощенной иерархической моделью это все же прошлое" неверен. Язык запросов и модель данных IMS просто другие, нежели чем у RDBMS, и все.

да пишу
Пишите, интересно! и Ваш стиль мне нравится

Ещё бы моему начальству нравился.... Цены бы мне небыло!
Мне это по работе написать надо бы.
Не то, чтобы именно мне.
Но никто не берётся.
А у меня девиз "Никто кроме нас" (с) ВДВ
Вот и пишу, получая звиздюлей от руководства. В том числе и за стиль.
Эмоций много... А нужен Документ!
Кстати, в теме исследоввания сравнение применимости и целесообразности применения (комплексное сравнение, не производительности) для одного и того же комплекса разных баз, конкретно - DB2 и IMS.
Функционально - идёт и та, и дргая.
Всё будут решать нефункциональные особенности, как и всегда.
Но действительно самому чертовски интересно.

Начальству нужен Документ - и это правильно. А у нас можете делиться с миром своими соображениями и домыслами)).

http://download.boulder.ibm.com/ibmdl/pub/software/data/sw-library/ims/idc-power-of-ims.pdf

сегодня на IBM-овской тусне было упоминание про этот документ.

Как впечатление?
Оценки выступающим сможете проставить?
В целом мнение негативное.
Положительное только по Олегу Летаеву, IBM Security Solutions, по Александру Тихонову, IBM Cognos, По Ирана Васти IMS, Евгений чуток отстаёт, тоже IMS (может, недостаток времени?), Дмитрий Лактионов IBM Enterprise COntent Management.
Остальные неудовлетворительно.

Да, Летаев был хорош. Лактионов тоже оставил приятное впечатление. Ирана и Женя Ляхович просто действовали в условиях дефицита времени, это так. Девушка с ILOG (яркая такая) была просто очень тихой, хотя материал у нее интересный. Оле Стреловой надо больше на публике работать, ей практики не хватает.
А вообще - у меня более положительное впечатление, чем отрицательное.

Имеем конспект данного материала тут.

Кстати, с 2008 года EGL (http://en.wikipedia.org/wiki/EGL_(programming_language)) поддерживает DL/I.
Надеюсь в этом году попробовать.
Это избавляет от множества технических деталей. Должно избавлять.
Давая возможность сосредоточиться на бизнес функционале.
код может деплоится в самостоятельное приложение, в транзакцию CICS, или транзакцию IMS.
Которые в свою очередь можно дёргать как сервисы откуда угодно.

Вот если попробуете и оно реально хорошо работает, то надо публиковать и учить этому людей, потому как у IBM средства разработки для мейнфреймов - ахиллесова пята, по моему мнению.

Ну если IBM сдвинулся - то рано или поздно будет работать хорошо.
EGL ведь не новая вещь. И не на голом месте возник.
Всё-таки, продолжатель идей VaGen.
кстати, тынц и тынц
VaGen тоже не сразу распробовали, а теперь многие слезть не могут...
IBM как тот старый бык, который медленно сойдёт с горы....
А ахилессова пята не только по вашему мнению, иначе бы в IBM не заявили, что будущие платформы - в успехе Rational.
О как, Ни в процах, ни в каналах, в Rational.