Мне кажется, что основная ценность фрейма должна быть в меньших затратах на единицу работы (например, проводку платежа). Тогда это обеспечит окупаемость оборудования через обозримый промежуток времени. Это достигается высокой специализацией приложений. Для организации это означает, что она инвестирует в специалистов, делая их сверхлояльными, но экономит на постоянных закупках дополнительного оборудования для обеспечения шевеления мультиплатформенного говнокода.

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

А кто и когда скажет клиентам о высоком "пороге вхождения" в платформу, куда входят и необходимость выложить сразу много денег за железо, трудности в поиске этих вот сверхлояльных специалистов и так далее?
Я думаю, что высокий порог, проблема со специалистами и сервисом, наряду с объективными трудностями с разработкой и есть то, куда надо смотреть IBM-овским менеджерам, а не мотивировать продавцов на жонглирование словами.

Для серверов System z компании IBM хорошо бы четко сформулировать позицию под какие задачи они нынче "заточены". Нынешнее продвижение ИМХО гласит "для всего", что очень далеко от действительности.
При этом, например, Java-нагрузка на z-сервера, по разным ощущениям и впечатлениям, является достаточно дорогой и никаких специальных преимуществ от платформы не получает.
Про "уровень вхождения" и требуемый персонал для обслуживания/развития вопрос часто "обходится". В наших реалиях z-специалисты достаточно редки, что вносит дополнительные риски при внедрении.
Так что задача N2 - увеличить количество специалистов.
Задача N3, мы это обсуждали на IMS-семинаре, сделать средства разработки для z-платформы бесплатными, включая эмулятор zPDT.
Да, пусть эти средства разработки будут без тех.поддержки (т.е. тех.поддержка на них будет платной), но это даст возможность разрабатывать софт для платформы энтузиастам и небольшим компаниям.
Что (ИМХО) будет способствовать росту популярности платформы.

Дополнительно надо как-то объяснять разработчикам/конечным пользователям, что высокая производительность кода и высокая универсальность кода вещи плохо совместимые. Пишем производительный код - значит закладываемся на определенную платформу/набор ПО и выжимаем из этого решения все, что возможно. Попытки написать код с N-уровнями абстракции и поддержкой нескольких платформ/СУБД оборачивается весьма избыточным потреблением ресурсов. И тут опять же нужно популяризовать, что System z может обеспечить нужный уровень надежности и отзывчивости для специализированного кода. И вот тут вполне уместно сравнение с другими платформами/ПО. На конкретных задачах и конкретном оптимизированном коде. Можно даже межплатформенные соревнования устраивать. Тут и энтузиасты пригодятся.
Правда опыт показывает, что оптимизация кода приложений не выгодна продавцу техники, т.к. новую технику сложно будет продавать, а это ущерб бизнесу.

Сама нынешняя модель продаж (чаще и больше) противоречит концепции System z (купили один раз и эксплуатируем много лет) и от этого ноги проблем и растут.

Прошу прощения за сумбурное изложение.

да и статья сумбурненькая, нечего извиняться
я согласен в том, что лучше отказаться от модели продвижения, где сравниваются затраты на некую типовую, перемещаемую между платформами, транзакцию.
да, я согласен, что нужно четко говорить о 1) эффективности, тогда забыть о переносимости рабочей нагрузки. программы и системы проектировать именно для платформы z 2) обязательно надо говорить о цене вхождения на платформу и ее ограничениях (типа инфраструктура, специалисты и проч) 3) надо говорить об особенностях платформы, типа коллективного характера использования, консервативного и инвестиционного характера вложений и т.д.
а вместо этого нам предлагают если не ложь, то специально подготовленный вариант правды с тщательно подобранными примерами.
продавцы, что тут сказать.

Жень, я не совсем согласен по поводу zPDT. Он платный потому что он на поддержке со всеми патчами, PMR и т.д. Даже если глянуть на бесплатные средства разработки под другие платформы, то часто сервис обеспечивается не самой компанией, а комьюнити вокруг какой-либо конкретной технологии. Поэтому пусть zPDT будет платный.
Тем более, что бесплатная альтернатива в лице Hercules есть и ее (тьфу-тьфу-тьфу) никто пока не убивает. Тут скорее вопрос к нашему комьюнити почему мы не написали гайд фор dummies по разворачиванию геркулеса, чтобы любой студент мог нагуглить и попробовать.

Я скорее сторонник наличия двух вариантов, платного и бесплатного.
Т.е. для энтузиастов - релиз, обновляемый, например, раз в год, без
поддержки. Из разряда поставил - работает. Возможно, без части фич, и
ограниченный по мощности. Но, легально разрешающий работу с z/OS, z/VM и
т.п. для некоммерческого или индивидуального использования. Ближайший
аналог - это например DB2 Express-C, или Fedora.

Для более конкретной отладки, групповой разработки, получения патчей и поддержки - платная лицензия и поддержка.

Да, Геркулес есть, мануал я таки напишу (запланировано несколько дней
летом), но он не имеет легального статуса с т.з. IBM. И выложить можно
только конфиги к нему. Добывание дистрибутива ОС и конфигурирование "под
Геркулес" - личная забота каждого. Т.е. я, например, не могу выложить
геркулес вместе с комплектом z/OS и настроенными агентами RDz, чтобы
заинтересованный энтузиаст смог начать разработку, не вникая в тонкости
администрирования системы.

Альтернативой бесплатному zPDT может служить доступ для разработчиков в некое "облако", доступное из RDz, но это, по моему, требует больше затрат на сопровождение, нежели версия zPDT без поддержки.

извиняюсь, что встреваю) есть лицензионно чистый "turnkey MVS" на основе доработанного MVS 3.8; а если приложить некоторые усилия, то найти образы OS/390, а возможно и z/OS, на торрентах вполне реально. Так что было бы желание... Распространять ворованное, конечно же, противозаконно, а вот выложить руководство по использованию сворованного вроде вполне законно)))

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

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


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

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

Дык самая конкурентноспособная и самая корпоративная платформа - это Microsoft.
по совокупности параметров.
При чём те, которые ты привёл, эти как раз прекрасно могут играть на стороне ИМС, кроме стоимости утилизации
Просто об этом мало кто знает.
Проблема.

