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

Для чего была разработана релционная теория - опущу.
А вот по поводу "без специальных знаний об организации БД" - оспорю.
Разработчик обязан знать структуру данных - разбиение данных на таблицы, наложение этих таблиц на бизнес-объекты, наименование ключевых полей, по которым должны объеденяться таблицы. Если разбиение данных на таблицы ещё можно вытянуть из системного каталога - то семантику (что значат эти данные) - уже с трудом. Можно получить комментарий таблицы, но программе он ничего не даст. Не всегда reference ключи могут быть - теория и имплементация допускают объединение таблиц без использования ссылочной целостности. В таком случае только знание структуры поможет. Хотелось бы верить, что ссылочная целостность есть всегда, но это не так.
Кроме того разработчику надо знать наличие ограничений (constraints) на таблицах. Их тоже можно выдернуть из системного каталога, но обрабатывать программно... Допустим, но это явно не основной способ.
Хорошему разработчику знать надо больше. Для создания эффективных приложений.

Спорное утверждение, слишком субъективное. На сколько не подходит, каких сложных структур?
Реляционным представлением можно выразить сколь угодно сложную структуру. Другой вопрос - насколько эффективно будут осуществлятся разные виды доступа к этой структуре?
Как небольшое отсупление. Я подмечал две противоположные тенденции.
Сперва структура высокой степени нормализации, а приложения по логике работы требуют данных, которые являются результатом объединения множетсва таблиц - начиная, наверное, с 5 и больше. Когда таких запросов много, большинство - начинаются "тормоза".
Проводят некоторую денормализацию - появляются свои косяки, не эффективное использование устройств хранения, дублирование информации, возрастает возможность ошибок, излишний ввод/вывод.
Так и шарахаются, как маятник, в поисках золотой середины (ну максимум два раза - дальше забивают и наращивают мощности железа, благо оно росло опережающими темпами, покрывая косяки проектирования и программирования, отдельная больная тема, требующая отдельного раскрытия, железа то можно взять больше, но в связи с заговором вендоров и лицензиями по ядрам - такая неэффективность начала выходить боком - приводит к удорожанию систем, на радость интеграторам и вендорам).
Да и если взять саму технологию - объединение таблиц методом сравнения полей всегда будет проигрывать использованию ссылок.

Это может быть, но есть тригеры, которые позволяют решить эту проблему на уровне базы, если не хватает возможностей referential integrity. Не самый изящный способ, но можно. Эффективность тоже будеь сильно зависеть, и менятся... Как правило в худшую сторону.

Честно говоря, не слышал ни об одном проекте, не сомневаюсь, что есть, но хотел бы просто знать.

К надёжности и доступности я бы добавил ещё и защищённость, как в широком смысле, так и в узком - ограничении несанкционированного доступа, или как оно там, разграничение доступа, контроль доступа, аудит, и прочая.
Всё-таки PSB/PCB - "жосткая" вещь в плане контроля над функционалом, над доступом к данным. Про что каждая транзакция IMS TM выполняется в отдельном регионе я уже как-то писал.
Перспективы.... Практически с некоторого уровня системы (по совокупности нефункциональных требований), - монополист.
Да, не часто слышно про новые продажи. Что только говорит о стабильности финансового рынка и финансовых институтов.
Будут изменения в этом секторе - будут новые продажи.
А раз не появляется новых финансовых институтов - то некому и продавать.
При выходе развивающегося рынка на некоторый уровень, и появление на нём соответсвующих финансовых институтов - тут же возникает IMS. Китай. Eвропейский ЦБ.
Другой вопрос, что какой-то-там Credit Susse по своим финансовым транзакциям кроет все финансовые институты РФ вместе взятые как бык овцу.
Так потому у них и IMS. А не в финансовых институтах РФ.
Но ежели РФ будет развиваться - будут и перспективы IMS.

