хорошая статья. разрешите добавить свои впечатления о 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.

Чего-то я не понял проблем с урлами, во что они превратились, поэтому я их открытым текстом
http://www.opennet.ru/opennews/art.shtml?num=27041
http://www.osp.ru/news/2010/0621/13002689/

Оценить - хорошо это или плохо - я не берусь.
У меня вообще к Eclipse настороженно-неприязненное отношение.
Ну так речь и не о домашнем кодере, всё-таки, а о рабочем месте для программиста корпорации.

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

Eclipse тем хорош, что его каждый второй знает. Это значит, что если корпоративный продукт будет похож на него, то людей можно будет готовить быстро.
Однако (опять же) основное - не единая оболочка. Меня больше тревожит эффективность среды исполнения на мейнфрейме. Если EGL будет работать на мейнфрейме так же медленно, как Java, то революции не будет(((.

Ээээ, "прошу пардону"!!!
Это же никакой не байткод!
Это же честная трансляция в COBOL ли, в Java ли...
Я выбыраю в COBOL
Ну да, по опыту VaGen можно сказать, что в транслированном коде без стаканА не разберёшся - куча определений, переопределений...
Вещь то с претензией на универсальность.
Но потом транслированный COBOLьный код честно компилируется, ну и куда он там - в CICS, IMS TM, просто в z/OS модулем, это уже как вам системный программер настроил - деплоится.
Допускаю, что можно и более эффективный COBOLьный код написать, чем тот, что транслируется с EGL.
Но не считаю это возможным сравнивать с Java.

ААААААА!!!! Кобол.... Ну даже в человеком написанном Коболе хреново разбираться, там гектары текстовой информации, отсутствие вменяемых объектов и вообще. А когда Кобол нагенерен VaGen, то да, смерть, не разберешься вообще. Вот я бы лучше эффективный run-time для Java на мейнфрейме сделал. Чтобы и многоплатформенно, и эффективно. Но это хотелка.

???
Мы какой-то разный COBOL видели...
В моём COBOL комментарии не нужны - код читается на раз...
Объекты? В COBOL? А напуркуа?
Ну ладно - Object COBOL от IBM...
Но это редкая форма извращения...
Индустрия не смогла ещё процедурное программирование освоить...
А что в объектном творят...
Не, ну идея конечно пятибальная.
Классная идея.
Для некоторых задач - самое оно.
Но для тех задач, для которых COBOL создавался - спорим на кружку пива - его ничем не заменить.
Никаком ООП любого языка.
Кстати, в спецификации на язык заложили требование - хюман читаемость. Потому как была патовая ситуация.
Сидят кодеры, чего-то кодят, ни один финансист не может понять чего. Учитывая, что на нём кодили всё-таки не автоматизацию пивных ларьков...
COBOL был призван исправить эту ситуацию.
И это удалось на сто пудов.
Я не о том, что все финансисты кинулись читать кобольный исходный код.
Ага - щаз....
Но англоговорящий человек из текста кобола получит информации гораздо больше, чем из Java со всей её наследованием, полиморфизмом, и прочими радостями, призванными запутать понимание происходящего.
Я проводил эксперимент.
Давал тект кобольной программы, и ни разу небыло затруднений в понимании сути происходящего в ней.
Так что кобол просто незаменим - для своего класса задач.
А под идеологию IBM он ложится прекрасно. Для создания относительно небольших модулей, из которых строятся транзакции CICS или IMS, из которых собираются технологические процессы, и в конце концов бизнес процессы.
Doom на нём написать, наверное, будет проблемно.
А систему расчёта ипотечных платежей - на раз.
Кстати, функция расчёта аннуитентного платежа - в спецификации языка.
Так что кесарю - кесарево, а слесарю - слесарево.
Да, язык избыточен.
Программа состоит из глав, главы состоят из параграфов, параграфы состоят из предложений, предложения состоят из подлежащего и сказуемого и оканчиваются точкой.
Охрененно сложный язык
Вот его избыточность как раз и служит его понимаемости.
Мне очень нравится красота и мощь С - первая любовь, чего уж там...
Но - Платон мне друг, но истина дороже.
Я не коболист.
И не IMS-ник.
Я вообще случайно забрёл - чистая правда.
Поэтому мне, как постороннему и не ангажированному человеку, не находящегося под гнётом прошлого опыта и авторитетов - мне таки виднее.
"Я так думаю" (с) Тофик Мктрчан.
Я всякого слышал про кобол - меня трудно удивить негативным к нему отношением.
Я, пытаясь сделать там фигню мелкую, задавал вопрос коболистам - ну как? как это можно реализовать?
Там вопрос с указателями был, если надо, могу потом пояснить. Так вот они мне показали, как можно, но сказали, что вообщето у тебя проблемы с головой, тебе бы (мне то есть) психологию изменить, под эту платформу по-другому надо, это не unix, у неё есть особенности, можно гораздо красивше, проще, и главное (!) более мелкими и реюзабельными модулями.
Я подумал - и согласился.
Не, на Сях тоже можно было бы разбить, на такие же модули при желании, но выгод это бы не дало, а тормоза бы дало. В целом решение на COBOL было более эффективно с точки зрения расходования памяти, но более грузило подсистему I/O, а с этим на платформе - полный порядок, и слава Б-гу. А излишнее расходование памяти всёравно грозило бы I/O в виде swapping.
Да кто нафиг сейчас эту память считает...
Да?
А ведь считают...
Если пивной ларёк автоматизировать - то оно может и не надо, один хер сервак ночью выключен будет, то, да сё.
А если национальную платёжную систему?
Я вот, глядя на индустрию со стороны, не стал бы так на COBOL...
Ничем не лучше эффективный Java runtime.
У них назначение разное.
К сожалению - таки да, если раньше обходились меньшим количеством платформ и языков, то теперь их больше. Но они не меняют друг друга.
Ну не заменил unix mainfraim-ы.
А windows не заменил unix.
А linux не заменил windows.
Как бы об этом не кричали.
У всего своя ниша.
Не знаю, может, немного сумбурно.
Но ассемблер тоже никуда не делся.
Хоть многие уже и не знают, что это

Совсем забыл - ELG с трансляция в COBOL не предназначены для последующей работы с оттранслированным текстом.
Ну не основной это способ работы.
Хоть технически и возможный.
Трансляцию в Java никто не отменял, опять же.
Отсюда напрашивается очередной интересный эксперимент.
Написать на EGL функционал, ну что-нибудь, с доступом к данным, ну можно придумать, и оттранслировать и в COBOL, и в Java.
И дать людям глануть и сказать, что происходит.
Людям, не знакомым ни с COBOL, ни с Java.
Где только последних взять???

Это да, не испорченные программизмом мозги воспринимают прямолинейную логику COBOLа легко и непринужденно - у меня один старый заказчик уверенно работает на русифицированном COBOLe до сих пор. Но как-то не поворачивается язык назвать его универсальным. Вот в древние времена был у IBM бизнес-язык COBOL, универсальный PL/1, машинный Assembler, символьно-скриптовый интерпретатор REXX, и системный PLX. Все было на своих местах. Сейчас произошло вымывание одних языков другими, попытка втащить на платформу С и Java, которые не лучше того, что было, но намного более распространенное...Эх, про это много можно говорить. Но сейчас "имеем то, что имеем!" (с) Кучма. Поэтому да, связка EGL-COBOL-DL/1 может быть интересной, только если средства разработки доведены до коммерческой кондиции, дружелюбны и им обучают студентов, а не вламывают в готового специалиста.
Вот посмотрим, когда хоть один IMS проект появится. И как для него (вернее, на чем!) будут писать программы.

В интересное время живем, товарищи!

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

Да, с Коболом у меня любви не вышло. По причине того, что не писал бизнес-логики никогда. А как системный инженер количество букв меня угнетало в Кобольных программах. То ли дело в Ассемблере))) Так всю жизнь - Rexx-PL-Fortran-Assembler, видимо, от этого ношу в себе кучу кобольных предрассудков.