Гриша, все, что я привел, прекрасно могут сыграть на стороне мейнфреймов и IMS. Но надо 1) правильно формулировать и ставить акценты 2) анализировать те места, где просадка, и устранять эти просадки. Например, позиционирование и работа со сверхлояльными кадрами.

В общем, ты правильно заметил: меня статья зацепила топорным уровнем аргументирования. Они вообще не в ту степь идут.

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

Рынку не нужны картинки IMS+DB2 = Win. Эти продукты не решают ни одну бизнес задачу предприятия. После их установки необходимо еще долго писать ПО по обработке данных(привет вопросу где эти люди, которые это сделают). Заказчики хотят быстро и предсказуемо получить результат. Тот же SAP намного ближе к сердцу в силу наличия готовых приложений и заготовок, но ведь никто его не запускает на мейнфрейме. (хотя технически это было сделано) Много приложений есть на Java. Есть не громогласное доказательство, что Java работает быстрее на мейнфрейме?
Можно прикрываться словами "говнокод" и "граммотность", но реалии рынка таковы - необходима платформа запускающая любой готовый говнокод быстро и удобно. Платформа позволяющая нанимать студентов без длительной фазы обучения(Университетских курсов повсеместно тоже нет).
Второй путь это написать на IMS и тд набор универсальных приложений типа 1С для быстрого развертывания на предприятиях. Развернул за месяц, доказал реально выгоду - продал. Но IBM сама ничего не делает и другим не дает (см порог вхождения для новичков и разработчиков)
Вот когда появится возможность запустить любое Сишное приложение в мейнфрейме и получить в два раза больше скорость, без оговорок, что надо 10 тыр подключений и сотни потоков, вот тогда и поговорим про конкурентно-способность.

Если рынку надо только "платформа запускающая любой готовый говнокод быстро и удобно. Платформа позволяющая нанимать студентов без длительной фазы обучения", то тогда зачем вообще покупать или продолжать эксплуатировать мейнфрейм. Кластер на линуксе или винде и фигли думать.
Мне кажется таргетный рынок мейнфреймов еще просто не понял до конца, что такое TCO. ИТ бюджеты слишком раздуты, чтобы обращать внимание на качество кода. А в той же Канаде например вполне нормально увидеть ЖД-компанию, которая откажется от сдачи в эксплуатацию shared queue, потому что это на 10% повышает стоимость одной транзакции. И добивайся high availability другими средствами.

так а все так и делают - запускают линуксы. Мейнфрейм это больше legacy. Кому повезло 40 лет назад - тот и в дамках. Но, все не так и плохо. Текущий рынок в деньгах больше чем "3rd platform" даже через обозримые 3 года. Интервал между выпусками MF железа сокращается. Рынок заставляет наращивать скорость MF быстрее, просто IBM хочет свой кусок с каждых добавленных 20%. Наверно и график где-то есть, что они 5ти летний план за 3 года сделали.

есть банковские фреймворки на IMS.

Любой *код - быстро и удобно, это не про System z. Это больше, наверное, про System x и System p. И, как правило, этот замечательный код не рассчитан на масштабирование, свыше определенного уровня, без частичного или полного рефакторинга.

Насчет произвольного кода С/C++ - тоже не совсем согласен. Если сервер рассчитан на массовое параллельное обслуживание - то он на нем и будет давать выйгрыш по производительности. Для сравнения, супер-ЭВМ будет весьма бледно выглядеть при расчетах в 1-2 потока, которые невозможно распараллелить.

Насчет готовых приложений - согласен, наличие готовых решений "под ключ" для российского рынка могло бы дать свой эффект.
Фантазия: "Облачный" провайдер, предоставляющий сервис аналогичный ПО "1С", реализованный на платформе System z, и, обслуживающий 100500 предприятий малого/среднего бизнеса.

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

абсолютно не маргинальная у тебя точка зрения.
конкурентноспособным предприятие делает целый комплекс мер, в основном управленческих, а не применение даже супер-пупер ПО, или отсутствие такового.
мне посчастливилось видеть, как работает кризисная бригада на предприятии, и как настраиваются бизнес-процессы. так вот, на каждом этапе управления или в основе цепочки может лежать даже попсовое ПО или вообще бумажки. важно, как когда и что делают с этой информацией.
так что главное - не уровень крутизны ПО, а умение им пользоваться и соответствие предъявляемым требованиям (при условии адекватности этих требований).
вдогонку: я уже высказывался о ценности ИТ тут - http://akostyrko.blogspot.ru/2011/09/blog-post_11.html

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

Тем не менее поскольку я несколько раз участвовал в подобных битвах и считал совокупную стоимость владения, я все же немного подискутирую:

1) лицензирование и скидки...
Лицензии на софт и поддержку - основа любого подсчета совокупной стоимости владения. Это реально дорого и если бы всем подряд раздавались скидки 90%, то, производители ПО уже бы разорились. Уверяю, это сильно не так. При этом непонятно почему мейнфрейм не будет диконтирован, раз пошла такая битва. Существует достаточное количество инструментов для этого. Все зависит от ситуации. 

И да, наверное очевидно, но все же... Если вы не посчитаете стоимость владения на мейнфрейме и не покажете выгоду, то ни один производитель ПО не даст скидку 90% просто так, за объем. 

2) за мейнфреймы надо платить сразу всю цену, а за софт нет
Неправда. Многие партнеры готовы предоставить рассрочку, а если это принципиально, то и предоставить оборудование в лизинг. Более того, это не теория, а вполне отлаженная практика.

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

Большой рынок лизинговых предложений для относительно небольшого рынка флагманской топовой платформы выглядит как-то неуместно. Если есть какая-то реальная потребность, я всегда готов помочь. У нас все продажи в каком-то виде уникальны. Мейнфреймы - не поточный бизнес, каждый клиент уникален.

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