Та мы ж тут усе свои, что нам тот дисклаймер...
От я бы посмотрел, что бы мы с вами написали, если бы Сашка всю статью перевел. Там ведь масса таких забавных оборотов, которые Вы процитировали!

я что хотел дополнить. мне понравилась мысль, что в общем случае специфика данных не отображается на структуру реляционной СУБД. А в IMS и Adabas - запросто.
Вообще отмечаю повышение востребованности и интереса к нереляционным СУБД.

А я бы лично даже не на это упор делал.
Архитеткору там до лампочки, какими средствами воплотятся его стрелочки, соединяющие яйца, где яйца - объекты, а стрелочки - связи между ними.
А мне - не до лампочки.
Мне - интересно.
Если запросы будут идти тысячи раз в секунду - очень интересно.
И что я, лично я вижу?
Мне надо дёрнуть порцию данных.
Запись о владельце счёта, к примеру. Или даже часть записи - не все данные о нём.
Что имеем в RDBMS? Не будем брать во внимание все способы выполнения JOIN, возьмём самый распространённый - nested loop join.
Все взяли? В смысле, вспомнили, как оно работает?
Берём первую строку из одной таблицы (или индекса, а то тут же меня поправят - индекс будет создан по этим полям! не суть - из структуры данных), берём значение ключевого поля, берём запись из другой структуры данных, берём значения соответсвующего ключевого поля, сравниваем, если совпадает - в отдельный участок памяти, если не совпадает - переходим к следующей строке во второй структуре, и так пока не закончатся строки во второй структуре, все ли, или диапазон - не суть. Затем берём вторую строку из первой структуры, и цикл повторяется.
И не волнует, что мне нужна была всего одна запись.
Нет, может быть и крайний случай - по уникальным ключам, и сразу - одна запись готова, в сборе.
Всё равно операция сравнения никуда не делась, на равенство значений ключевых полей.
Но может быть и другой крайний случай, когда как минимум в одной структуре данных (таблица/индекс) поле будет не уникальным.
Чисто реляционый подход - оперируем множествами.
Затем результирующий набор объединения может проходить операцию объедитнения ещё с одной таблицей, потом ещё... И если это очень-очень-очень часто... Хана производительности, или, если не так эмоционально, нужны будут соответсвующие аппаратные ресурсы.
А потом, в конце-концов, result set отдаётся программе, которая уже выполняет fetch записей, пока они не закончатся, записи будут содержать много мусора (ключевых полей и дупликатов полей при объединении) которые бизнесу нафиг не нужны, но по технологии - без них никак (если поле не перечислено в предложении SELECT это не значит, что его не подымут с диска... Страницу подымут... А это 4К минимум...)
А что IMS?
А не надо сегменты (структуры данных) объеденять - они уже соеденены, ссылками в префиксе.
То есть для извлечения одной цельной записи - явная экономия.
А что с множеством записей? Ну, вдруг следующие надо... Типа - отчётик...
Так таки если есть соотвествующая структура, из которых надо выбрать записи по какому либо критерию, то ситуация просто повторяется до тех пор, пока не закончатся нужные сегменты. Типа - как fetch. Но без соответсвующих накладных расходов.
И если размер записи известен - а он таки да, известен - то минимальная единица подымаемой из диска информации будет как раз тот, что нужен. А не 4К, и делай что хочешь.
Кстати, если не на VSAM, а на OSAM, построена иерархия, то там своя канальная программа, которая, если обнаруживает последовательный доступ, начинает делать упреждающее чтение сегментов.
Ключевой момент - если есть соответсвующая структура.
Ибо в RDBMS по-любому можно данные в таблицах объеденить, индексы только облегчают процесс, без них может быть дольше - но данные получим.
А в IMS при отсутсвии соотвествующей структуры - нифига мы не получим, придётся прогу писать - возмём из этой структурки сегментик такой, из него поле, а затем пробежимся по вот этой структурке, проверяя во всех сегментах поле на запомненное значение, при совпадении выбираем...
Знакомо, да?
То есть, то, что за нас делает оптимизатор - придётся делать руками.
То есть, быстро результат не получим - надо подумать, написать прогу, скомпилячить, оттестировать...
Гемморой...
Если это нужно однократно.
Но!
Если это нужно 44000 раз в секунду?
не проще ли построить соотвествующую структуру однократно, и свести задачу к уже решённой...
Тут ведь как.... если 50 раз в секунду - игра может и не стоит свеч...
А на 1000 раз в секунду - накладные расходы могут быть уже чувствительными и не оправданными.
Опять какой-то сумбур...