PLX PLI никуда не делись, даже HLASM никуда не делся.
Разработка ведётся на всех, включая COBOL.
Новые языки само собой отвоевали пространство, вернее - привнесли новое пространство. Я бы не сказал, что ниша старых сократилась - просто появились новые.

Ну а нелюбовь системного программиста к COBOL понятна
Каждому - свой инструмент.
Дай человеку молоток - и всё вокруг для него станет казатся гвоздями

Я к чему.
Коллега пробовал, с помошью зарубежных братьев по разуму, использовать RDz, для показа, не для работы.
Таки да, настроить всё - та ещё задача.
И если ради себя любимого, да для того, чтобы чего-то там по-кодить, проверить - то не стоит.
Легче в терминале.
Надо таки иметь системного администратора и системного программиста под рукой, ежели сам знаниями не владеешь.
Но настроенное однажды окружение тиражируется на сколько угодно рабочих мест разработчиков.
То есть, для организации, имеющей Z и профильных специалистов - настроят.
И дадут рабочие места кодерам, которым уже знания целевой среды не нужны, если они, конечно, не кодят на HLASM из-под RDz, что тоже не возбраняется

Документ в целом готов.
И передан группе людей на вычитку.
В том числе и akost.
Если он решит, что уже готов, и сообщит, то...
Разместим на широкий обзор.
А пока, елси кто хочет - могу индивидуально
Это, если кто забыл, про централизацию, платформы для неё, и IMS, и много чего.
29 страниц.
Кучу всего пришлось перелопатить.
Кстати, по CICS накопал такого... Что был в шоке.

Документ версии 1.2 получил, взял читать. Скажу, что думаю по данному поводу на следующей неделе, ибо большую часть этой недели буду вне Москвы, в поездке.