Большой рынок для топовой платформы - это да, неуместно. Как и полное отсутствие такого рынка. Мейнфреймы - это не компьютер "Ломоносов", существующий в единственном экземпляре. Это - серийное изделие. И наличие трех-пяти поставщиков лизинговых решений, согласитесь, для страны с парой десятков установок - это не чрезмерно, я думаю.
Есть ложь, есть наглая ложь, и статистика)))). Не будем о мировом опыте, это пусть тамошние об этом рассуждают в данном контексте.  Расскажете хоть об одном российском неунаследованном мейнфреймовском решении, где крутятся не Линуксы и не мобильные нагрузки, типа WAS?))) Мне правда интересно.
А если по существу, имею сказать следующее, о чем, кстати уже говорил. 
1) приведенные в статье аргументы - слабы, и в России не работают даже без вдумчивого анализа, не говоря уже о нем.
2) продажная концепция IBM в России, связанная с мейнфреймами, слаба, не учитывает особенностей рынка и сильных сторон платформы. 
3) техническая политика и политика позиционирования по существу нивелирует положительные качества платформы и ведет к ее деградации в среднесрочной перспективе.

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

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

Такие дела.

++++плюс-плюс-плюс.
покупают, потом имеют геммороя, потом начинают думать, как бы приложение из WAS на яву standalone, первый шажок, а потом - да пошли они лесом, эти фреймы!
как там сказал наш один общий знакомый - мэйнфрейм и его внедрение требует изменение инфрструктуры компании.
Хорошие слова!
Иначе куча проблем при сомнительной выгоде, в том смысле, что и без фрейма, в принципе, прокатило бы.

1) Я готов показать TCO, рассчитанное для одного большого коммерческого заказчика, который очень заботится о цене. Все там хорошо и достоверно. Прямо как в статье, которую я не смог прочитать, но наверняка она хорошая

2) Главная особенность российского рынка, которую надо учитывать - местные разработчики ПО. Ее за последние пару лет сильно учли. Более того во многих проектах именно разработчики ПО стали по факту поставщиками оборудования. Дальше будет лучше.

3) Техническая политика? Стратегическая? zBX, IDAA и прочие акселераторы помимо стандартного эволюционного развития? И почему это плохо?

Откуда такая информация про скидки на софт? Она уже мелькает второй раз и просто любопытно кто такую неправду рассказывает? Не слушайте больше этих людей, они вас обманывают

За последний год появилось два сильных на рынке интегратора, которые наращивают экспертизу по System z. Унаследованное ПО не приносит практически ни копейки вендору, а лишь серым поставщикам, ровно как и вторичный рынок (за очень редким исключением). И да, постоянно появляются новые заказчики. Если об этом не трубят во всех новостях, в силу того, что кто-то на стадии имплементации (у нас традиционно это медленно) или ведомство такое, то это не значит, что что-то там загибается Все хорошо

И да, почитайте свежий отчет IBM за второй квартал -- все опять упало, кроме System z. 11% YtY. Рано хороните.

Вот, обожаю конструктивную оппозицию. А можно статью с TCO нам в студию, в виде частного примера? Можно замазать слово IBM и наименование клиента, оно нам не надо))).

И про отечественных разработчиков - тоже интересно. Это ж в основном мигрированные приложения, верно? А нейтивные как? Система "Исток", АСРЗ и прочие программные комплексы - есть что-то подобное? Чота я давно не слышу такого. Можно примеры привести, хочется написать про отечественных разработчиков, прямо тут, на сайте. Первый готов о них поговорить, распросить, разрекламировать!

Про скидки на софт знаю не по разговорам. И считаю это правильным! Как и помощь вторичному и серому рынку. Потому что и то, и другое помогает платформе. А что хорошо для платформы, то хорошо и нам, это позволяет избежать сверхлояльности сотрудников.

А вот новый заказчик новому заказчику рознь, как вы понимаете)))

В общем, ждем фактуру. Она будет?

Да наверняка можно ТСО выложить готовое. Я в начале следующей недели выложу.

Так сложилось, что многие разработки по сути под одного заказчика, поэтому не оч публичные, хотя мне казалось, что в узких кругах все знают. Ну из тиражируемых - диасофт. Чем не разработчик? И почему db2 в z/os не native приложение? Или если не cics или ims, то не кошерно?

а вот передергивать не надо. диасофт написал Флекстерру на яве. так вот дб2 - это нейтивное приложение. но лазит к нему явовский горбыль по jdbc. флекстерра к нэйтив приложениям отношение имеет сильно опосредованное. скорее, просто никакого.
внимательнее, дружище, а то скомпроментируете идею.

Логика мне не совсем ясна. При чем тут java, jdbc и прочие вещи? Давайте их вообще в соседний линукс или не дай бог виндоус поставим. И через db2 connect пусть ходят. Стало нативнее или опять все неправильно?

действительно, давайте внесем ясность. я говорил о разработчиках приложений, спроектированных и написанный под мейнфрейм, а не портированных туда, да еще и на яве. именно такие приложения являются нэйтивными. а вы говорите о db2 и флекстерре.
да, дб2 - вполне нэйтивный. только к диасофту и к разработчикам прикладного софта не имеет отношения, это платформенный софт общего назначения, написанный IBM. а диасофт - не разработчик для мейнфрейма. это разработчик портируемого софта.
мне же интересны те, кто пишет для мейнфрейма, с учетом особенностей мейнфрейма. диасофту на мейнфрейм плевать, я разговаривал с их разработчиками на конференции в ЦБ, включая супер-пупер архитекторов. их позиция проста - мейнфрейм, не мейнфрейм, нам пофиг, мы будем там работать. нормальная позиции, только к продвижению и закреплению платформы отношения не имеющая. более того, в силу прожорливости явовского окружения и платы за портируемость в виде странных классов и неучета особенностей архитектуры приложения типа флекстерры легко пригробят мейнфрейм как идею.
так вот, повторяю то, что лично мне интересно. есть ли сейчас активные разработчики мейнфреймовского софта в России, которые это продают? то, что разработчики есть у самих заказчиков, я знаю - у самого сидит куча народа. а вот на продажу?

Есть несколько компаний, ориентированных на западный рынок. На российский рынок никто нового не пишет, на сколько я знаю, во всяком случае в тиражируемых промышленных масштабах. Есть проекты, где поверх переносимого приложения есть попытки приделать тот же cics ts, но это скорее исключение. Плюс есть проекты по адаптации западного нативного софта под российские задачи.

Ну я при этом не считаю, что это большая проблема. Как таковая db2 в z/os для нормального приложения - это вполне себе ничего. И то, что приложение кросс-платформенное тоже ничего. Если не будет этого - не будет роста мейнфреймов. Это будет основной движущей силой. Если вокруг этого будут появляться "правильные" решения, заточенные под z-архитектуру, хорошо. Я буду только рад. Но нет ни одной серьезной причины, чтобы это случилось.  Заказчики сами на это не пойдут.