Вот это все почти в аналогичных выражениях я объяснял недавно большому стороннику применения реляционных СУБД в банковском деле. Теперь ему просто пошлю ссылку на Ваш комментарий в качестве конспекта моих объяснений.

что за дела, только что это же самое пояснял, но уже по надобности, с примерами...
Так что могу задублировать мысли сюда, если интересно.
А именно - отвечал на претензии к IMS.
Сложность разработки.
Отсутсвие специалистов.
Неспособность изменятся под изменяющиеся условия и задачи.
Неоправданное усложнение IT инфраструктуры - DB2 то никто не отменял, аналитика там, ERP, другие задачи.
Да зачем вообще IMS, можно на CICS+VSAM, будет ничуть не медленнее.
IMS TM медленнее CICS.

Конечно, интересно.
Пишите как нравится, можно непричесанно. Ибо у нас тут вменяемые люди пасутся, разберемся.

IMS TM медленнее CICS???? Это на каких же задачах? Или я чего не понял или понял неправильно?

Сложность разработки.
В целом, разработка прикладных систем под готовые структуры IMS DB гораздо (!) проще, чем под структуры DB2. IMS предоставляет очень простые средства доступа к данным, сам доступ к данным однозначен, и на этом этапе не может быть ошибки. В то же время, SQL гораздо гибче, позволяет решить одну задачу разными средствами, которые могут оказаться не одинаково эффективными, и не всегда заранее можно сказать, какой способ извлечения данных будет эффективным.
Но IMS требует структур данных, соответсвующих ожидаемым способам доступа. И к построению этих структур данных надо относится со всей серйозностью.
Значит ли это, что структуры данных IMS проектировать сложнее, чем DB2?
Как ни странно будет звучать - вовсе нет!
Во-первых, сами по себе реляционные структуры получается более грозоздкими, чем соответсвующие им сетевые структуры .
Во-вторых, проблемы и ошибки в проектировании структур данных могут обладать эффектом позднего выявления. Что мы и имеем возможность наблюдать практически во всех крупных проектах. Именно гибкость реляционных структур и языка SQL дают возможность выполнять доступ к данным в любых структурах, даже не самых оптимальных. На этапе разработки, и даже на этапе опытной эксплуатациии это не всегда удаётся выявить. Но при сдаче системы в промышленную эксплуатацию выявляются недопустимая производительность системы по причине не соответствия запросам к данным существующим структурам данных. Особенно характерно это выражено в очень крупных системах. Что мы и имеем в системе заказчика. О чём есть соотвествующий документ по результам нагрузочного тестирования от .... Выясняется, что в платёжной системе небыло понятия счёт и баланс счёта. И когда появится в промышленной эксплуатации - неизвестно. Но при использовании IMS такая ситуация просто не могла бы возникнуть - такой ошибке просто нет места. Могу пояснить, но считаю излишним - написать программу, пробегfющую по всем сегментам платежей с целью суммирования значений и выяснения баланса, немного не тоже самое, что написать select sum() from payments where...
Вот именно эту разницу в усилиях я и называю поздним выявлением проблемы. Проблему с отсутсвием понятия счёт и баланс выявили. На этапе промышленной эксплуатации.
Если бы пазл начали строить сначала, могли выявить раньше. То есть, риск ошибки на этапе проектирования данных больше, чем в IMS, и именно из-за особенностей платформы - гибкости способов доступа к данным.
Как вывод - миф о более сложной разhаботке под IMS не состоятелен, при правильно организованном архитектурном подходе сложность одинакова, но при отклонениях от правильного архитектурного подхода риск ошибок больше у DB2.
Заказчик склонен отдавать разработку на аутсорсинг, оставляя администрирование систем за собой.
С этой точки зрения разработка прикладных систем для ... не должна представлять никаких трудностей.
Если я правильно понимаю позицию ..., у нас есть эксперты нужной квалификации для проектирования систем, и для предачи опыта.

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

