фиг его знает, где в инете старую доку искать.
"N-way sharing based on the new Coupling Facility hardware is much easier
than the old software-based block-level sharing."
Это вот отсюда http://documents.bmc.com/products/documents/36/96/103696/103696.pdf
Глава 17

vadiminfo
Говорили, что это иерахическая СУБД. Вроде ее к таковым относили в литературе. А далее говорил характерное для иерархических вообще: для структурирования типы записей, их коллекции, связи по указателям, ссылкам. Язык БД навигационный.

Применительно к IMS - не совсем навигационный, пример я дал.
vadiminfo
Ну а зачем ананалог, када есть СУБД с самим SQL?
Аналоги ведь могут праздно себя являть: SQL все же ориентирован на множесвенную (не упорядоченное множество) модель. А навигация на упорядоченное множество: коллекцию.
Отказываемся от коллекции? Отказываемся от иерархической МД в IMS? Ну тада что Вы хотите сказать, что IMS типа реляционная теперь стала? Или почти реляционная? Или и реляционная и иерархическая? Или сосбно что?
С одной стороны, ну, больше на одну РСУБД стало: у IBM уже две РСУБД есть, ну буит третья до кучи.
Но с другой стороны, нужно подтверждение, потому что IMS все же традиционный пример Иерархической СУБД дожившей до наших дней. Он типа их флагман был. А теперь он перебежал получается?
Нет, IMS не как бы реляционная.
И DL/I не SQL.
Просто анектод про "селект слон фром африка" - не про IMS.
в DL/I не указывается порядок извлечения данных.
Как бы это странно не казалось.
А SQL и оптимизатор IMS не нужен.
При всём при том, что всё-таки декларируется - какие данные надо вернуть.
В прямом смысле слова - указывается Segment Search Argument, который и есть аналог WHERE
Так понятнее?

Yo.!ппмда, в примере абонент -> счёт при запрашивании счёта по номеру, счёт конечно получим.
Но чуда не произойдёт, и для его получения IMS просмотрит все сегменты, пока не наткнётся на нужный.
Эдакий tablescan.
То есть ещё раз внимательно принцип - структура строится под запросы.