Это не совсем правильно, в смысле вынесения приложений с z/os и оставление только базы. Мало того, что MVS, где первая буква от multiple, и предназначенной управлять тысячами адресных пространств, оставляют 4 (!).
Нарушаются важнейшие архитектурные принцыпы. Например, обрабатывать данные как можно ближе к месту хранения, иначе возрастают накладные расходы и задержки.
Возрастают трудности с обеспечением безопасности. Данные из одного контекста безопасности передаются совершенно в другой. Как сказал вот господин из ес-лизинг, для распределённой системы невозмож ее о построить модель угроз, модель нарушителяё и модель обеспечения безопасности.
И вот в здра в ом уме и трезвой памяти преллагать заказчику такое ухудшение свойств его системы и инфраструктуры?!

Ну а зачем нам базу одну запускать. Пусть будет их много и займут эти адресные пространства

1) Я конечно здесь представляю исключительно свое личное мнение, но все же надеюсь занимаю в этой уважаемой компании не последнее место и мое личное мнение чего-то стоит.

2) Концепция "просто обычный большой сервер" опять же уникальна для какой-то аудитории и какого-то профиля клиента. Если у тебя куча линуксовых/юниксовых серверов, то зачем пугать страшными уникальными вещами, когда есть "просто обычный большой сервер" с хорошей виртуализацией? Не надо усложнять где не надо, также как упрощать)

1) А при чём тут  занимаемое место? Цветовая дифференциация штанов и кудва раза? И какое это место, интересно?А кто занимает последнее место? А кто первое? А должен ли занимающий первое прислушиваться к мнению занимающего последнее? Вот, к примеру, когда мы идём в автосалон покупать автомобиль, то кмненю продавца салона, который ездит как обыватель, и ничего не смыслитв еэксплуатации и ремонте, не должно вообще кого-то интересовать. Вотличие от мнения независимого от автосалона механика.А право на личное мнение имеет каждый.Вот, к примеру, ни akonev, ни akost, ни nkv, ничего не пишут про своёместо. Но если я, к примеру, буду несогласен с akonev, то буду сильноподозревать, что я чего-то не знаю, какого то опыта мне не хватает. а akost, если ему верить, вообще мелкий писарчук ;)Вот с akost я очень части сильно не согласен и дискуссирую. К примеру,по использованию HLASM для прикладного программирования небыл согласен.Это потому, что akost ленивый, и не хотел на примере показать. Нонашёлся IBMer, который доходчиво смог показать, да  так, что не толькостуденты поняли, а даже я. О чём я публично и заявил, был не прав, HLASMвполне подходит для прикладного программирования на Z, более того, онпросто необходим в построении централизованных систем.Да и вообще, с точки зрения сложности разработки и сопровождения всеязыки делятся на системы с автоматической управлением памяти (ява, кпримеру) и с ручным управлением памятью (С и HLASM как поноценный аналогС на z/OS). Это кстати не я, а очень известный эксперт в областипрограммирования сказал. Здесь не вписывается уникальная концепцияCOBOL'а, как языка с отсутствием ручного управления памятью и отсутсвиемавтоматического (сборщика мусора). Да и EGL стоит особняком, про этоотдельно надо рассказывать, поскольку это уже есть основная тенденцияиндустрии, и должно стать основой предложения IBM, в виду рядауникальных свойств, как в плане простоты изучения и разработки, так и вплане применимости в эксплуатаци - целевая трансляция или в ява, или вCOBOL, в зависимости от нефункциональных требований.

Как много текста. Я всего лишь хотел сказать, что не понимаю кому конкретно в IBM.ru что-то говорить. Сам с собой поговорить что ли?

Ну это...)))) самому с собой бывает тож ничо так поговорить. Я тут на этом сайте раньше частенько сам с собой говорил, пока хоть скока народу не наприходило. Мысли в порядок приходят, и вообще полезно)))
а если по сути... такие вещи, как позиционирование, все чаще выбирают исходя из маркетинговых понятий, а не из четкого понимания инженерных ограничений. Все хотят быть Джобсами, который навязал свой подход инженерам и срубил на этом денег. А этот подход для промышленных и корпоративных систем губителен. Что хорошо работает на потребительских группах, может прибить корпоративные. Поезда продают не так, как автомобили...
Так что Гриша хоть и бывает радикален, но увы, часто прав куда более, чем частично.

Хочется больше человеческого общения. С самим собой и так слишком часто общаюсь

Так в чем маркетинговое позиционирование System z не совпадает с техническими возможностями? Мы сейчас опять кажется вернемся к теме, что просто DB2 в z/OS - это плохо, а вот разработанное на коболе и IMS - это единственное правильное, да?

Не, не не надо радикализма. У нас DB2 был, и проект совместный с IBM по консолидации, и я на своей шкуре знаю, как оно все на самом деле.
И IMS у нас нет, но это именно я говорил и говорю о паршивом позиционировании мейнфрейма. Приходите на посиделки, при случае, обсудим и этот вопрос тоже))).

Зовите. Я всегда за

Прежде всего с самим соб о й. Самому себе сказать - Dedicated to every customer succsess.
Что по-русски значит - не впаривать, а помогать заказчику решить его проблемы, строить и развивать инфраструктуру и приложения. И если заказчик будет доволен, то это обязательно будет сопровождаться многолетним сотрудничеством и продажами.

Звучит как вызов. У нас разве не так? Кто куда впаривает? Или если решение построено не на IMS, то это обязательно впаривание? Увы я пока не пойму о чем конкретно нужно мне с собой поговорить. Про обычный большой сервер я уже пояснил выше.

p.s. Какой-то непонятный пессимистичный настрой с чего бы?