А вот тезис, что с IMS вы можем настроит плохо спроектированное
приложение, а с плохо спроектированными приложениями на DB2
вы вынуждены остаться жить навсегда - в целом
верен, но должен звучать не так, точнее будет - с IMS вы вынуждены
будете менять систему для получения работоспособного образца,
по-другому просто не получится. Это как раз и подводит к другому мифу
- о якобы не гибкости решений на IMS.
Да, они будут не гибкими - потому, что если оно уже работает - оно
оптимально, и менять нечего. Если не оптимально, то оно не работает, и
разработка не закончилась. На выходе всегда - оптимальная система.
А про RDBMS в целом и DB2 в частности - всё верно, наспех сделанную
неоптимальную систему чрезвычайно сложно изменить, что мы и наблюдаем
именно сейчас и именно у заказчика.
На основании всего этого - RDBMS не лучший выбор для критических
систем, которыми являются все финансовые, масштаба страны, в том числе
и у заказчика.

Отсуствие специалистов опущу, кроме мелкого замечания.
Во глубине сибирских руд компания не может начать внедрение Unix - только подготовят специалиста, как он сбегает в Москву
Специалисту по IMS, буде такого обучите, пока бежать некуда
Вопрос решается, в том числе и в рамках учебных программ университетов.
И не только.
Будем видеть.
Четсно говоря, роль этого вопроса явно переоценена.
Если взглянуть краем глазика на бюджеты, на которые тянут такие системы, то затраты на подготовку специалистов покажутся бесконечно малой, я вас уверяю.
Про пример компании, осуществляющей хостинг банковских систем на IMS, сколько им потребовалось специалистов для окучивания какого объёма работы?
В том то и дело.
На текущий момент только по Москве нехватка IT специалистов около 9% по данным IDC.
Повсеместная централизация и применение правильных систем способно кардинально изменить эти цифры

Системы заказчика должны быть способны быстро изменяться и подстраиваться под изменение задач и внешних условий.