ну да, значит ничего принципиально не изменилось с лохматых годов. т.е. вы зашиваете в ПО как нужно доставать данные, а я зашиваю какие мне нужны данные. собственно поэтому каши и иерархические вымерли.
мое имхо единственная рулизная вещь у такой фигулины (и потому она гораздо интересней каши) это географически распределенный sysplex. вот вместе с sysplex действительно можно делать то, что нельзя на других субд/платформах с той же эффективностью. а так это такой асемблер для субд, где руками нужно прописывать методы доступа к данным, что может быть иногда оправдано, но в очень специфических случаях.
про дата шаринг почитаю на досуге, доложусь.
Понято с точностью до наоборот.
Интересно, на основе каких рассуждений сделан вывод о "зашиваете в ПО как нужно доставать данные" если я утверждал абсолютно обратное?
Ещё раз - в данном примере произойдёт аналог табличного скана, вполне самостоятельно, БЕЗ участия клиентского приложения, на стороне IMS, клиент получит свой сегмент.
Но чуда не бдет - будет перебор.
Как и в реляционке.
Нужен индексный доступ?
О чудо!
Надо строить индекс.
Как и в реляционке.
Да, как за много-много лет ДО IMS делалось на VSAM - KSDS.
Индексный доступ обеспечивается индексом.
Если нет индекса - РСУБД вернёт данные, приложение не знает об индексе, если не берём хинты.
Если нет индекса в данном примере - IMS вернёт данные, приложение не знает об индексе.
Так понятнее?
действительно, ничего не изменилось с лохматых годов - это основа IMS, так было всегда.
Не надо руками прописыватьт методы доступа - я с первого поста пытаюсь это пояснить .
Я понимаю, в это поверить невозможно, это противоречит мировозрению.
Но это так.
Документация доступна - читайте.
И это оказалось оправдано в 80% крупнейших финансовых институтов мира.
Но это как раз к "навигации" отношения не имеет.
Кстати, я ведь в примере про Fetch и пример навигации приводил - вызов GNP это как раз и есть навигация.
Сперва чисто декларативно затребовали клиента по фамилии Иванов, получили. Далее чито навигационно требуем его первый дочерний сегмент - и в этом нет криминала, потому что он первый, и потому что он дочерний, и IMS точно знает, где он лежит - у IMS в этот момент есть его точный адрес.
напукруа тут что-то другое?
Вы бы не начинали сразу оценивать, вы бы для начала попробовали понять, что ли :)
Вас никто не призывает мигрировать, более того, я могу утверждать, что вам и не повезёт попробовать IMS, на этом недо-рынке, где один не самый крупный шцейцарский банк кроет всё Россию со всеми финансовыми институтами как бык овцу - в таких условиях IMS вам никто не даст.
Так вы хоть спрашивайте, пока есть возможность и доступ к системе, вед можно и тестики прогнать, и примерчики.
То, что это устарело - я знаю, мне один "архитектор" страницу в инете показал, гдле по русски написано - представляет чисто академический интерес :) Ага, для России - в точку!
Так вот вы с академического интереса и подходите.
Можно вот КЛАДР структурку глянуть, запросики к ней создать.
Кстати, в IMS есть аналог SPUFI, так что программировать не надо, чтобы запрос выполнить.
Правда, он зело чудной, и вы матюкаться долго будете - параметры позиционные :)
Сказано в доке - операнд в десятой колонке, и никаких одинадцатых :)
Что есть - то есть :)
Но не в этом суть продукта.
Но в принципе, если вам ужо так всё понятно - то я таки настаивать не буду :)
Только сами подумайте с чего бы это китаёзы не оракл для национальной платёжной системы выбрали?
И даже не DB2.
Дураки потому что.

вы уж простите мне мою безграмотность - но что такое RDF, потому что гугл отсылает к http://www.w3.org/RDF/
А кэш я не затрагиваю по ряду причин.
Основная - IMS используется для OLTP, которому характерен случайный метод доступа к данным, к малым порциям данных. В этом случае кэш мало помагает, а вот сильный ввод-вывод - сильно помогает.
Есть фича, когда запрос, зная, какой будет следующий сегмент, запрашивает сразу два сегмента, родитель-потомок, есть фича OSAM, вместо VSAM, который не только организация данных, но и другая канальная программа, которая "распознаёт" тип доступа - случайный или последовательный, и в случае последовательного применяет упреждающее чтение.
Так что кэш - не самое.
Самое - много путей доступа к устройствам ввода-вывода.
в z9 их было 1024, если мне склероз не изменяет, или это уже в z10 - канала - это как 1024 шины применительно к другой платформе, хотя канал это не только путь доступа, но для простоты пусть будет так.

без сильного ввода-вывода организовать доступ параллельно к хотя бы 30000 разных сегментов одновременно в одну секунду будет затруднительно, а отдельно стоящая IMS выдала 44000 транзакций в секунду, транзакциями называется процедура IMS TM, то есть аналог хранимки.
Ясный пень, что процедура процедуре рознь, но пусть каждая из них затрагивала всего один сегмент.

iv_an_ruппмвы уж простите мне мою безграмотность - но что такое RDF, потому что гугл отсылает к http://www.w3.org/RDF/
Правильно отсылает.
ну на досуге посмотрю.
хотя, судя по некоторым признакам....
ему ещё долго щёки надувать, чтобы IMS уделать.

iv_an_ru
То есть у вас активное подмножество намного больше доступной ОЗУхи, я правильно понимаю? В таком случае интересно было бы узнать цену железок и какие-то циферки по размерам базы. А то вдруг выяснится, что кластер из 100 машинок по $5000 каждая и по цене сравним, и 100*10=1000 независимых винтов позволяют делать вполне недурственные цифры в т.ч. и на OLTP?