2) Что делать, если у заказчика куча юниксовых серверов?Думать надо, однако. Концепция консолидации распределённых систем имеетместо быть. Но! Только как этап на пути к централизации!И это подтверждают даже сервисные инженеры IBM, которые десяток летруками занимались консолидацией распределёненных систем, и открытопишут, что концепция провалилась. Программные платформы, созданные в90-х годах, и ориентированые на эксплуатацию на выделенном для системысервере, имею врождённую не-эффективность, на уровне 5-10 %, в видеизбыточного потребления аппаратных ресурсов.Прикидываем - консолидируем, к примеру, 80 распределённых систем на однумашину, берём коэффициент не-эффективности по миниму 5%, в итоге целевоерешение обладает 80*5=400% не-эффективности.Круто, да? Что кстати, и подтверждается практикой.Это как если 1С натянуть на 100 фреймовских процов, к примеру, толку ведь не будет, пусть уж оно на распределёнке, правда, liks?Вот и приходится слышать от компании интегратора и разработчикаобвинения IBM в фальсификации нагрузочного тестирования перенесённого слинукса приложения на вебсфере + дб2, в вебсферу и дб2 на z/OS.С трудом верится в такое, но судя по тому, что сам разработчик, а уж темболее заказчик, не собираются ставить систему даже в опытнуюэксплуатацию...А всё дело в том, что думать надо, работать.Выяснять в чём проблемы текущей системы, какая у компании стратегия,чего она хочет достичь, с кем она конкурирует, какие мировые образцыэффективности в этой отрасли.Централизация систем, в противовес консолидации или централизацииуправления распределёнными системами, требует изменения концепциипостроения системы. Нельзя взять просто региональную систему имасштабировать её до уровня страны. Кстати, даже для DB2 на z/OS этосправедливо - перерасход ресурсов будет как минимум на порядок больше,чем мог бы быть при тщательном проектировании, а скорее всегоЮ дажебольше, чем на порядок, вот у упомянутого выше разработчика так начетыре порядка, нехило, да? Кстати, это не уникальный российский опыт,зарубежный опыт крупных финансовых компаний показывает то же самое.Порядок - это много или мало?В построении централизованных систем надо вычленить ключевое, missioncritical место, от успеха решения которого будет зависить успех всегопроекта, всей компании. И вот в реализации этого критичного места естьместо в том числе и HLASM , хотя IBM предлагает решение EGL, иконкуренты тоже предлагают сравнимые платформы.А сама ДБ2 для Z обладает присущими всем реляционкам проблемами.Кстати простой пример, расчёт льготного стажа в виде выслуги,  на, к примеру, платформе IMS TM +IMS DB и кобола, мало того, что получается более эффективно, в этом тоникто не сомневается, надеюсь, но что интересно, получается куда какболее понятно и лучше читаемо, чем решение на SQL.Потому как наложение JOIN'ов на GROUP BY даёт нечто великолепное в планепонимаемости :)Уж промолчим про выполняемость этого оптимизатором :)Даже если ту же 1С вдруг перенести на DB2/Z, толку не будет.Опять же, из истории мы знаем, что ИБМ первой сделала реляционную базу, и использовала её в исследовательских целях. Имея уже высокоэффективную базу, ИБМ даже представить не могла, что это г... кому томожно продать...Да, не те тогда продавцы были, что ныне... А тут вдруг оракл своё г... стал продавать, и ИБМ пришлось догонять. И пришёл вкус - оказалось, продажа не очень эффективных систем тоже может быть выгодна, она приводит к продажее бОльших серверов. Так родилась известная поговорка - DB2 sells hardware. И родилась она внутри ИБМ. А IMS ИБМ хотела, было, ликвидировать, так заказчики не дали. так что сама по себ ДБ2 ничем принципиально не отличается.С CICS тоже интересно, будучи реализацией концепта multithread proramming, он обладает всеми присущими этому концепту недостатками, в виде накладных расходов, низкой изоляции, повышенной сложности, повышенными требованиями к программированию, и даже надёжность ниже, и всё это по сравнению с однопоточным концептом. Просто обычно ныне КИКС используется вместе с ДБ2, и на фоне проблем дб2 проблемы самого кикса уходят на второй план.Это как при использовании вебсферы  с дб2, на фоне проблем сферы проблемы дб2 уходят на второй план. А вот при использовании КИКС с ДБ1, то есть IMS DB, уже вовсю начинают напрягать проблемы кикса. Вот и получается, что для z/OS самая эффективная (отношение количечтва выполненной работы по отношению к затраченным ресурсам) есть IMS, и среда исполнения бизнес логики, и база. И уж кто-кто, а ИБМ это знает прекрасно, кто сомневается, тому могу персонально на пальцах...

Мне кажется твой пост проплачен ims

А если серьезно, то я не пойму с чем ты споришь. С формулировкой "большой мощный сервер"? Я же уже объяснил пример к чему она применима. Нельзя построить кейс по консолидации на мейнфрейме? Никогда-никогда? Это неправда. А если можно, но у некоторых бывают проблемы, так на то они и проблемы, чтоб решать)))

Это в вашем мире всё продаётся и покупается. Чувствуется по применяемой фразеологии продавец. А уже проводились сравнительнфе нагрузочные испытания, при чём и дб1 и дб2 настраиваоись специалистами лабы дб2. Но специально для тебя можно сделать ещё. А проще спроси в лабе дб2 - хочу устроить сравнительные нагрузочные испытания, и выложи сюда ответ. Кратко он будет таким - забудь и даже не думай.
Нагрузрчные испытания ИМС публчно доступны, а где для  DB2/Z? 
Вообщето технарю достаточно выяснить устройство одного прод у кта и другого, чтобы сделать вывод о позиционировании и сферах применимости. Конечно, у дб2 есть сильная сторона - это универсализм. На ней можно построить и оперативную систему, и аналитическую. Но как любой универсальный инструмент она будет проигрывать в эффективности набору специализированных. А с приобретением netteza ситуация вообще становится интересной, ведь это ее просто ускоритель к дб2, это полноценная самостоятельная платформа построения аналитических систеи, хрвнилищ и витрин, то есть специализмрованная база. Вот и получается, что вполне можно иметь связ к у имс и неттеза, для оперативных систем и аналитики, и в совокупности это будет куда как эффективнее, чем на дб2, котора может делать всё, но хреновинько.
И зачем тогда на ырейме дб2?
Да чисто теорети я к ски можно представить случай чистой консолидации. Но как правило это будет этап к централиза й ии. Консолидация высоконагруженных систем в один бокс экономически не очень выгодна. Особенно грустно, когда консолидируются системы, в составе которых есть функционал, уже предоставляемый подсистемой z/os. Например, системы со значительной долей пакетной нагрузки.
Или с развитыми требованиями к аудиту.
В таких случаях исплльзование фрейма могло бы быть куда как эффективнее.
Я могу представить условия, при которых консолидаци при централизации управления была бы выгодна, но не в один бокс, а в один датацентр. Но на этом поле полно игроков, и предложения ибм будет неуникально, и не факт, что лучше, по всей совокупности. И тут мы приходим к метолике/уловкам - ниже