Напрямую небыло заявлено, но я добавлю, потому как это всё о том же - очередной миф о недостаточной гибкости IMS. Или - иерархических систем вообще. Но я ограничусь только IMS. То есть - отсутсвие у IMS аналога ALTER TABLE.
Теоретически это так. Но вот практически мы наблюдаем несоотвествие структур данных посылаемым запросам на примере конкретной системы заказчика, смотрите выше, и наблюдаем попытки решить эту проблему. За довольно длительный срок были проведены частичные изменения структуры, не затрагивающие основных проблемных мест, и уже очень длительный период времени длится период тестирования, после разработки и изменения приложений. Речь о финансовой системе, учеренность в правильном функционировании должна быть полной. На общем фоне затраченного времени, не ведущего к полному решению проблемы, время, потраченное собственно на изменение структур предложениями ALTER TABLE исчезающе мало.
Это не теория - это реалии конкретного заказчика.
Случай не единичный.
Архитектурные ошибки исправляются очень тяжело, и вопрос не в ALTER TABLE.
В IMS генерируется новая структура, в которую заносятся данные со старой.
В целом более длительная операция, чем ALTER TABLE с последующим LOAD, но ещё раз - это время исчезающе мало на фоне всех затрат на исправление архитектурных ошибок.
Невозможно себе представить ситуацию изменения структуры данных с соответсвующим изменением приложений, если потребуется, на промышленной финансовой системе крупного масштаба в серйозной организации, без предварительных этапов разработки, всестороннего тестирования, в том числе с точки зрения безопастности. Можно смело утверждать, что в таких условиях это не восстребованная опция.
К любому изменению структуры даже не очень крупных систем готовятся тщательно и заблаговременно.
С другой стороны, способность систем к изменчивости не в базах, не в способах изменения структур данных, а в архитектурных подходах, положенных в основу систем. Это не имеет отношение к базе или к языку программирования.
Есть "удачные" примеры внедрения решений на абсолютно объектно-ориентированных средах, на абсолютно реляционных базах - на .Net и MS SQL сервер, которые оказались абсолютно монолитными и не способными изменятся, из-за архитектурных проблем вообще и из-за отсутсвия архитектурного уровня доступа к данным.
С другой стороны есть примеры решений на COBOL, IMS TM, IMS DB, CICS, которые все из себя процедурно-ориентированы, записе-ориентированы, но в силу применённых архитуктурных подходов абсолютно модульны, видоизменяемы, пережившие эпоху терминала, и успешно живущие в эпоху web 2.0.
В любой системе финансового учёта лежит базовый неизменный принцип двойной записи - 1452 год, Лука Пачоли, описал в математическом труде, это и положено в основу летоисчисления современных финансовых систем.
Имея неизменный набор примитивных объектов - счёт, владелец счёта, баланс счёта, и одну основную операцию - платёж, как дебит по одному счёту, и кредит по другому, возможно построить сколь угодно сложную финансовую систему, потому как этот базис лежит в основе любой из них, всё остальное как надстройка над базисом.
Так вот в силу некоторых характеристик, так получилось, что IMS лучше всего приспособлена к огромному количеству проведения параллельных платежей с максимальным уровнем гарантий по достоверности, изолированности, устойчивости.
Если речь не об огромном количестве платежей - возможно, это задача не для IMS, возможны варианты. В случае огромного количества платежей - вариантов нет. В случае очень-очень огромного количества платежей опять происходит переход количества в качество и опять нет вариантов, кроме zTPF. Я искренне желаю заказчику достичь таких объёмов, тогда у них будут совсем другие проблемы, и не будет головной боли с DB2, IMS, CICS, WAS.

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

Но это принципиальный подход IBM, в отличие, скажем, от Oracle - не всё в одном, а набор специализированных инструментов, каждый из которых решает лучше свой класс задач.
С этой точки зрения затраты на внедрение и обслуживание IMS окупаются снижением требованиями к аппаратным ресурсам и сопутсвующим ему снижением лицензионных платежей.
С другой стороны, IMS позиционируется для особо критических, ответсвенных участков систем. С этой точки зрения она по ряду характеристик превосходит DB2. Имеющиеся сведения о системах заказчика позволяют утверждать, что в них есть участки, от которых зависит основная деятельность заказчика, и к которым предъявляются особые требования. И когда речь идёт о централизации критических подсистем, риски многократно возрастают, соотвественно растут и требования к платформе. Здесь уже речь не о лицензионных отчислениях - а о доступности данных, о разграничении доступа, об изолированности транзакций параллельных однотипных транзакций, о скорости восстановления.
Можно сказать, что по совокупности факторов, вопрос применения IMS в данном конкретном проекте может дать другие преимущества, не очевидные большинству заранее. Ведь речь не идёт только о повышении производительности со всеми вытекающими ценовыми последствиями.
Это и вопрос принципиально другого, гораздо более простого способа организации разграничения доступа пользователей регионов и федеральных пользователей к данным соответсвующих регионов и ко всем данным - по сравнению с другими системами, в том числе DB2.
Это и вопрос возможнности точного определения количества операций ввода/вывод, требуемых для получения конкретных данных, из-за предопределённости путей доступа к данным, что даёт основу для оценки времени доступа к этим данным. В случае использования реляционых баз такое принципиально невозможно, гибкость способов доступа и наличие оптимизатора делают поведение при доступе к данным не предсказуемым, и изменения в планах доступа наступают, как правило, в самые критические моменты, при повышенной нагрузке и резком изменении количества данных, и при множестве других случаев.