э, хоть один референс кластера OLTP на 100 машинках банковской платёжной системы?
Но вы не поверите - IMS может обойтись дешевле той же DB2 на сравнимой задаче - ресурсов меньше жрёт значительно, а в Z плата идёт за ресурс.
Кстати, почему-то практически в 100% там, где стоит IMS, стоит и DB2.
Неожиданно, правда?
Дураки какие-то, разные инструменты для разных задач используют...
То ли дело мы, одной кувалдой везде...
Там есть ещё занятные цифры по сравнению совместно используемого софта, но уже не в базах данных.

Yo.!
нет, я чуть усложню пример и вам будет не выкрутиться. сейчас лень придумывать какую-то прикладную область но суть такая: две таблицы, одна была больше, другая меньше. пока такая пропорция выгодно идти по второй, обратывая первую. если со временем первая стала, меньше чем вторая то IMS уже не перестроит схему доступа. завтра придумаю привязку к какой-нибудь предметной области
Вот-вот - типичные слова человека от сохи, то есть от реляционной базы!
Это оптимизатору выгодно!
Я дополню вашу задачу - надо вернуть ОДНУ запись из первой таблицы, и затем ОДНУ запись из второй, которая соответсвует первой, затем ОДНУ следующую из второй, соответсвующую первой.
И как бы оптимизатор ни пыжился, как бы не менял порядок таблиц, какой бы алгоритм не выбирал - я ведь вам писал про nested loop join - один хер в структуре IMS, где первая запись из первой таблицы содержит АДРЕС! связанной записи из второй, а та содержит адрес на следующую... Не получится, короче, у оптимизатора.
А порядок возврата сегментов определяет не количество записей, а бизнес-потребности, требования.

Yo.!
а вот это интересно. если IMS на z/OS было бы прикольно налабать какой-нить пример и прогнать сравнить z9 с писюком.
ну практически это и происходит.
только вот какая штука....
Чтобы Z получился выгоднее, или задача должна быть очень здоровая.
Или задач должно быть очень много.
А лучше всё вместе.
Тут даже не по деньгам сравнение.
по аппаратно-программному устройству писюка и Z.
z9 совсем не числогрыз, это последний z196 имеет 5 с лихуем гигагерц.

iv_an_ru
Сразу усугубим. Три таблицы, ROUTE (базовые сборочные последовательности), SP_OUT (отгрузки запчастей на другие заводы), SP_IN (приход запчастей с других заводов).

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

SELECT * from ROUTE r, SP_OUT o, SP_IN i
WHERE
o.R_ID = r.BEGIN_ID and i.ORIG_ID = o.DEST_ID and r.END_ID = i.R_ID

Таблицы связаны в треугольник тремя "равноправными" равенствами, возможны шесть способов перебора.
то есть историю возникновения IMS вы не глянули.
Она была создана под проект Союз-Апполон, и как раз под учёт сборочных узлов, деталей, и прочих механических припамбасов. К тому же рекурсии решаются просто.
Если хотите примерчик сделать - вы уж опишите, что за сущности имеем, как они взаимосвязаны, а то я не понял, что за базовая сборочная последовательность. Можно в терминах create table.
Только возвращатся при каждом вызове будет ОДНА сущность, для возврата всех придётся в цикле повторять - про аналог Fetch я уже писал, лень повторятся.
Вот из вашего запроса база тоже курсор сделает, из которого программа Fetch записи.