У меня 10 лет хорошего технического бэкграунда, поэтому не надо оскорблений

Я не понимаю религиозности битвы DB2 и IMS. Зачем нужны бенчмарки - любой разумный человек и так догадается, что для определенных задач IMS будет заметно быстрее. Увы, весь мир идет в сторону простоты и универсальности и навязывать свое видение всему миру - не очень правильная стратегия. Про IMS надо говорить с заказчиком, но без фанатизма. Нравится идея - ради бога, реализовывайте. Не нравится, не надо убиваться и винить всех вокруг...

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

Расскажи об этом тем заказчикам, которые уже выполнили успешные проекты по консолидации. Расскажи им, что они не существуют

Решать можно не только продажей доп мощностей. Мы еще по-моему никому не отказывали в тюнинге системы, даже если это не входит в наши прямые обязанности.

А вопрос TCO - это у всех вендоров вопрос уловок и ухищрений. Ведь что такое по своей сути TCO? Подсчёт некоторых выбранных параметро, и оценка их по каким-то критериям. А другой ведор выберет другие параметры, или другие критерии.... А если и заставить их выбрать одинаковые, то у заказчиков могут быть свои приоритеты по отношению к этим параметрам и критериям.В условиях российских заказчиков, где в подавляющем большинстверегиональные системы и системы отдельных департаментов есть искусственноразорваный функционал одной логической системы, и в плане грядущейконкуренции с лучшими образцами западных систем, высоко централизованных,единственный выход оставаться на плаву и успешно конкурировать, этосрочно начинать централизацию, приближать вычисления к данным, надкоторыми они проводятся, повышать эффективность.Ибо в условиях, когда конкурент закрывает опер день за минуту, а у наслучшие компании гордятся, если уложатся в меньше, чем 6 часов... Или 4часа? А не одинаково ли, по сравнению с минутой?А TCO подсчитанный для двух разных компаний в одной и той же индустрииможет быть абсолютно разный, да ещё если разные вендоры начнут считать.

Не уловок, а методологии

Уловки ли, методология ли, но с у ть одна - вендоры навязывают заказчику свои уловки, пардон, методологию, вместо того, чтобы взять методологию заказчика, или помочь ему пазработать его методологию.
А то от какого вендора метолику не возьми, так у кажлого из них TCO  лцчше, а так не бывает. Даже оракл вот с микрофокусом дают тсо переноса нагрузки с мэйнфрейма, а на деле оказывается, что чпсть просто не компилитс! А то, что компилиться, падает при исполнении, но тсо просто прекрасный!

Мне кажется ты заказчика видел в каких-то фильмах. Пришли мне названия, я тоже посмотрю

Я не встречал пока еще ни одного заказчика, у которого была бы готова методология подсчета совокупной стоимости владения. Более того, заказчики сами просят ее рассчитать с учетом тех данных, которые они в состоянии предоставить. И рассчитывается она плохо в первую очередь не из-за уловок, а из-за того, что заказчик не может сказать вещи вроде стоимости минуты простоя. Преимущество конкретного вендора/интегратора при рассчете не в применении уловок, а в том, что можно заранее корректировать скидки, не дожидаясь пока тебе сказали, что ты слишком дорог и тебя уже нет в проекте. Это уловка? Ну отчасти может быть...

Кхм... можно я вклинюсь? я не знаю, как там другие заказчики, их же у вас много. но мы свою TCO считаем сами. Так что минимум одного вы уже знаете))).

Любые исключения лишь подтверждают правило
Но это похвально. Редкость в наши дни.

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

Ладно, дискуссия уходит в непродуктивное русло, пошли не аргументы, а...
Ну попробую последний раз изложить аргументацию.
Всё, что будет ниже, легко технически проверяемо, особенно если есть доступ к мощностям, как заявлено, и легко выясняется при умении слушать. Заказчика.
С чем соглашусь сразу и безоговорочно - с тем, что наши заказчики, здесь, у нас, сами не знают своих требований, зачастую.
Факт, многие, и действительно хотят, чтобы им составили методику, выбрали параметры и критерии.
Но не на примере агиток главпура, а на примере обследования их компании.
А вот здесь начинаются расхождения, ну-тес, приступим, и, пожалуй, после изложения этих банальных аргументов в очередной раз, я и закончу непродуктивные дискуссии.

Консолидация.
Множества юникс-линукс систем в одну машину.  На z/VM.
Основана на принципе добровольного освобождения сосуществующими на одной машине системами процессоров. Но консолидируемые ныне комплексы этого не делают. Ранее я это уже писал, это факт, констатируемый сервисными инженерами ИБМ. А уж кто-кто, но они как раз и "решатели" проблем и "настраиватели" систем.
А со всеобщей тенденцией индустрии к самонастраиваемости и самообслуживаемости систем ситуация будет только ухудшаться.
И это на фоне быстрого развития средств централизованного управления массивами блейдов. И в реальной действительности проектов по консолидации на блейды больше, чем на мейнфреймы.
Изначально IBM выступила с идеей консолидации в z/VM для второстепенных систем, не core systems, которые и так в мэнйфрейме. Кто же виновать, что у нас core systems реализованы в распределённых системах. И что местный IBM, начитавшись зарубежных агиток, и не вникнув в суть вещей, предлагает консолидацию высоконагруженных core systems региональных систем и департаментов. А это - не работает. И даже нагрузочное тестирование местного IBM это подтверждает, если верить компании разработчику предлагаемой к консолидации системы.
И всё это в высоко конкурентной области, где любое изменение лицензионной политики конкурентов приведёт к мгновенному изменению экономической обоснованности. А лиценезионные политики изменять гораздо проще и быстрее, чем технологии. И здесь мейнфрейм не представляет ничего уникального на рынке.
Как вариант - консолидация в LPAR на ождной машине. Но это совсем другое, тут будет конкуренция даже с Пэшками. А два ящика или один или даже четыре - не принципиально.
Принципиально мейнфрейм тут ничего не даёт. Чуть лучше, чуть хуже - не суть, лицензионная политика правит бал в этой сфере.
Проверить легко - взять 82 региональные системы, и консолидировать. Думаю, при успешных результатах заказчики будут драться за место в очереди на такую консолидацию.