Признавая, что IMS DB демонстрирует недостижимые характеристики в производительности по сравнению с DB2, есть предложение от ... решить особо критические с точки зрения производительности участки связкой CICS и VSAM.

Я отнюдь не хочу поставить под сомнение реализуемость или производительность такого решения - все мы знаем, что это возможно и производительно.
Я просто хочу вернутся к тому, зачем вообще IBM занялось разработкой СУБД, имея VSAM. И не только IBM.
СУБД появились как решение проблем доступа множества программ к одному источнику данных, который стал возможен после появления DASD. В мире последовательных устройств ввода/вывода такой проблемы вообще не стояло - программы эксклюзивно получали наборы данных, работыли с ними последовательно. Но появление DASD позволило технологически организовать одновременный доступ к одному набору данных из разных программ. Встала задача организации такого доступа архитектурно. Безусловно, были попытки решения этих задач в рамках прикладных систем, в рамках ОС , следы чего остались местами до сих пор. Но в целом индустрия приняла решения возложить эти специфические задачи на специальное ПО промежуточного уровня - СУБД. И решение оказалось верным, так как дало дополнительно ряд преимуществ, и теперь СУБД предоставляют значительно более богатый функционал и упрощают проектирование и разработку, чем решение без СУБД.
Можно ли обойтись без СУБД? Безусловно.
Оправданно ли это? Нет.
Множество вопросов, поддержание логической целостности данных, поддержание воспомогательных структур данных (индексы, и прочие специфические) полностью лежат на СУБД, и в случае отказа от них придётся это воплощать самостоятельно. В идеальном случае это будет не хуже, чем в существующих СУБД. Лучше не будет, могу показать на примере применения OSAM в IMS. Но высока вероятность, что будет хуже по каким-либо параметрам, к примеру, время на разработку, лёгкость сопровождения.
В целом, на текущем этапе, разработка с VSAM возможна, но явно не является основным направлением в финансовом секторе, особенно в сфере больших централизованных систем, закрывая доступ к ряду технологий, как партиционирование, и прочие.

> Что касается вопросов производительности и изолированности, то тут я выскажу
> следующие
> соображения. Требование ACID для юнитов работы (UOW) в транзакционных
> системах, как раз,
> и "говорит" о том, что I - isolation (изоляция юнита работы) должна быть
> обеспечена (и обеспечивается)
> транзакционным монитором.
> То, что таски запускаются в одном или разных адресных пространствах - это
> уже реализация.
> Само по себе это изоляцию не обеспечивает в полной мере (т.к. нужно еще
> изолировать доступ к данным в момент
> изменений),

Совершенно верно, ACID не имеет никакого отношение к выполнению каждой
отдельной проводки денег в отдельном адресном пространстве.
Но по поводу роли монитора транзакций можно уточнить.
Роль мониторов транзакций - в проведении согласованных изменений
множественных источников данных.
А согласованное изменение единственного источника данных, но
выполняющегося с разных программ - это задачач базы данных.
Естественно, возможны вариации - но это основной подход.
То есть, с внедрением DASD в полный рост встали две проблемы.
1) Как проводить изменения из одной программы к разным независимым
источникам данных.
2) Как из множества программ проводить изменения одного источника данных.
Ответом на первую проблему стало развитие мониторов транзакций, после,
в принципе, тупиковых попыток возложить это на операционную систему,
рудименты мы ещё можем наблюдать.
Ответом на вторую проблему стало развитие систем управления базами данных.
И задачи мониторов транзакций не пересекаются с задачами баз данных -
частично функционал может перекрываться, но изначально назначение
разное.

