Вот попробовал набросать свой взгляд, почему не получилось продвинуть в России IMS.
Итак, не получилось потому, что:
IMS - это мейнфрейм, а мейнфреймов чем дальше, тем меньше. Ниша съеживается, причин тому - масса, и объективных, и субъективных. Это можно обсуждать очень долго и под разными углами зрения, но для меня совершенно понятно: та модель продвижения мейнфреймов и поведения на этом рынке производителя не способствует расширению их количества. Является такая модель поведения IBM глупостью или таков объективный ход истории - это предмет отдельного обсуждения, но объективный факт остается фактом: количество мейнфреймов уменьшается, а вместе с уходящими мейнфреймами уходит плацдарм для внедрения IMS.
На рынке нереляционных СУБД у IMS есть очень сильный конкурент - ADABAS. Это тоже нереляционная СУБД, которая, в отличие от IMS, имеет массу сильных сторон - начиная от мощнейшего языка NATURAL, и заканчивая современными свистелками и перделками, типа доступа из SQL, Java и так далее. Я не буду подробно описывать все вкусности программной линейки от Software AG на мейнфреймах и особенности ADABAS-овской модели данных, но могу вас всех уверить: технически там все на очень высоком уровне.
Низкий уровень базового образования в области ИТ. Сам смотрел программы ВУЗовские и могу уверенно утверждать: основам обработки и моделям хранения данных учат очень поверхностно и в своем большинстве обсуждают только реляционные модели. Причем такое длится уже не год, не два, а пару десятилетий. Неудивительно, что подавляющее большинство инженеров просто не понимают, о чем вообще идет речь и зачем это нужно. Приходится разжевывать с самого начала, от азов. Не каждому слушателю или оратору это по плечу и не всегда это возможно.
Подвижность ИТ-рынка и желание быстро-быстро получить хоть какой-то результат, пусть даже этот результат будет не очень качественным. Для IMS, как мне кажется, нужен зрелый и консервативный ИТ-ландшафт. Продукт имеет высокий порог входа: нужны оборудование, специалисты, существенное время на проектирование, высокие требования к культуре работы и так далее. Все это можно обеспечить, но для этого нужно иметь хорошо описанную предметную область, железобетонную уверенность в том, что решение будет востребовано долгие годы без кардинальных переработок основных структур и алгоритмов обработки данных. У нас, увы, идет постоянное движение и обновление даже в таких консервативных областях, как бухгалтерский учет, не говоря уже, например, о пенсионном законодательстве. Планирование на пять лет вперед является экстремально рискованным, тут за год может все измениться полностью (особенно с учетом Крымнаш, Санкциинавсегда, Усiнамайдан, Навальныйпридетпорядокнаведет, Недадимвобидуновороссию и прочую веселуху). Поэтому основной подход к работе заключается в максимально быстром получение результата, предъявлении его заказчику и получению кусочка денег, пусть небольших, но уже сейчас, ибо завтра может не наступить никогда.
Большинство названных факторов, кстати, в том или ином виде имеет место не только в России или на пост-советском пространстве, но и в мире в целом, поэтому рискну предположить, что IMS не продвигается не только в России, но и везде. Там, где он есть - он есть и будет работать еще много лет. Но новых установок, с нуля, я подозреваю, исчезающе мало или даже нет совсем.
IMS - интересная и производительная система, с массой особенностей, которые становятся достоинством или недостатком в зависимости от квалификации, опыта и представлений того, кто его оценивает, и от того, как конкретный специалист привык решать ту или иную задачу.
Так что вряд ли можно было надеяться на то, что здесь, в России, сломают общую тенденцию. Однако я активно поддерживал деятельность по продвижению IMS, хотя, признаюсь, делал это в угоду своему собственному частному мотиву: я считал и считаю крайне важным расширение инженерного кругозора у российских специалистов. Мне не нравится монополия на технические идеи, поэтому все, что заставляет специалистов ломать свои стереотипы я буду поддерживать, даже если это «что-то» не имеет коммерческого будущего. И в целом, я считаю, все сложилось хорошо: были и семинары, и курсы в Бауманке, и огласка, и приезд специалистов. Значит все, что сделано, было сделано не зря, и на IMS крест ставить рано. А может мы еще что-нибудь замутим и попродвигаем, а?)))...
Категория: От AKost | Добавил: akost (20.03.2015)
| Автор: Костырко Александр
Неправда ваша, дяденьки! Какая-такая эпитафия? Данная статья есть личный взгляд на вещи, не более того. Если IMS будет где-то установлен и приживется, я буду очень-очень рад, потому что это будет значить, что у нас есть люди, способные преодолеть вышесказанное, как со стороны поставщиков-производителей, так и со стороны заказчика. Так что перечитать последний абзац и продолжать работу, и только так. Несмотря на.. ибо сложные задачи - для настоящих мачо, и только так))). И еще. Я работаю на корпоративного заказчика, и моя главная задача - быть пессимистом и готовиться к худшему. Чем я и занимаюсь. Каркаю, так сказать!
Пааазвольте! Никто ничего не закрывает, даже наоборот. Хотел я сперва "про-оппонировать", потом перехотел, пока кратко скажу - в эссе не изложена ещё одна причина - противодействие вендора. И открыто наглое противодействие, с подлостью и интригами, и молчаливое противодействие, всестороннее замалчивание, и хитрое противодействие, например, наш присутствующий здесь коллега убеждал меня "надо поддержать вебсфера + дб2, если это сохранит мейнфрейм, тогда будет место и для ИМС", но ведь зависимость противоположная была для данного заказчика! Только применение ИМС могло сохранить мейнфрейм! Вернее сказать, продвижение "вебсфера плюс дб2 и хули думать" ведёт к гарантированию выкидыванию мейнфрейма, так будет точнее, а продвижение ориентированного на потребности заказчика решения, каким могло бы быть продвижение решения на ИМС (а не продвижение ИМС) могло бы сохранить его.
Вот вопрос локализации звучит интересно... Надо будет подумать.
Ну я твою причину про внутреннее сопротивление части специалистов производителя указать не могу - я ж с другой стороны дверей, и достоверно знать о ней не могу. Хотя имею основание догадываться об этом)..
Примерно такую же песню можно спеть и про Адабас в настоящем, от которого в прежние советские времена "глаза рябило", что не проект, то Адабас с Натуралом..., а ИМС не было в проектах и в советские времена, нет, мы много про него знали, и дистрибутив был минский, но мы, по-дурости технической, мечтали использовать SQL/DS (предтеча DB2), хотя, ресурсов МФ на него, обычно, не хватало, а внедряли Адабас... Основной причиной такого положения дел было, то что версия Адабас была локализована, а остальные системы - нет.
Ну я бы поспорил с тем, что главным условием успеха Адабаса-Натурала была локализация. Скорее, я бы назвал намного меньшие требования к ресурсам. Мы проводили сравнения Адабаса и SQL/DS - разница была разительная. Ну и то, что комплект Адабас+Натурал давал полное самодостаточное решение для создания приложений. С SQL/DS требовалось на PL/SQL писать доступ к данным, а экранные формы и логику приложения там хрен напишешь, приходилось пользоваться полноценными языками типа PL/I, что увеличивало громоздкость решения. Ну и немалое значение имело то, что Адабас давал приличную производительность сразу "из коробки", а SQL/DS приходилось оптимизировать (и приходится сейчас).
Чё-то Грибоедова мне напомнило, про времена Очаковские и покоренье Крыма... Современные эффективные менеджеры (Чацкие то бишь), пробежавшись по Data sheet и Overview модных баз и тулзов, несут какую-то чушь, а закаленные бойцы суют им под нос толстенные Guide, пытаясь убедить в всяких вкусностях старинных рецептов. Ушел поезд и для IMS и для Adabas, а жаль... Пункт 4 - ближе всего к истине, нмв. Что бы сделать стоящую систему, а не поделку, нужен приличный коллектив и от трех до пяти лет разработки с гарантированным финансированием. А не так как сейчас, договора заключаются к середине года, а закрываются уже в ноябре, почти всегда без гарантии пролонгации. Отсюда и изготовление не пойми чего. И да, систему-то, после разработки и внедрения, еще надо и подкручивать и доделывать, а вот этого совсем никто сейчас не хочет
Всё верно, современное законодательство, система тендеров, контрактов, не способствует долголетнему планированию. Но есть небольшое исключение. Выпадающее из всеобъемлющего законодательства, чем и являющееся перспективным. И где есть место и многолетнему планирование, и даже место, время, и деньги на подкручивание и доделывание, и что особенно интересно, на это доделывание (обслуживание) бюджет фиксирован, и всё, что будет сэкономлено - чистая прибыль. Что способствует пристальному прислушиванию к инженерам, в плане как бы нам сделать так, чтобы потом как можно меньше возвращаться, тестировать, проверять, разрабатывать. Потому я настойчиво и талдычу - изменения только по бизнес-требованию, а не по изменению версии платформы! Иначе это уже в убытки пойдёт.
мда, весеннее обострение, видать. вообще-то, я писал о статусе единственного поставщика. которого годовой цикл (в реальности получается около 9 месяцев) гос контрактов и закупок по соответствующему закону не касается.
Следует признаться - отчасти да. Я долгое время наблюдал за этим странным внутренним противостоянием и несколько рад, что "наши" победили. Уж точно для этого непростого занятия - продажи мэйнфреймов, особенно для новых заказчиков, подобные внутренние конфликты не способствуют развитию платформы.
Конечно.. Когда это затягивает сроки, добавляет путаницу и непонимание у всех внешних и внутренних участников, безусловно это мешает. Вот если бы помимо споров с пеленой у рта за этим прекрасным продуктом еще были бы люди, которые будут устанавливать, разрабатывать, тестировать, мигрировать... Да хоть что-то делать.. Вот тогда да. Но увы. Законодательство виновато видимо в их отсутствие или масса других факторов, перечисленных в комментариях. Да здравствует трудолюбие! Да здравствует ответственность! Да здравствует DB2!
IMS и DB2 - несколько разные продукты. У каждого есть свои плюсы и минусы. Так что при выборе того или иного нужно скорее ориентироваться на конкретную задачу. В DB2 быстрее разработать что-то. Но если скорость более актуальна - можно подумать про IMS. А персонал... Так ведь если продуктом мало пользуются, то и персонала будет мало. И наоборот, если исходя из реальных потребностей заказчик будет выбирать продукт (например, тот же IMS), то следом появятся и люди, которые умеют проектировать, разрабатывать и прочее.
Теория понятна. На практике, ну решили допустим, что IMS для данной задачи лучше подходит, ну и дальше кто что будет делать? Та толпа ужасных людей, которые лоббируют DB2 и не дают развиваться бедному IMS отошла в сторону допустим.... IMS-то сам не ставится Приложение само не пишется Миграция сама не мигрирует
кхм... хочется спросить. а что, у нас в стране поставщик СУБД пишет для заказчика задачи?... вроде ж везде поставщик и разработчик - это разные вещи. у нас, например, пишет все заказчик...
А как же: - доказать состоятельность теории на пилоте - помочь разработчику с частью функционала (или миграции) - научить разработчика / заказчика особенностям - отвечать на вопросы разработчика / заказчика по ходу проекта
Если заказчик не готов приложить усилия, что б хотя б немного разобраться - это смертельно. И тут уж ничего не поделать. Такому заказчику можно впарить всё, что угодно. Но ведь именно он должен в первую очередь быть заинтересован.
На следующее сообщение. По поводу пилота - ведь DB2 покупают не требуя никаких макетных доказательств. Почему для IMS исключения? Опять же - имеются исследования, которые можно почитать, подумать...
По поводу помочь, научить и отвечать - появится спрос, найдутся и специалисты.
Мне кажется, проблема в другом. Если заказчик не уверен, что через пол-года требования к системе не изменятся, то, конечно, лучше брать реляционную СУБД. Она более универсальна и проще переделать. Приложение IMS - штука более фундаментальная. Так что здесь большие требования к качеству проектирования. Короче, заказчику нужно предоставить возможно более объективную инфу, пояснить все плюсу-минусы. Далее - пусть выбирает.
Ну, к примеру, рассадка пассажиров по местам в вагоне как была сто лет назад, так и осталась. Хотя вагоны поменялись и паровозы разве что в музее увидеть можно. Почему Экспресс на DB2 сделали - это вопрос. Кроме того на DB2 строить приложение "безопаснее", потому как ежели чего - можно проще мигрировать на любую платформу. IMS жестко привязан к IBM мэйнфрэймам.
Мне нравятся аргументы, основанные на реальном опыте. Мне не понятно, почему выбор (даже гипотетический) между DB2 и IMS мешает продвижению платформы.
Мне кажется РЖД здесь приведен как раз как контр-пример. Там есть определенные вопросы к функциональности приложения, на сколько я знаю.
Выбор между DB2 и IMS хорош когда есть команды за обоими продуктами, которые готовы вкладываться в пре-сэйл руками. При чем вкладываться плотно. Увы за последнее время я не видел ни одной продажи нового мэйнфрейма, где что-то проходило без очень плотного технического вовлечения (пилоты, миграции, бенчмарки итд). Мое личное мнение, провал IMS связан исключительно с этим.
Дайте заказчика на IMS - в течение месяца будет команда, готовая и способная взять на себя и дизайн базы, и разработку приложения, и сопровождения, и обучения... Может быть, не во всех регионах, но в МО - уж точно. Другое дело, что IMS - это жёсткая привязка к IBM мэйнфрэймам. Если DB2 приложения в случае чего можно мигрировать, с IMS это намного сложнее будет. Опять же - спросите кого-нибудь про СУБД, он вероятнее всего скажет про Oracle и DB2... IMS, полагаю, в этой очереди будет где-то в конце - уж сильно она не на слуху.
В течение месяца только появится команда? А люди, которые знают, любят и умеют DB2 сидят прямо сейчас и готовы уже начать? Чувствуете разницу подхода? С утра пообщались, а к вечеру уже z/OS с DB2 развернут и готовы начинать миграцию. С DB2 LUW, с Oracle...
Я не считают жесткую привязку IMS плюсом. Вещи, связанные с этим, производительность, например - это хорошо. А жесткая привязка на мэйнфрейм - что же здесь хорошего? Совместная жизнь должна быть по-любви, максимум по-расчету, но не по принуждению
Я и говорю - про IMS мало кто знает. Потому держать готовую команду - кому надо. DB2 более распространена, она более на слуху, потому и заказов на неё больше, и как следствие - специалистов. Кроме того, месяц - нормальный срок. Пока переговоры, то да сё. А про жёсткую привязку - я так и сказал. Это плохо. Это отпугивает. Я и не говорил, что отсутствие выбора - это хорошо. DB2 здесь в выигрыше своей многоплатформенностью.
Спасибо, вы совершенно верно сформулировали мысль, которую мы достаточно долго пытаемся донести - IMS требует больше вложений при проектировании решения. Из этого вылазит необходимость понимать работу приложений и архитектурные решения, которые стояли за той или иной программной реализацией. Отсюда же и невозможность начать мигрировать какое-то решение прямо сразу как в случае с DB2. Вначале требуется большая работа с заказчиком, рисование ER-диаграмм и всех других прелестей. Ну а это, в итоге, удлиняет цикл продаж
Да. IMS не только требует больших вложений на начальном этапе. Миграция (если вдруг чего) обойдётся так же несравненно дороже, чем миграция той же DB2. Но это - касательно выбора IMS-DB2. Речь же изначально шла о трудностях с продвижением платформы мф. Как тут мешает IMS, я так и не понял. С моей кочки зрения, продвижению мф мешает та же большая начальная стоимость. Для мф нужно строить специальный машзал с фальшполом, мощной вентиляцией и проч. Стоимость техники на много больше. Стоимость лицензий на ПО... Если вдруг чего не того - проблемы с миграцией и её стоимость. С этим согласен.
А IMS... Ну есть она. И что? Заказчик выбирает DB2, потому как она более известна, больше специалистов, меньше проблем при миграции на другую платформу. И т.д.
==== Всё-равно получилось несколько не то, что хотел сказать.
Любая задача должна начинаться с работы технолога. Он должен продумать все варианты, определить последовательность операций, выделить необходимую на каждом этапе информацию. На этом анализе строится техзадание. Дальше - пишется собственно приложение. При такой организации не может быть ситуации, когда "ох, ёлы, мы забыли, а давайте быстренько". И тогда приложение живёт долгие годы. Пример - тот же АСОУП. В такой ситуации вполне реально использовать IMS. Определяющим фактором является быстрота работы, меньшие издержки на администрирование. Но платить за это нужно более длинным циклом написания запросов, что не является критичным в силу продуманности технологии и потому кардинальных изменений нет, а остальное можно делать и не быстро, но в пределах разумного.
Другое дело, когда технология не продумана. Здесь главным является быстрота латания дыр и гибкость. И DB2 имеет здесь несомненные преимущества.
Я допускаю, что существует ряд задач, где гибкость является неотъемлемой особенностью. Продумать всё и предусмотреть невозможно. Тут - однозначно DB2. Ну, и уже упомянутые: возможность мигрирования, отсутствие привязки к платформе...
ну злорадство никого вообще-то не красит, я считаю, но это личный выбор каждого, портить свою карму или нет. в отношении конфликтов. конфликт конфликту рознь. я считаю, что конструктивный технический спор отлично проясняет позиции для участвующих и великолепно чистит сосуды головного мозга. кстати, я, как заказчик, фирмы, где нет внутреннего технического противостояния, считаю просто тухлыми и лживыми. любой серьезный продукт является причиной сильных эмоций для сотрудников, которые с ним работают, и если конфликтов нет, то сотрудники просто сговорились наколоть заказчика, то есть меня. в отношении IMS. я уже говорил, в силу особенности архитектуры самой СУБД я считаю наличие ее на рынке косвенным индикатором зрелости этого самого рынка. так что уход IMS считаю удручающим признаком. Единомыслие ("одна СУБД, одна платформа, одна нация, один фюрер") считаю серьезным риском, именно поэтому у нас мультивендорность внесена в техполитику, и если на мейнфреймах воцарится один вендор, мейнфрейм вынесем нафиг. такой вот мой персональный взгляд на вещи, не толерантный нифига.
Очень хочется поспорить, но честно даже не с чем. Я за технические споры, конкуренцию в любом ее здоровом проявление и многообразие решений. Другое дело когда после этого спора говоришь - ну бери, делай... А дальше тишина Так что трудолюбие победило фанатизм Добро победило зло DB2 победил IMS Ура!
Опять ложь. Ну допустим, у локального ИБМ, включая локальную лабораторию, нету специалистов, которые способны поставить, настроить, и т.д. (что явная ложь). Но ведь несколько лет было в силе конкретное обязательство Директора IMS не только установить и сконфигурировать, но и поучаствовать в создании приложения (ядра) клиента! Примерно так же, как ИБМ сделала в 97 году для одного заказчика as/400. И не только обязательство - он реально выделил специалистов. Готовых внедрить. Трудолюбие и ответственность? А может по-фамильно перечислить все акты противодействия и подлости? Может, перечислить заказчиков и проекты, где такая дружная команда обосралась? Дикие технические предложения за гранью абсурда? Как 3 месяца не могли выдать банальный hello world, хотя вроде "конечно я знаю, конечно я писал!". Ага, вот такая компетенция, это не наклейки крутые лепить на что попало. Как MS SQL на интеле вдул DB2 на мейнфрейме по самые гланды? Хотя эта же задача на мейнфрейме обходит Интел как стоячего.... Если не упираться рогом только в один продукт (DB2) а использовать все возможности z/OS и мейнфрейма. Вот такая вот компетенция. Как на прямые вопросы заказчика несли техническую ахинею и врали (а что, ведь не по технологическим причинам выбирают платформы). А может, перечислить по-фамильно тех, кого CIO заказчика назвал "знатные подонки"? Замечательная характеристика дружной команды ИБМ. Тебе особенно будет интересно А может, лучше это не здесь, может лучше сразу Кириллу Геннадьевичу? Чтобы подлость и техническая некомпетентность подчинённых, наносящих непоправимый вред бизнесу ИБМ, была видна руководителю? Про то, кто конкретно говорил "я не допущу продажи ИМС", а кто "я против, внедрение ИМС приведёт к падению MLС (лицензионные отчисления), а заказчик должен платить больше!" Это тоже слова конкретных ИБМеров. Так что каждый из вас в меру своих сил противодействовал. А начать могу с тебя Ну раз вызвался про трудолюбие и компетенцию Можно будет даже набрать номер телефона, и пусть Кирилл Геннадьевич сам спросит, чтобы из первых уст. Про то, как наобещав с три короба, такая дружная и грамотная команда наделала таких косяков, что за полтора года все не вычистить? Там есть что послушать, и главное - заказчик всегда прав. Так что не надо хоть тут врать, может плохо закончится.
ОХ НИХРЕНА СЕБЕ! какая интересная у людей жизнь... а главное, что про это все имеет то или иное представление масса людей ВНЕ IBM. и я отнюдь не единственный из них, увы.
это что.... это только малая часть. Но из интересного ещё могу вспомнить, как уважаемый представитель уважаемого заказчика, чрезвычайно лояльного пользователя мейнфрейма, в сердцах выдал: - В следствии своей жадности в следующей жизни ИБМеры будут глистами! И не в кишках богатых и сытых европейцев, а в кишках нищих и вечно голодных африканцев! От до чего людей доводят бывает... DB2 sells hardware. Как говорят американцы. В переводе не нуждается. А для hardware нужны софтовые лицензии. Всем выгодно. Кроме заказчика
Мы тебе все эти годы мешали со всеми твоими директорами ИМС и лабой что-то запилить? Я тебе могу много рассказать про то, кто кому "вдул" в том бенчмарке. Про то, как, например, твои коллеги выставили таймаут на стороне клиента в 30 секунда и доказывали нам, что любой запрос выполняется максимум за 30 секунд. Ты как всегда слился и нам пришлось все сделать за тебя, поэтому ты не в теме.
Бред только у тебя в голове, и ты им активно засорял эфир в ИБМ долгие годы. Не тебе судить о том бенчмарке. Тебя попросили тогда поучаствовать, но ты как всегда слился. Твой же текущий работодатель пожаловался на тебя и попросил дать кого-то ещё. Или скажешь не было такого? Перечили, пожалуйста, свои достижения в ИБМ за последние пять лет. Мне что-то кроме «я умудрился много лет ничего не делать и получать за это зарплату» ничего на ум не приходит. .
Дак я и не сужу о том бенчмарке - судит заказчик. Он и назвал его провальным. Кстати, продавец по железу, теперь у нас, и ему всё о том бенчмарке высказали в лицо. Ничего, проглотил. А по поводу жалобы моего текущего работодателя - так он не подтверждает. Только узнал, что ухожу из IBM - позвонил и пригласил. Доверил команду создать. А было всё по другому. Но у меня нет желания рассказывать о твоих интригах. Как ты по твоему же выражению "мочил" меня. Я лучше буду рассказывать о своих успехах, о успехах нашей команды. А что сделано - уже можно посмотреть, ну я в другом месте написал. Вывод простой. Нет такой задачи в OLTP, включая регулярную отчётность, которую нельзя было бы на порядки эффективнее сделать используя IMS чем DB2. Плюс DFSORT для отчётности. На текущий момент не только производительность системы в бесконечное число раз выше (потому как дольше двух часов ответа от DB2 клиенты не ждут, сколько бы оно работало не известно), но и функционал на IMS кроет функционал на DB2 как бык овцу. Потому как к запросам IMS мы прикрутили regexp(), а в SQL убогий LIKE предикат. Вот как-то так, если только по фактам.
Так я оттуда сразу ушёл, ещё на испытательном сроке. Как только узнал, что политика банка - избавлятся от IBM, в том числе и моя задача была помогать избавляться от IBM. Я даже добился встречи с самим французским куратором. Ну вот по итогам разговора с ним и понял - глухо, IBM в банке не будет. Ещё что интересует? Давай теперь успехи до IBM, да?
Да ничего он не выбирал. ИБМ там был издавна. А теперь стратегия - линукс плюс оракл. Но ясно же, что такое переход будет занимать время. Сервера Power покупали как раз в те три недели, что я там был. И как раз моя задача была переводить в первом этапе хранилище с db2 power на db2 linux, во втором этапе участвовать в переводе на оракл. Но это не имеет отношение к делу. При чём тут Росбанк. Ещё вопросы будут?
У меня столько вопросов, что уже комментарии не помещаются, придётся перейти в новую ветку. Было бы конечно интереснее если бы ты на вопросы отвечал хоть немного правду, но я думаю все читатели уже догадались, что твои слова нужно просто интерпретировать ровно наоборот.
Хорошо, забудем росбанк, который на самом деле всё-таки купил дб2 и другой набор инфосферного софта, вернёмся к истокам: ты говоришь, что IMS расходует меньше аппаратных ресурсов (я с этим вообще не спорю), а значит дешевле. Всё верно? Учитывая, что IMS продаётся как AWLC софт, а DB2, как правило, zNALC какова эта экономия? Можно ли сказать, что в большинстве ситуаций купить аппаратные ресурсы с дб2 дешевле, чем купить IMS на меньшее количество MIPS?
Опять бред какой-то. Слушай, ты мне уже надоел. Я и про стоимость ничего не говорил, и стоимость бывает разная - стоимость приобретения, стоимость владения, и надо иметь в виду (при построении архитектуры) срок жизни системы, и ZNALC не всегда применим, и так далее - то есть ваш любимый подход "хуле думать, вебсфера плюс дб2 и вперёд!" глубоко ошибочен, в каждом проекте надо изучать, изучать существующую инфраструктуру заказчика, его ИТ стратегию, конкретные характеристики будущего проекта, и всегда архитектура - это компромис. Но тебе с твоими коллегами это не интересно. Вот конкретный мой текущий проект является примером, когда ZNALC нафиг не нужен ибо система на дб2 не отвечает ТЗ чуть больше, чем полностью. И невозможно это исправить, не исправив в корне всю архитектуру, начав с нуля. Что мы и сделали. А ещё учесть срок жизни системы. И вообще, у меня нет никакого желания учить тебя и твоего коллегу, хотя это парадокс - все, кто меня знает, подтвердят, что я всегда делюсь знаниями, и здесь в компании уже обучил кучу народу. Но ни тебе ни твоему коллеге это не надо - у вас одно желание, потроллить. Вот ты зачем здесь вопросы задаёшь? Ты что, хочешь систему построить, архитектуру разработать, структуры данных создать, программы написать? Нет же, никогда. Так что давай так поступим - я тебя с твоими вопросами пошлю нафиг, и буду продолжать работу, а когда мы прогоним полный цикл нагрузочного тетсирования, я опубликую их, плюс кратко описание старой и новой архитектуры. Это реально может быть полезно, потому как можно прикинуть на бизнес процессы в большом количестве компаний, и можно будет ответить на вопросы во что это обойдётся и какую нагрузку потянет. А бизнес-процессы достаточно типичны, если и у нас, и у akost, в таких совершенно разных компаниях они в своей основе совпадают, и ещё таких процессов полно в разных компаниях.
вот да, обещание опубликовать описание архитектуры и нагрузочного тестирования одобряю. считай, что ловлю за язык, призову к ответу за базар, и вообще "пацан сказал - пацан сделал"! ждем с нетерпением.
Да пока полный цикл тестирования не завершим, как-то неохота публиковать на пол дороги, кусок. Интереснее, когда полный сценарий, целиком. Что интересно, так это то, как всё взаимосвязано. Вот например, складской учёт, движение материальных средств (элементов складского учёта), как, оказывается, принципы складского учёта могут использоваться для учёта "движения" (истории жизни) документов. Казалось бы, совсем разные отрасли, так сказать, но тем не менее принципы можно использовать. Например, проблема учёта "поправочных" документов, исправлений к документам. Наш сотрудник (сманеный с чебоксарского химпрома) предожил использовать принцип складского учёта - документ не правится, а сохраняется новый документ, который отменяет старый, эдакое сторно. Получается история жизни конкретного документа, первая версия, последующие версии. А со стороны z/OS это GDG получается. Индексируются все версии, а в карточках сохраняются и старые, и последняя версия, физически упорядоченные по времени поступения, то есть по версии. Остаётся разработать процедуру внесения версии - изначально поступил документ, создалась карточка и набор данных, затем поступило изменение, создаётся новая карточка для новой версии, удаляется набор данных, создаётся GDG, и сохраняется старая версия документа и новая. И всё это из .net Вот так коллективным разумом и продвигаемся. Возник вопрос генерации имён наборов данных. Поначалу сделали из ключевых полей документа, наткнулись на очень большое количество повторов -из 430 миллионов документов примерно 24 миллиона повторов имён, и хотя их можно было сделать уникальными, используя первую букву квалификаторов имени датасета (они не задействованы), но это усложняло логику. Самым простым казалось генерировать имя из последовательного номера, первый документ - первое имя, второй документ - второе имя, переводя число порядкового номера документа в имя, как это сделано в реляционках, объект sequence или поле incremental. Но в таком случае надо сохранять последнее значение числа, и при многопоточной вставке документа изменение единственного числа сразу становится узким местом, вставка документа процесс длительный, блокировать число от начала до конца - не эффективно, делать пропуски в номерах - при нашем количестве документов не хорошо. И вот наш чебоксарец предлагает - у нас контролируемое количество регионов, вставляющих документы, регионы одно-тасковые (однопоточные), назначаем каждому региону свой HLQ, и регион сам ведёт сохранение максимального числа сгенерированных имён документов, экслюзивно блокируя свой сегмент с числом, и никому не мешая. А дальше - простой алгоритм превращения любого числа в валидное имя набора данных, буквы A-Z, цифры 0-9б @#$%, кажется. Получается, первый символ квалификатора имени это число по основанию 29, остальные семь символов квалификатора это число по основанию 40. А дальше простая математика перевода данного десятичного числа в странное число, в котором семь чисел по основанию 40 и одно по основанию 29, и это повторяется 3 раза для трёх квалификаторов, плюс HLQ и плюс LLQ для возможной GDG если придёт изменение документа. Это уже я сам код писал. Если потребуется увеличить параллелизм сохранения документов - создаём новый ICF каталог, создаём альяс, создаём JCL старта региона в котором указываем HLQ как параметр, и можно запускать новый регион, который начинает с числа 1 и генерирует имена датасетов.
Кстати, хотел сказать пару слов по поводу TPNS ака WSIM - Workload Simulator. Ну чрезвычайно мощный продукт! Это просто охренеть, какие сложные сценарии можно создавать! И настолько гибок сам продукт, настолько же дебильна документация! Это просто нечто! Хуже документации я не видел пока. Ну ладно, что основное средство описания сценария это HLASM макросы, это понятно. Но задокументировано дебильно. И только помучавшись понимаешь, что вручную запрограммировать сценарий клиентов на 400 - это мука! Есть REXX подобный язык STL, описываешь на нём сценарии, и препроцессор генерирует описание сценариев на макросах, уже легче, но документация такой же степени дебильности, и всё приходится делать методом научного тыка. Вот сейчас наш чебоксарец осванивает, ругаясь.
Ты нервничаешь, значит тоже сомневаешься, это хорошо. Посчитай стоимость конкретно для твоей задачи. Каких тебе данных для этого не хватает? Людей, электричество, помещение, количество кабелей и другие вещи, которым учат западные таланты, можешь пренебречь. Возьми основные вещи - закупочную стоимость + поддержку. Чтобы не разглашать чужие тайны, можешь говорить в процентах. Не знаешь цен на что-то? Позвони Егорову, они всё равно там ничего не делают - посчитают за недельку.
Если не хочешь или не можешь это сделать, значит твой аргумент про количество используемых ресурсов будем считать болтологией. Какая разница сколько DB2 использует ресурсов, если они в разы дешевле?
Дык как же не неврчиначть то... Ты если хочешь, чтобы я тебе отвечал - переставай троллить. Или чукча не читатель, чукча писатель? Я для кого писал, что система на дб2 не отвечает ТЗ, конкретно - время ответа на запрос бесконечно? (Более двух часов, дальше не интересно, да и больше 5 минут тоже не интересно) ? Вот кому это было написано? Вот конкретно для нашей задачи, даже если мейнфрейм бесплатно, z/OS бесплатно, и ДБ2 бесплатно, и дисковая стойка бесплатно - то зачем?! Оно же не работает, то есть не отвечает ТЗ! Ты вот к закупочной цене добавил цену поддержки. Это хорошо, но далеко не всё. Совсем не всё. И поддержка может закончится, и дальше нет возможности её даже купить у вендора - такова оказалась реальность. Значит, надо поддержку покупать у третьей фирмы, или иметь свою экспертизу в поддержке, как аппаратуры, так и софта, мы двигаемся по этому пути. Но даже кроме стоимости поддержки аппаратуры и софта есть стоимость сопровождения нашего программного комплекса. И тут тоже вагон и маленькая тележка ньюансов, особенно если учесть планируемый срок эксплуатации. Я называю это "сопровождаемостью" системы, стоимостью сопровождения программно-аппаратного комплекса, и это не то, что стоимость поддержки. Я про это уже писал, и ещё в архитектурном решении буду писать, но ты про это не знаешь - потому как руками ничего не делал. С чего ты взял, что стоимиость ресурсов ДБ2 а разы дешевле? Ну вот дай ссылку? По конфигуратору стоимость ДБ2 и ИМС практически одинакова. Но первый раз при покупке первого мейнфрейма можно получить существенну скидку - мы под это уже не подходим. Но даже первый раз, ну получил скидку года на три, пусть на 5. А планируемый срок эксплуатации комплекса 50 лет. Ну и нафига скидка на первых пять лет, кому она поможет? Учитывая, что вендор оставляет за собой право менять лицензии как ему вздумается, или вообще отказывается продавать. Только ты не только пиши в попытке затроллить, ты ещё читай, что тебе пишут, или останешься без ответов - мне не нравится, когда мои ответы не читают, пропадает желание отвечать
Я бОльшую часть времени не троллю, только когда совсем смешно. Сейчас я очень серьезен. Давай по пунктам:
1. Почему DB2 отвечает более двух часов? Можешь показать пример запроса? Как ты правильно сказал, я не специалист, но вижу в комментариях одного. Может быть он сможет тебе помочь?
2. Всё правильно про поддержку. Но есть компании, которые уже поддерживают системы без ИБМ и делают это не хуже. Зачем вам такая экспертиза внутренняя? Спросите сколько это стоит и удивитесь как недорого (если ты реально хочешь решить эту проблему, а не пытаешься тут раздуть сложность).
3. Ценообразование в ИБМ происходит не совсем так. Важен объем закупки, "историческая" скидка и тип нагрузки. Надеюсь ты не будешь оспаривать мои знания в этом, также как я не комментирую твои перлы про regex. В случае с WAS+DB2 объективно больше объем, но "новая" нагрузка, поэтому можно получить существенно лучше условия. В то время как IMS - "традиционная нагрузка" и для нее уважаемая компания IBM не хочет создавать прецедент, иначе все владельцы IMS/CICS прибегут и будут требовать столько же.
1. Не сможет. Запросов таких тьма - любой запрос, в который попадает любое не индексированное поле. Проиндексировать все поля всех таблиц не предлагать в виду явной глупости (но такое даже пробовали, да, дивны дела твои...) 2. Не пустит никто из твоих дешёвых компаний в машзал, нет шансов, просто нереально. Да и у нас уже есть все ресурсы. 3. Вебсферы нет и не планируется, пролёт раз. Аудит сервера никто не допустит, пролёт два. Да даже ежегодную сертификацию никто не допустит. Так что ZNALC не катит от слова совсем.
1. Там использовался более интересный приём чем индексирование всего. Я же говорю, попроси помощи 2. Ты опять включил режим болтологии? А IBM много пускали в этот машзал? В чем разница? 3. Про zNALC ответил ниже. Про вебсферу - в большинстве случаев её дешевле вставить в спеку и не использовать. Ой? А может она у тебя уже куплена? Проверь закупочные спеки, кажется мы можем найти сюрприз
Где это - там использовался? Разница ни в чём - имея в лицензии требования аудита сервера лицензию никто не будет рассматривать. Просто невозможно. А IBM три месяцуа сидел в машзале, настраивая ленточные библиотеки. Да, вебсфера закуплена, да, не используется. И что?
Ээээ. а в чём опозорился? Да, вебсфера закуплена - именно с целью снижения стоимости закупки, как мне пояснили. Да - не использовалась, не используется, и не планируется к использованию. В чём позор то? Мальчик, ты бредишь
Нет, не о стоимости закупки. Я же уже писал, что стоимость закупки только один из факторов. И как оказывается, не самый важный. А ещё ты и сам вспомнил про стоимость поддержки. А ещё есть стоимость владения, в которую входит и стоимость поддержки. А стоимость владения практически индивидуальна. Потому как в неё входит много переменных значений. Так у кого с мозгами проблема? Ладно, пусть будет у меня. Мне уже жаль потерянного времени. Так что вернёмся к тому, что я уже писал. Мы звершаем испытания и публикуем результаты и архитектурное описание. Результаты приводим в сравнии с текущей эталонной реализацией, архитектуру которой одобрил ты с твоей командой. Твой коллега делал тестирование производительности этой архитектуры. Он же "учил" меня, что производительность СУБД зависит от архитектуры приложения, которое с ней работает. Он же "ответственный" по твоим словам. Так что принимаем реализацию за эталонную. Кстати, и Microsoft и IBM выделили специалистов для проведения нагрузочного тестирования. Специалисты обоих компаний провели изучения и изменения. И провели тестирования. Так что вполне можно считать архитектуру эталонной. А вот препираться с тобой нет никакого желания. Всё одно ты ничего умного пока не написал.
Какая эталонная реализация? Был бенчмарк и то, что было оттестировано, работало лучше SQL Server. Об этом есть протокол, который подписали твои коллеги. Остальное - твои фантазии, потому что то, что потом вы там напилили к бенчмарку не имеет никакого отношения. Опять же, если бы ты участвовал в бенче, а не слился, ты бы знал, что именно тестировалось, какие были цели и какие были даны рекомендации после. И кто оптимизировал вашу текущую реализацию? Ты? И мы должны результаты твоей деятельности принять за «эталон»? Результаты твоей работы можно принять только за эталон того, как работать не надо. Ты постоянно уклоняешься, но ответь наконец, чего ты добился за последние 5 лет в ИБМ? Хочешь выкладывай DDL, статистику DB2, запросы с планами, параметры базы данных, настройки оборудования, параметры z/OS, полный набор записей SMF включая 113 для прогона на DB2, а потом все тоже самое для IMS с доказательствами того, что твой говнокод делает именно тоже самое и именно такое же количество раз с таким же исходным наполнением базы и параметрами запросов. И тогда мы сможем подискутировать. А пока я читаю только твой стандартные закидоны дилетанта.
Так как же не эталонная, если и ты, и специалист от MS тестировали, изучали, вносили изменения, опять тестировали? Если это не эталонная, то что эталонная? Никто ничего к бенчмарку не лепил. Менйфрейм - 5 GP + 3 ZIIP + 128 GB RAM + DS8800 (отличная дисковая стойка в плане скорости) MS SQL - x3560, 2 CP (12 cores) + 32 GB RAM + DS3512 (сами можете прикинуть её скорострельность по сравнению с DS8800) Мейфрейм - 95,9% запросов завершилось менее 1 сек Интел - 99,6% запросов завершилось в интервале от 385 мс до 650 мс Это по бенчмарку, тут больше нечего сказать, стоимость решения все могут сами прикинуть. Текущая реализация не изменилась от тестированной (ну там увеличили длины ряда полей, с 255 до гораздо больших величин). В принципе всё осталось тоже, моя деятельность - в руководстве администраторами, чтобы оно жило. План выполнения запроса вот принёс, не знаю, как фотку вставить. Могу словами. Запрос select bla-bla from table_name where field-name = 'FFBBCC' выполнялся 48 минут. Сперва index scan из индекса с 508278523 элементов, даёт 173 записи, затем fetch из таблицы (508251154 записей в ней) и на выходе 172 записи. Статистика собрана 9 числа. Поле в индексе стоит третьим. Но это ещё хороший результат, потому как если взять по непроиндексированному полю - конца не будет. Про политику "проиндексировать всё" я уже выше писал. Так что тут дискутировать больше нечего. А "говнокод" мы чуток позже будем тестировать, как сценарии будут готовы, и результаты обязательно выложим с описанием архитектуры. Данные само собой те же, что и в дб2 - нам же не продавать, мы же для ебя делаем, зачем себя обманывать то. Но только дискуссии там не будет - я с хамами не вижу смысла вести дискуссии, просто сделаем описание, потому как архитектурные приёмы и способы могут реально оказаться полезны в более чем одном случае. Так что каникулы завершились, больше у меня нет ни времени, ни желания "дискутировать" с тобой, вот только если смогу как картинку с диаграммой explainвставить, то вставлю, хотя смысла в этом никакого.
Могу только добавить, что существует документ, в котором перечислены все аппаратные средства с их серийниками и ПО с их версиями, введённые в эксплуатацию. Вебсферы в списке нет, и включение её не планируется.
Кстати, ответь, зачем платить поддержку третей стороне, которая ничего не будет делать - потому как в машзал её не пустят? Вопрос, впрочем, риторический. Уже свои ресурсы есть.
И чтобы раз и навсегда закрыть вопросы по ZNALC - вендор требует не просто ежегодной сертификации на соответсвие требованиям ZNALC, но и требует права на аудит сервера. Unreal! Это НЕ ВОЗМОЖНО, по Закону, просто нет шансов. Так что вот не надо больше про ненаучную фантастику.
Хорошо, ты победил. Существует понятие Solution Edition for New Workloads. Это еще лучше. Можно это сделать с IMS? Практически нет. Ты же разработчик? Давай лучше говорить о технических темах, я слишком хорошо знаю прайсинг
Ну ты... Нечитающий... Вот ответь, зачем дармовая лицензия на то, что не удовлетворяет ТЗ ? Тем более, что цена закупки на IMS на наши железки вполне себе ничего, не ужасающая. Других расходов гораздо больше. Те же расходы на диски... Это нечто! Ну не играет большого рояля цена закупки на софт. А если ещё плюнуть на поддержку от вендора, которую всё равно невозможно получить, и "сесть" на стабильную проверенну оттестированную версию, имея своих сильных сисрпогов, то можно забить на треование постоянной смены версий. Но лучше, конечно, купить поддержку от вендора, но он, такой нехороший, внезапно может её не продать.
Вот не думаю, что ушел. Было уже такое: к 2000 году выключат последний мейнфрейм! реляционные СУБД вытеснят все остальные! не будет ни кино, ни театра, ни книг, останется одно телевидение!... уверен, что и Адабас, и IMS нужны и останутся в качестве нишевых продуктов, особенно там, где они уже есть. а вот новое пространство - врядли, тут я согласен. но на их концепциях вырастут новые продукты и технологии.
Я бы согласился с коллегой Коневым. У Боинга была (точнее - всё ещё есть) довольно навороченная система на IMS+Cobol. 30 лет развития и под млн строк кода. Появилась идея всё это перенести на кудатотам... Предполагается на Intel (т.е. от mainframe уходят), реляционная СУБД... Как это будет делаться и во что обойдётся - не понято, но курс, судя по всему, взят твёрдо. Так что поезд если не ушёл, то плавно уходит. По крайней мере есть таковые попытки, потому как не сильно верю, что "кудатотам" покажет такую же или близкую производительность. Но приходят новые менеджеры, которым не нравится "старьё" и проталкивают модерновые идеи не считаясь с затратами.
насколько я в курсе, такие попытки миграции происходят каждый раз при смене менеджмента в крупных компаниях, сидящих на мейнфреймах. Чаще всего безуспешно. Понятное дело, если задаться целью, и "мы за ценой не постоим", то, скорее всего, в большинстве случаев сделать можно.
Фиг им!... а не последний мейнфрейм Нечем заменить, то что действительно нужно, из работающего на мейнфрейме и не важно на чём это продукт написан. Так как гораздо проще подлатать, дописать и прилепить функциональную свистелку. В близко знакомой мне системе, есть функциональная часть, отвечающая за ввод и качество входной информации, а далее очищенная, и главное достоверная, информация раскладывается по базе данных. Так вот собственно база данных, менялась за время жизни системы два с половиной раза. И недоделанная половинка, как раз и приходится на обеспечение системы ввода и контроля информации. И кардинально изменить эту часть не решаются даже сами отцы-основатели системы. Сверхтрудоемко, сложно, неблагодарно, должно строго следовать технологическому процессу и т.д. А главное - на этой очищенной информации, паразитируют сотни арм-ов, арм-иков и арм-ят с креативными лейблами.
Александр, а для "близко знакомой системы" существует документация или хотя бы исходники логического и форматного контроля ввода информации? Но согласен - переписывать громоздкую систему сильно дорого обойдётся. Хотя, приведённый мною пример говорит, что далеко не всех это пугает. Ну, флаг в руки.
Конечно существуют, правда без гарантии 100% совпадения с истиной Так нынче и читать-то (исходники и документацию) толком никто не умеет. А сделать заново быстро и совместимо с истиной невозможно - так что нема быстрого профита.