COBOL.
Занимает выдающееся место в индустрии.
Ещё раз, все языки делятся на две основные группы, не по синтаксису, а по системам работы с памятью, как основополагающему водоразделу, определяющим нефункциональные особенности платформ, эффективность, разработки и исполнения.
1) С автоматическим управлением памятью (ну, как сборщики мусора, например).
    Преимущества - высокая эффективность работы разработчика
    Недостатки     - низкая эффективность исполнения
2) С ручным управлением памятью
    Преимущества - высокая эффективность исполнения
    Недостатки     - низкая эффективность работы разработчика
COBOL не входит ни в одну, ни в другую группу, является средой работы со статичной памятью. Жаль, я не специалист, затрудняюсь сформулировать.
Имеет очень высокую эффективность разработки и исполнения.
Современный компилятор кобола от IBM - это реально выдающееся достижение.  Сам синтаксис языка довольно сложен для создания компиляторов.
Большинство широко известных критических высказываний о COBOL имеют возрасть в несколько десятилетий, относятся к очень древним системам, к "легаси" в полном смысле.
Современный COBOL очень современен:) и как нельзя лучше подходит для создания современных, новых, систем.
Да, исполнение программ платное в среде z/OS, но выгод от его использования гораздо больше, чем затрат на лицензии.
Проверить - взять ключевые места системы, реализовать на COBOL, сравнить с реализацией на Java под WAS, и подсчитать. Там есть чего подсчитать, особенно если это будет приложение COBOL + IMS, разница будет больше четырёх порядков факт, в затрачиваемых ресурсах. А кроме ресурсов есть управляемость, надёжность, и куча других факторов.
Ну и, раз уж затронули IMS, то переходим к

SQL
"SQL" не равно "простота". "Универсальность" - да, "простота" - нет.
    "select ct.pricelist_id, setup_charge, min_charge_period, charge_increment_period, charge,
    prefix, ts.time_spec_id, holiday_date, dp.dest_id
    from root.contract ct join root.pricelist_timesubpricelist ptsp on ct.pricelist_id=ptsp.pricelist_id
    join root.time_subpricelist tsp on ptsp.time_subpricelist_id=tsp.time_subpricelist_id
    join root.subpricelist sp on tsp.subpricelist_id=sp.subpricelist_id
    join root.time_spec ts on tsp.time_spec_id=ts.time_spec_id
    join root.minval_spec mv on sp.minval_spec_id=mv.minval_spec_id
    join root.destprice_destpricelist dp_dpl on sp.destpricelist_id=dp_dpl.destpricelist_id
    join root.dest_price dp on dp_dpl.dest_price_id=dp.dest_price_id
    join root.destination_prefix dpfx on dp.dest_id=dpfx.dest_id
    join root.prefix p on dpfx.prefix_id=p.prefix_id
    join root.timeofday t on ts.timeofday_id=t.timeofday_id
    join root.dayofweek d on ts.dayofweek_id=d.dayofweek_id
    join root.holiday h on ts.holiday_id=h.holiday_id
    where 
    ct.contract_id=? and
    (holiday_date = date(cast(? as timestamp) + ? minutes)
    or holiday_date = date('0001-01-01'))
    and
    (
    cast(? as timestamp) + ? minutes >= 
    timestamp(date(cast(? as timestamp)+ ? minutes), time_start)
    and
    (cast(? as timestamp) + ? minutes) <
    timestamp(date(cast(? as timestamp) + ? minutes ), time_start) 
    + t.period_length minutes
    )
    and prefix=substr(?, 1, length(prefix)) 
    and
    (
    (dayofweek(cast(? as timestamp) + ? minutes) - 1 >= day_start and 
    dayofweek(cast(? as timestamp) + ? minutes) - 1 - day_stop <= d.period_length)
    or
    (dayofweek(cast(? as timestamp) + ? minutes) - 1 <= day_stop and
    day_stop - dayofweek(cast(? as timestamp) + ? minutes) - 1 <= d.period_length)
    )
    order by prefix desc, time_spec_id desc, holiday_date desc 
    fetch first 1 row only optimize for 1 row for read only with cs";

За этим - очень простая логика, реализуемая элементарно, если процедурно. И
это не худший случай, то, что творится внутри система типа SAP, 1C -
хуже на порядки.
Идея, заложенная Кодом в реляционную теорию и в его язык доступа к данным, была проста и наивна - дать пользователю доступ к
данным минуя программиста.
Кодд приводил в пример запрос на его языке к реляционной системе и на языке доступа к системе CODASYL.  И тут
я с профессором согласен Но оставим CODASYL в стороне.
Имеем множество диалектов SQL, ведущие из которых очень мощны, избыточны,
многовариантны, сложны, один и тот же результат можно получить
несколькими способами, а реальность - то, как запрос будет выполнятся -
можно узнать только не всегда простыми специальными инструментами, типа
Explain, и IBM здесь не образец простоты ну никак. Достаточно мало
разработчиков умеют получать план выполнения запроса, ещё меньше  умеют
его понимать, и ещё меньше умеют "исправить" исходный запрос, для
получения приемлемого плана выполнения. На западе профессия
"переписывателя" SQL запросов очень ценится. Но план  выполнения запроса
с течением времени не постоянен, он изменяется,  таким образом процесс
оптимизации SQL запросов непрерывный и очень дорогостоящий, идущий до
конца эксплуатации системы.
Реальные системы в производстве состоят из множества сложных запросов, не читаемых "в лёт".  Если их не
оптимизировать - то надо обеспечить избыточность аппаратных мощностей
для более-менее приемлемой эксплуатации системы. Пардон, но это ну никак
не вяжется с парадигмой консолидации, надеюсь, понятно, почему.
Разработчики вынужденны знать и язык программирования общего назначения, и SQL. Его
надо отдельно и серьёзно учить, это стало профессией.
То есть не пользователи имеют доступ к данным, как мечталось, а появилась новая профессия. Это не страшно. Но.
Но проблема усугубляется тем, что современные средства разработки не
предполагают ручного написания SQL (не говоря уже о его отладке) и
вообще не предполагают знание его.
Как факт индустрией признана сложность SQL и появились средства, изолирующие разработчиков от
сложности SQL, которые генерят тексты запросов.
Таким образом, ныне в эксплуатации куча систем, где коды SQL запросом никогда не видел
человек, не говоря уже о планах выполнения. такие системы уже
практически нереально довести до эффективного состояния, практически ни
за какие деньги. Когда я мониторингом нахожу проблемные запросы,
анализирую их планы выполнения и переписывах текст запросов -
компания-разработчик заявляет, что не может вычленить все инстанции этих
запросов в системе. Система живёт 8 лет, потребляя ресурсов минимум на 4
порядка больше, чем должна, даже с WAS и DB2. Это ну никак не вяжется с
концепцией консолидации.
Но очень выгодный бизнес и для вендора, и для разработчика-поставщика.
Не надо называть РДБМС и SQL - "простота".
Как проверить? Получить тексты запросов 1C
Ладно, не буду таким жестоким, можно и чего-нибудь по-проще, не травмирующие разум