Выполнение отдельной проводки денег в отдельном адресном пространстве
имеет совсем другое назначение, чем обеспечение ACID.

Есть утверждение о более высокой производительности решения на CICS по сравнению с решением на IMS TM в силу архитектурных особенностей.

Речь шла об уровне изоляции транзакций IMS TM, выполнением каждой из них в собственном адресном пространстве, в связи с чем и появилось это утверждение. Я не готов вот так сразу сейчас ответить, возьму паузу, но дам несколько замечаний.
Есть вероятность, что ответ уже есть у наших коллег.
Есть вероятность, что требование к уровню изоляции транзакций будет более приоритетным по сравнению с требованием ко времени выполнения транзакции.
Есть вероятность выполнения DL/I (язык доступа IMS) из CICS.
До сих пор я встречался с утверждениями, что CICS более функционально богат, IMS более производителен.
Обратное утверждение поставило меня в тупик, требуется разобраться.
Прекрасная тема для проведения сравнительных испытаний.
> То, что таски запускаются в одном или разных адресных пространствах - это
> уже реализация.
> Само по себе это изоляцию не обеспечивает в полной мере (т.к. нужно еще
> изолировать доступ к данным в момент
> изменений),
> но имеет определенные плюсы и минусы. Плюс - что разрушение
> адресного пространства задачи
> не влияет на работу других, минус - переключение между TCB кушает около 2000
> машинных инструкций.
> С учетом, что кикс может запустить несколько регионов, то выполнение
> транзакций тоже можно распределить
> по нескольким TCB. Хотя я не уверен, что IMS КАЖДЫЙ task запускает под
> отдельным TCB. Насколько я помню,
> IMS имеет несколько "базовых" адресных пространств и транзакции при
> выполнении их используют.

Yes, IMS is attaching (more and more) TCBs a lot. Just to distinguish / separate functions or to explore parallelism (CPU is assigned to TCB, multi CPU CECs can serve and work for multiple TCBs - dispatched - in parallel) . But IMS internal tasks - so called itasks - are splitted , maybe share a TCB, maybe belong to their own one.)
So it's not necessarily a TCB SWITCh ( IMS names that ISWITCH) and especially for the MPP regions - running in DLI code once joined this will happen in cross memory mode , just branching forth and back! Very efficient ! and stopped first for a necessary I/O or something .
There are debugging Classes available talking about the IMS engine internally.

Вопрос создания новых систем на IMS не стоит, доживают свой век унаследованные системы, от которых пока не смогли отказатся по разным причинам.

Немного странно слышать такое заявление от специалиста, предлагающего критические участки решить связкой CICS + VSAM
Тем не менее рассмотрим.
Вопрос создания новых IMS не стоит. Но не делается оценки - почему не стоит.
А эта ситуация как раз свидетельствует о стабильности в финансовом секторе мировой экономики. Те финансовые институты, которые вышли на соответсвующий уровень развития, на котором совокупность требований к системе требуют применения IMS - уже её получили.
Рынок насыщен.
Новые финансовые институты каждый день не появляются, и старые резко не меняются.
Тем не менее, в связи со смещением вектора экономического развития в Азиатский регион, мы наблюдаем сопровождающий его всплеск развития финансовых институтов, и соответсвенные внедрения систем на базе IMS.
Если Россия будет развиваться - а у нас нет повода в этом сомневатся, правящая партия и правительство делают ставку на структурные изменения в экономике и опережающий рост темпов экономического развития, (правда, я эти словосочетания "перестройка" и "ускорения" слышу с 84 года) - то будут вынуждены развиваться и финансовые институты. Продолжающаяся интеграция в глобальную экономику, сопровождаемая вступлением в ВТО, неизбежно приведёт к росту финансового сектора, и возникновению конкуренции на финансовом рынке и сопутсвующих секторах (страхование, прочие). Конкурентные преимущества получат системы с сильно централизованными оперативными данными, которые резко сократят издержки на выполнение базовых операций. Опыт ... показывает, что хоть решить эти вопросы можно и без применения IMS, тем не менее, в подавляющем большинстве случаев эти вопросы решены именно на базе IMS, именно из-за совокупности её характеристик.
Уже пять лет прошло, как ....... национальной платёжной системы. Уже и президент неоднократно заявляел об этом стратегическом шаге. Но на текущий момент дело не сдвинулось, в том числе и по причине отсутсвия опыта построения таких систем, отсутсвия понимания в том, как такие системы строить.