vadiminfo
Про то что я спросил не понятнее. Вы просто более детально подтвердили то, что я утверждал, т.е и так знал.
Ясно дело, что все производители наровят вставить деклпаративный язык. Но он может себя праздно являть. Вот Вы подверили, что порядолк не нужен. Т.е. не нужно иерархическое, а реляционого нет. Вот теперь возникает вопрос что за МД она поддерживает.
Так понятнее про вопрос?
то есть вы уже знаете, что такое IMS, и я только подтверждаю ваши знания?
Ну ладно.
Вы не поверите, но нигде в доке я ни разу не встречал упоминание о том, что за модель данных поддерживает IMS. такое впечатление, что им положить на чаяния наших базовиков.
Данные располагаются в сегментах, минимально обрабатываемой порции. Сегмент имеет служебную часть - префикс, недоступную программно. В префиксе находятся разные типы указателей. Указатели указвают на другой сегмент.
Указатель может быть не сегмент из другой иерархии - logical reference.
Сегменты расположены в иерархическом порядке, где один всегда root сегмент.
Но используя logical reference и secondary indexes рутовым сегментом можно сделать любой. Только он уже будет не физический родитель, а логический родитель.
Так, кстати, структура КЛАДР получилась, два сегмента, один рут, второй его потомок, но у потомка указатель на рут, и потомок выступает логическим родителем сегмента рут. Рекурсия то есть.
Это какая модель данных?
Мне лично - по барабану.
Вы себе как-то её обзовите.
Всё равно исходить надо из возможностей инструмента, а не подгонять его в ярлыковые рамки.
Вот к примеру программа запустилась, надо обращатся к базе за данными.
GU COURSE (COURBO = A1114)
STUDENT (LNAME= ИВАНОВ)
По выполнении этого в памяти программы будет сегмент типа STUDENT у котрого поле LNAME равно ИВАНОВ, при чём этот сегмент является дочерним сегментом сегмента COURSE, у которого поле COURNO равно A1114.
Вот это что? Навигация? Декларация?
По большому счёту по барабану, как это называется, это берёт абсолютно осознанное количество операций ввода-вывода, абсолютно осознанное количество процессорного времени, то есть абсолютно предсказуемо, за какой промежуток времени программа получит в память исходное.
При чём этот промежуток времени не зависит от количества записей.
Почему не зависит - гляньте описание HDAM и PHDAM. Только читать много, и материал не простой - они, гады, до байта всё разложили, что где лежит.

iv_an_ru
Да я поверю --- если старая система ещё жива, значит у неё есть какое-то толстое уникальное преимущество. Просто хотелось бы простую цифирь: цена железки, размер базы в гигах и строках, число транзакций. Чтоб поконкретнее поверить.
Старая???
Последняя версия вышла в этом году, следующая на подходе - чаще, однако, чем DB2, как мне кажется. Не старая - зрелая :)
Ну референсов вы на сайте IBM и сами надыбаете, как мне кажется, там и по размерам, и прочим делам,только по поводу цены не обольщайтесь. Такого понятия как прайс лист в мире Z можно сказать нету - цена считается под конкретный аппарат конкретного заказчика. Поэтому цен вы точно не узнаете.
Но главный принцип - платится за выполненную работу. Может быть организованно в прямом смысле слова - по сети отсылаются отчёты сколько времени потрачено каким софтом, и на основании этого выставляется платёж. То есть выключили на ночь сервер - нифига не платите.
Да, если захотите, и проявите намерения, то вас могут свозить, к примеру, в Credit Susse, на посмотреть.
Только как я уже говорил, россиян это практически не касается - н зачем в России такой софт?
Какие задачи решть?
Ни одна финансово-учётная система из разработанных под IMS не может провести проводку задним числом с пересчётом остатков. Более того, они считаю, что это криминал. Ну тупые...

iv_an_ru,

хорошо, попробую, но быстро не обещаю, и наводящие вопросы могут быть.
Только вот про ссылки-указатели вы так и не вчитались.
IMS не работает с множествами, в принципе, и даже не перемножает их.
Но если запись об объекте ROUTE имеет связаную запись объекта SP_OUT - то в первом будет прямой указатель на адрес последнего.
То есть на выходе в IMS будет процедурка, которая позволяет перебрать сегменты, у которых в поле DWG значение 1234
Но давайте тогда попробуем этот пример, чем разбирать - что такое есть за модель данных в IMS. Если нет возражений у остальных читателей.
всё больше интересно. Я просто сейчас убегаю, ближе к ночи займусь.