IMS
Прежде всего, это не CODASYL система, и вообще не попадает ни под один стандарт. Ну, как и АДАБАЗ, обе системы вне стандартов, отчасти и благодаря этому успешны (высказывание akost, я уж позаимствую).
Для работы с IMS разработчик должен знать только один язык, на котором составляет текст программы. Работа с IMS ничуть не сложнее работы программиста сMQ, очень даже похоже, до поразительного совпадения, но что-то я не припомню, чтобы хоть кто-то в мире жаловался на сложность работы с MQ. В отличие отSQL
Хотя по-рассуждать о сложности работы с MQ горазды все, кто с ней не работал
Проверить - взять и написать программу по работе с IMS, на COBOL, простую задачу с готовой базой я дам. Потом то же самое сделать на Java + DB2.
Можно смело говорить, IMS для прикладного разработчика это очень просто.
Есть только один способ получить данные, и он же правильный.

Может ли наша страна развиваться успешно без применения консолидации систем на фреймах? Безусловно, альтернатив полно.
Может ли наша страна успешно развивать экономику в высоко конкурентной среде без мер протекционизма и без построения высокоэффективных централизованныхсистема на IMS и COBOL ? Однозначно нет!
Эксплуатируя десятки лет старые вычислительные системы без изменений западные компании имеют запредельный ROI.
Вынуждая наши компании к постоянной смене одних технологий другими, "ещё более эффективными", при отсутствии построенного базиса в виде core systems, вендоры орекают их на чрезмерные затраты и низкую эффективность. Я не сторонник теории заговора. Скорее тут теория глупости.
Не может банк, с трудом закрывающий опер день в ночное окно, честно конкурировать и стать мировым.
С чего надо начинать нашим компаниям, т с построения высокоэффективных core systems, или с консолидации линуксов?

Ну а тезис "пусть ДБ2 плодятся и размножаются, и занимают весь большой фрейм" может вызвать лишь улыбку. Это сродни пожеланию "пусть все люди будут добрыми и честными", одного порядка.
Ну, пусть подсистема ДБ2 это пять адресных пространств, включая  DDF для подключения распределённых клиентов. Хочу видеть инсталляцию из 20 подсистем ДБ2 в промышленной эксплуатации. А это всего 100 адресных пространств. Feducia аутсорсит более 800 банков, сколько у неё подсистем ДБ2? Ну и IMS?

Да, если я со своим нетехническим бэкграундом вынужден пояснять эти азы технарям... Пожалуй, мне пора уходить из индустрии.
Я не могу бороться с пропагандистской машиной, которая главпуровскими агитками заменяет мозги.

> Да, если я со своим нетехническим бэкграундом вынужден пояснять эти азы технарям... Пожалуй, мне пора уходить из индустрии.
Я не могу бороться с пропагандистской машиной, которая главпуровскими агитками заменяет мозги.

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

Это троллинг, я так понимаю. Гриша хоть и эмоционален, но последователен. И аргументы у него присутствуют. Да, радикален, но факты присутствуют. А высказывание типа "пока одни тут разглагольствуют, другие дают стране руду" - это не шибко честно.

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

Когда я говорил про "работают", я имел в виду простую вещь - DB2 для z/OS как центр большинства решений не просто присутствует в каких-то маркетинговых материалах и заявлениях - это огромный пласт работ проведенных здесь в России - технические презентации, портирование, нагрузочные испытания. Мне кажется к чужому труду надо относится с уважением. Именно эта работа помогает результату, а не мочить конкурирующие продукты на форуме

опять же, не надо сгущать. тут - техническое место, клиентов тут нет. и говорить о недостатках продуктов тут уместно, даже если поставщик или разработчик считает их флагманскими. это - технический ресурс, и технические аргументы тут имеют решающую роль.
имеете сказать, что SQL-запросы эффективнее программ на DL/1  - скажите, изложите аргументы, мы послушаем, оценим, примем во внимание. а сказанное Власовым про SQL видел сам, и на мейнфрейме в том числе, когда туда подключали 1С. кстати, проект так и утопленный общими усилиями IBM и 1С))). это к вопросу продвижения и прочего.
есть свои плюсы и минусы у реляционных баз. есть говенная файловая система в zOS. есть еще масса технических проблем, в разных платформах - разные. и есть очень убогая манера продвижения мейнфреймов в России и в мире, основанная на невысокой технической грамотности управленцев здесь, и, допускаю, там. и обо всем этом мы будем тут говорить, и в резких тонах.
так что критика тут никого не мочит. тут публика другая. а продавцов мы тут все нежно любим, когда по делу идет разговор, а не на уровне "все знают, что консолидация - это хорошо!". консолидация консолидации рознь, чо уж тут.

Зря Вы на Гришу "наезжаете", он во многом прав. Речь идет о "серьезных системах"..., конечно, составить "каталог домашних DVD's можно и на DB2".

Да ладно, разве же это наезд.
Так, плач Ярославны.
Давайте лучше вот тут немного наездами позанимаемся, в хорошем смысле этого слова.
тоже тема больная.
Может, у я чего неправильно понимаю, не вижу тенденций