Ну вот как-то так.
Ещё было приведено письмо коференции CICS, в котором IMS пиналось в том числе и на отсутсвие интерфейсов Java, Web, Soap
Ну не серйозно.
От-туда же и утверждение о более высокой производительности CICS по сравнению с IMS TM.
Правда, в самом начале автор сделал замечание, что лет 15 не работал с IMS TM, и лет 5 - с IMS DB
а само письмо датировано 2003 годом.
Не аргумент, короче.

http://www.listserv.uga.edu/cgi-bin/wa?A2=ind0306&L=cics-l&P=R55225&D=0
оригинал письма из CICS рассылки

http://www.listserv.uga.edu/cgi-bin/wa?S2=cics-l&D=0&q=&s=IMS+vs.+CICS&f=&a=&b=
все обсуждения темы.

Интересно.
Было выдернуто и прислано вложением одно отдельное письмо.
Но там ведь есть и другие мнения!

Вот здравый подход.
http://www.listserv.uga.edu/cgi-bin/wa?A2=ind0306&L=cics-l&P=R54605&D=0
http://www.listserv.uga.edu/cgi-bin/wa?A2=ind0306&L=cics-l&P=R54776&D=0

А вот, тот же автор, письмо которого было прислано, немного раньше пишет
http://www.listserv.uga.edu/cgi-bin/wa?A2=ind0306&L=cics-l&P=R55415&D=0

Again, I am a CICS/DB2 advocate, but a well tuned IMS/DB/DC environment will
perform extremely well. Many large IMS/DB/DC shops are still processing
upwards of 25 million transactions per day. I have seen a few cases
recently where
this is being done with less hardware than a similar volume, similar size
CICS/DB2 shop...

Я бы сказал, что выдёргивание этого конкретного письма, из всей линии
обсуждения, а тем более не приведение полного спектра мнений этого
автора по проблеме...
Не является полностью архитектурно выверенным
подходом.
Но в целом я согласен с другим автором - в случае заказчика надо
ставать на позицию "show me".

В целом, чудо не произошло.
Связка IMS DB/DC признаётся более производительной чем связка CICS/DB2.
Меня интересуют другие сочетания.
Есть много разработок IMS TM как DB2 Stored Procedures на стероидах.
Есть много CICS/DLI.

Надо изучить все сочетания.

дочитал.
выдохнул.
колоссально!

частные выводы:
1) про производительность IMS TM - успокоили. я предполагал, что там что-то выдернуто из контекста, даже начал сам искать инфу по этому поводу, но Ваша инфа появилась раньше.
2) проектирование и влияние на него моделей данных - тут тоже все поддерживаю, удивительно, что Ваш оппонент, похоже, Дейта «Введение в системы баз данных» не читал. Там изрядный ломоть книги - влияние нормализации реляционных баз на производительность, избыточность и целостность. Все в мелочах расписано - как нормализовать, как растут промежуточные структуры данных, сколько запросов и прочее. Про иерархические модели там тоже есть, но вот вопрос проектирования и производительности там очень поверхностно упоминается, ибо там все в руках разработчика.
3) с заказчиком Вам таки повезло - видать, умный. мои заказчики таких разговоров не вели, они заранее все знали, а тут у Вас хоть мнения спрашивают.