Comments 31
По-моему, на предыдущем, митапе 18-го года обсуждал с кем-то из ваших АСОД.
На мой взгляд — натягивание совы на глобус.
В общем, к идее АСОД лично я отношусь весьма скептически. При том, что С/С++ для меня «родной» язык (пишу на нем с конца 80-х, а на RPG начал писать только в банке в 17-м), но сама концепция DDS как единого средства описания данных (PF, LF, DSPF, PRTF) мне видится вполне разумной и достаточной для выполнения текущих задач. Но в эту концепцию надо вникнуть, разобраться с ней, а не убоявшись непонятных буков кидаться изобретать свой велосипед.
Ну и пример программы можно было бы подобрать более удачный. На Fixed сейчас уже давно не пишем. Все новые скелетоны написаны на free и выглядят не столь устрашающе. :-)
Про использование SQL отдельная тема. Не так давно була у меня задача на оптимизацию, где пришлось заменять SQL запросы (которые не удавалось параметризировать и которые тормозили тем, что перестраивались при каждом вызове) на «нативный RPG»
В результате отказа от SQL и перехода на «чистый RPG» время выполнения конкретного участка кода сократилось в три раза и нагрузка была довольна
В «нефункциональных требованиях» этот вопрос обсуждался.
На мой взгляд — натягивание совы на глобус.
- Нотация АСОД ничуть не понятнее DDS.
- Работа с АСОД подразумевает разработку на C++, в том время как >95% кода написано на RPG. И более половины задач (работающих с интерфейсом) — доработка уже существующего кода, а не разработка нового.
- Для работы с дисплейными и принтерными файлами в RDi если визуальный редактор, где можно сразу видеть как все это будет выглядеть на экране (и располагать/двигать поля на экране мышкой, а не высчитывая в уме позиции). И простейшие интерфейсы там делаются вообще без вникания в тонкости DDS. Для АСОД такого инструмента, насколько я знаю, нет.
- Возможности DDS достаточно широки. От простейших форм до управления цветом, видимостью, возможностью ввода в поля. Всплывающие окна, списки прокрутки, менюшки, выбор радиокнопками — все это есть в DDS. Там можно много чего делать — я делал автоматичекую подгрузку некоторых дополнительных значений с отображением из на экране по факту ввода данных в нужное поле без нажатия Enter (например — вводите ПИН клиента и сразу (без нажатия Enter) автоматически заполняются поля с его именем/названием и т.п
- Разработка с использованием DDS проще — на RPG не требуется писать никакого дополнительного кода для вывода на экран помимо READ/WRITE. Только логика работы с данными. В АСОД же код загромождает восприятие
В общем, к идее АСОД лично я отношусь весьма скептически. При том, что С/С++ для меня «родной» язык (пишу на нем с конца 80-х, а на RPG начал писать только в банке в 17-м), но сама концепция DDS как единого средства описания данных (PF, LF, DSPF, PRTF) мне видится вполне разумной и достаточной для выполнения текущих задач. Но в эту концепцию надо вникнуть, разобраться с ней, а не убоявшись непонятных буков кидаться изобретать свой велосипед.
Ну и пример программы можно было бы подобрать более удачный. На Fixed сейчас уже давно не пишем. Все новые скелетоны написаны на free и выглядят не столь устрашающе. :-)
Про использование SQL отдельная тема. Не так давно була у меня задача на оптимизацию, где пришлось заменять SQL запросы (которые не удавалось параметризировать и которые тормозили тем, что перестраивались при каждом вызове) на «нативный RPG»
Из PEX статистики работы XXXXXXXXX видно, что 33% времени и 36% ресурсов CPU тратится на выполнение QSQRPARS в программе YYYYYYY, т.е. парсинг статических выражений при подготовке SQL запроса,
В результате отказа от SQL и перехода на «чистый RPG» время выполнения конкретного участка кода сократилось в три раза и нагрузка была довольна
Рессурсовзатратность QSQRPARS уменьшилась до незначительных показателей.
В «нефункциональных требованиях» этот вопрос обсуждался.
Не соглашусь с Вами.
Во-первых, АСОД это «собирательное понятие» и оно намного больше чем интерфейс. UI — лишь небольшая его часть. Не стоит обобщать.
Во-вторых, почему наличие большого объема кода на RPG должно останавливать от создания кода на плюсах. Особенно под ILE, где можно вызывать функции из модулей на разных языках без особых проблем. К тому же Вы сами знаете, что RPG — процедурный язык со всеми вытекающими «процедурными» проблемами и отсутствием ООП. В добавок, иногда IBM полна сюрпризов. К примеру, недавно вышел для 7.3 PTF SI73189 для поддержки %Timestamp с микросекундами. Теперь, если собрать программу на машине с этим PTF и развернуть на машине, где его еще не поставили обновление — получите MCH4437 Program import not found. Лично я начинаю переживать за стабильность софта RPG под вендорским runtime-ом.
В-третьих, в статье продемонстрирована только низкоуровневая работа с UI-подсистемой. Никто не пишет экраны на чистых плюсах. Для этого есть язык DPL, который позволяет декларативно описать и нарисовать форму. Тут не нужна IDE на старом Eclipse чтобы пододвинуть поле, достаточно простого текстового редактора (я использую Sublime Text 3 + подсветка). Все «некрасивые» конструкции спрятаны внутри, никакого кода кроме прочитай вон ту форму и .Do() писать не надо. И в дополнение, можно указать бизнес-смысл поля, например, счет или клиент. Все валидации работают «из коробки».
В-четвертых, возможности DDS конечно впечатляют, не просто так мануал составляет более 1000 листов. Но DDS больше не развивается. За последние 10 лет в нем не было никаких изменений. Он так и останется позиционным, хотя это дело привычки. Кроме того, его конструкции для использования продвинутых элементов управления не такие уж и простые, и уж точно немаленькие по размеру. В DDS ярко выражена идея MVC, они же примерно ровесники, и мне тоже нравится идея выделения отдельной структуры record format-а для передачи данных между компонентами. Но в реализации для DDS она статична и требует пересборки всего связанного при изменении. Любое изменение — перекомпилируй программу, перекомпилируй DDS. И еще, динамическая работа с полями — это практически невыносимое занятие. Дикое ограничение в 2020-м году.
В описанном решении таких ограничений нет. Библиотеки были созданы для динамики. Динамические формы, динамические record-форматы…
К тому же, пример с SQL немного не в тему. Воспринимается как рекомендация, что SQL — это плохо и использовать его не стоит.
Повышенный CPU с QSQRPARS означает, что постоянно проверяется синтаксис SQL-запроса. Видимо это динамический запрос, который постоянно менялся. Зациклите API QSQCHKS и будет то же самое. Возможно есть баг у IBM, вы не задавали вопрос о проблеме на midrange?
Сомневаюсь, что такие запросы появляются часто. Переезд в 2020-м году с SQL на ручное управление путями доступа к данным — это возвращение в прошлый век. Хотелось бы разбираться в причинах такого поведения. Не факт, что при следующем аудите производительности IBM не скажет на разработанный RPG-кусок: выбросите прямой доступ и перейдите на SQL, все будет работать быстрее.
Если говорить про пример в статье, то для UI-подсистемы SQL — это просто адаптер над данными. Реализуя специальный интерфейс, можно написать запрос и на прямом доступе, если попали в такую ситуацию, что другого решения не видно.
Во-первых, АСОД это «собирательное понятие» и оно намного больше чем интерфейс. UI — лишь небольшая его часть. Не стоит обобщать.
Во-вторых, почему наличие большого объема кода на RPG должно останавливать от создания кода на плюсах. Особенно под ILE, где можно вызывать функции из модулей на разных языках без особых проблем. К тому же Вы сами знаете, что RPG — процедурный язык со всеми вытекающими «процедурными» проблемами и отсутствием ООП. В добавок, иногда IBM полна сюрпризов. К примеру, недавно вышел для 7.3 PTF SI73189 для поддержки %Timestamp с микросекундами. Теперь, если собрать программу на машине с этим PTF и развернуть на машине, где его еще не поставили обновление — получите MCH4437 Program import not found. Лично я начинаю переживать за стабильность софта RPG под вендорским runtime-ом.
В-третьих, в статье продемонстрирована только низкоуровневая работа с UI-подсистемой. Никто не пишет экраны на чистых плюсах. Для этого есть язык DPL, который позволяет декларативно описать и нарисовать форму. Тут не нужна IDE на старом Eclipse чтобы пододвинуть поле, достаточно простого текстового редактора (я использую Sublime Text 3 + подсветка). Все «некрасивые» конструкции спрятаны внутри, никакого кода кроме прочитай вон ту форму и .Do() писать не надо. И в дополнение, можно указать бизнес-смысл поля, например, счет или клиент. Все валидации работают «из коробки».
В-четвертых, возможности DDS конечно впечатляют, не просто так мануал составляет более 1000 листов. Но DDS больше не развивается. За последние 10 лет в нем не было никаких изменений. Он так и останется позиционным, хотя это дело привычки. Кроме того, его конструкции для использования продвинутых элементов управления не такие уж и простые, и уж точно немаленькие по размеру. В DDS ярко выражена идея MVC, они же примерно ровесники, и мне тоже нравится идея выделения отдельной структуры record format-а для передачи данных между компонентами. Но в реализации для DDS она статична и требует пересборки всего связанного при изменении. Любое изменение — перекомпилируй программу, перекомпилируй DDS. И еще, динамическая работа с полями — это практически невыносимое занятие. Дикое ограничение в 2020-м году.
В описанном решении таких ограничений нет. Библиотеки были созданы для динамики. Динамические формы, динамические record-форматы…
К тому же, пример с SQL немного не в тему. Воспринимается как рекомендация, что SQL — это плохо и использовать его не стоит.
Повышенный CPU с QSQRPARS означает, что постоянно проверяется синтаксис SQL-запроса. Видимо это динамический запрос, который постоянно менялся. Зациклите API QSQCHKS и будет то же самое. Возможно есть баг у IBM, вы не задавали вопрос о проблеме на midrange?
Сомневаюсь, что такие запросы появляются часто. Переезд в 2020-м году с SQL на ручное управление путями доступа к данным — это возвращение в прошлый век. Хотелось бы разбираться в причинах такого поведения. Не факт, что при следующем аудите производительности IBM не скажет на разработанный RPG-кусок: выбросите прямой доступ и перейдите на SQL, все будет работать быстрее.
Если говорить про пример в статье, то для UI-подсистемы SQL — это просто адаптер над данными. Реализуя специальный интерфейс, можно написать запрос и на прямом доступе, если попали в такую ситуацию, что другого решения не видно.
Ну, начнем с того, что ООП не самоцель и уж точно не панацея. Сейчас оно уже не так модно как в конце 90-х.
Так что упирать на то, что АСОД хорошо потому что ООП я бы точно не стал (при всем моем уважении к ООП в целом С++ в частности и более 25-ти лет опыта писании на оном).
И, как практикующий (команда ядровых функций, сейчас в группе комплаенса) разработчик (кстати, ради интереса попробовал АСОД и какую-то несложную опцию на нем таки сделал) я могу уверенно сказать, что для наших конкретных задач он не дает никаких ощутимых преимуществ. А отсутствие визуального редактора форм — это вообще жирный минус когда приходится делать что-то сложное (ну, скажем, то же «структурированное место рождения» — 9 битком набитых экранов).
Что касается необходимости перекомпиляции при изменении экранки — это особенности наших скелетонов. Никак на связано с дисплейниками. Там проблема в том, что для обмена информацией между модулями опции (MR-VR-UR-RR) используются автогенерируемые экранные структуры. У меня есть опции, где этого нет — обмен идет GZ структурами (так получилось, что сначала там делался внешний ввод, а потом уже к нему дописывался интерактив). И там можно сколько угодно менять дисплейник, пересобрать придется только MR модуль. Что не является проблемой от слова совсем.
Уж если хочется изобресть, то скорее интереснее вот это:
www.jbcs.nl/products/j42aa.shtml
Ну и все равно все упирается в конечный вопрос — кто у нас будет разрабатывать опции на АСОД? Я вот работаю в команде ядровых функций (т.е. самый что ни на есть backend). 99.99% приходящего на доработку кода — RPG. Разработчиков, способных писать на С++ очень немного (есть, но даже не половина). Т.е. для разработки и поддержки все равно будет использоваться RPG. С/С++ используется для низкоуровневых сервисов там, где его применение оправдано удобством и скоростью разработки.
Если разрабатывать некоторую систему с нуля — наверное есть шансы. Заменить все наработанное — зачем?
Так что упирать на то, что АСОД хорошо потому что ООП я бы точно не стал (при всем моем уважении к ООП в целом С++ в частности и более 25-ти лет опыта писании на оном).
И, как практикующий (команда ядровых функций, сейчас в группе комплаенса) разработчик (кстати, ради интереса попробовал АСОД и какую-то несложную опцию на нем таки сделал) я могу уверенно сказать, что для наших конкретных задач он не дает никаких ощутимых преимуществ. А отсутствие визуального редактора форм — это вообще жирный минус когда приходится делать что-то сложное (ну, скажем, то же «структурированное место рождения» — 9 битком набитых экранов).
Что касается необходимости перекомпиляции при изменении экранки — это особенности наших скелетонов. Никак на связано с дисплейниками. Там проблема в том, что для обмена информацией между модулями опции (MR-VR-UR-RR) используются автогенерируемые экранные структуры. У меня есть опции, где этого нет — обмен идет GZ структурами (так получилось, что сначала там делался внешний ввод, а потом уже к нему дописывался интерактив). И там можно сколько угодно менять дисплейник, пересобрать придется только MR модуль. Что не является проблемой от слова совсем.
Уж если хочется изобресть, то скорее интереснее вот это:
www.jbcs.nl/products/j42aa.shtml
Ну и все равно все упирается в конечный вопрос — кто у нас будет разрабатывать опции на АСОД? Я вот работаю в команде ядровых функций (т.е. самый что ни на есть backend). 99.99% приходящего на доработку кода — RPG. Разработчиков, способных писать на С++ очень немного (есть, но даже не половина). Т.е. для разработки и поддержки все равно будет использоваться RPG. С/С++ используется для низкоуровневых сервисов там, где его применение оправдано удобством и скоростью разработки.
Если разрабатывать некоторую систему с нуля — наверное есть шансы. Заменить все наработанное — зачем?
По поводу SQL отдельно.
Там проблема была в том, что запросы, содержашие IN (...) не параметризуются (для них нельзя вынести в *INZSR Prepare/Declare. Т.е. строка запроса строится на лету и каждый раз перед исполнением строится план заново. Что приводит к повышенной нагрузке.
Прямой доступ 100% предсказуем и управляем. Для сложных запросов — да, муторно. Но там, где он вызывается десятки и сотни раз в секунду (а функции, скажем, проверки клиента по спискам террористов-экстремистов дергаются ох как часто и очень много откуда) требования к эффективности очень высокие. И у нас таких функций очень много. Репликаторы JMON, обработчики HMQ… Тут приходится сильно думать за эффективность кода и о том как он будет работать. И многие наши разработки идут на бой только через нагрузочное тестирование.
Там проблема была в том, что запросы, содержашие IN (...) не параметризуются (для них нельзя вынести в *INZSR Prepare/Declare. Т.е. строка запроса строится на лету и каждый раз перед исполнением строится план заново. Что приводит к повышенной нагрузке.
Прямой доступ 100% предсказуем и управляем. Для сложных запросов — да, муторно. Но там, где он вызывается десятки и сотни раз в секунду (а функции, скажем, проверки клиента по спискам террористов-экстремистов дергаются ох как часто и очень много откуда) требования к эффективности очень высокие. И у нас таких функций очень много. Репликаторы JMON, обработчики HMQ… Тут приходится сильно думать за эффективность кода и о том как он будет работать. И многие наши разработки идут на бой только через нагрузочное тестирование.
А что заставляет банки в РФ использовать подобное legacy? Я понимаю, что в США это обусловлено тем, что автоматизация там началась 50 лет назад. А у нас это только 90-е годы (собственно когда и появились коммерческие банки).
А что в этом плохого? Оно работает. Хорошая производительность, высокая надежность. Реальное время (все операции совершаются круглосуточно, а не «с 4-х утра до полуночи»).
На самом деле, все это спрятано внутри. Внешний (пользовательский) интерфейс может быть каким угодно — через WS можно подключить любую морду.
Терминал — это для разработчиков и поддержки по большей части. Ну кто-то из бизнеса работает в нем, но далеко не все.
Могу уверенно сказать, что на уровне ядра АСОД не используется. Пробовали ради интереса, но плюсов для себя не нашли. Таких, чтобы тратить время на перестройку рабочего процесса и стандартов разработки.
На самом деле, все это спрятано внутри. Внешний (пользовательский) интерфейс может быть каким угодно — через WS можно подключить любую морду.
Терминал — это для разработчиков и поддержки по большей части. Ну кто-то из бизнеса работает в нем, но далеко не все.
Могу уверенно сказать, что на уровне ядра АСОД не используется. Пробовали ради интереса, но плюсов для себя не нашли. Таких, чтобы тратить время на перестройку рабочего процесса и стандартов разработки.
Это у банка-то высокая производительность? А почему рублевый перевод из Альфы в Сбер идет сутки? И валютный (внутри!) Альфы тоже быстрее суток не проходит? Я конечно понимаю, что тут скорее всего человеческий фактор, но зачем тогда говорить про требование высокой производительности для такой системы? С точки зрения пользователя от замены клерков на компьютеры скорость работы банка не поменялась.
Я принимал участие во многих highload проектах и что-то мэйнфреймов там не наблюдал.
А почему проблема именно в Альфе?
Мой опыт переводов (все рублевые)
С2С Сбер — Альфа. Практически сразу
С2С СКБ — Альфа. Практически сразу
С2С Альфа — Сбер — в течении суток
Между клиентами по номеру телефона или счета
Альфа — практически сразу вне зависимости от того, в одном городе клиенты или в разных
Сбер — практически сразу в пределах города и в течении суток если между городами (Екб-СПб, например).
Со счета в ВТБ на счет в Сбер перевод шел вообще дня три…
А вот еще ситуация, с которой я сталкивался в одном банке. Есть счет и привязанная к нему карта. Остаток по карте и остаток по счету технически разные вещи. Так вот в том банке было так — если к счету привязаны две карты и на счете лежит, допустим, 10тр, то можно сначала по одной карте потратить 7тр, а потом по другой еще 5тр. Потому что остатки на счете и карте выравнивались только на следующий день. А то и через день. В такой ситуации в момент синхронизации остатков получался технический овердрафт на -2тр.
В Альфе такого быть в принципе не может — там сихнронизация проходит максимум в течении минуты, а реально за несколько секунд.
Еще в рекламе одного из банков было «все операции проводятся с 4-х утра до полуночи». Потому что с полуночи до 4-х утра издет переход на следующий банковский день (End-Of-Day — EOD) в это время все операции кешируются и не выполняются, они проведутся уже следующим днем.
В Альфе этого нет. Там все операции идут и во время EOD в режиме реального времени. Это достаочно геморройно для разработчиков (юнит ночного ввода, накат из ночи в новый день и т.п.) Но это работает.
Я не знаю что такое hiload. Видимо, что-то из разряда realtime. Некое качественное понятие, характеризующее внутреннее устройство системы. Те, кто релаьно работает с реалтаймом, оперируют количественными понятиями — гарантированное время отклика системы. Думаю с hiload что-то подобное.
Так вот. Только таблица клиентов в Альфе — несколько десятков миллионов записей. А каждая запись в таблице клиентов тянет за собой еще кучу клиентских данных (карточки клиентов, счета, карты и еще много чего...) Итого нагрузка на систему по оценкам составляет (в обычном режиме) порядка 3млрд изменений БД в сутки. Это только изменений. Обращений к БД на чтение там как минимум на порядок больше. С таким hiload работали?
Мой опыт переводов (все рублевые)
С2С Сбер — Альфа. Практически сразу
С2С СКБ — Альфа. Практически сразу
С2С Альфа — Сбер — в течении суток
Между клиентами по номеру телефона или счета
Альфа — практически сразу вне зависимости от того, в одном городе клиенты или в разных
Сбер — практически сразу в пределах города и в течении суток если между городами (Екб-СПб, например).
Со счета в ВТБ на счет в Сбер перевод шел вообще дня три…
А вот еще ситуация, с которой я сталкивался в одном банке. Есть счет и привязанная к нему карта. Остаток по карте и остаток по счету технически разные вещи. Так вот в том банке было так — если к счету привязаны две карты и на счете лежит, допустим, 10тр, то можно сначала по одной карте потратить 7тр, а потом по другой еще 5тр. Потому что остатки на счете и карте выравнивались только на следующий день. А то и через день. В такой ситуации в момент синхронизации остатков получался технический овердрафт на -2тр.
В Альфе такого быть в принципе не может — там сихнронизация проходит максимум в течении минуты, а реально за несколько секунд.
Еще в рекламе одного из банков было «все операции проводятся с 4-х утра до полуночи». Потому что с полуночи до 4-х утра издет переход на следующий банковский день (End-Of-Day — EOD) в это время все операции кешируются и не выполняются, они проведутся уже следующим днем.
В Альфе этого нет. Там все операции идут и во время EOD в режиме реального времени. Это достаочно геморройно для разработчиков (юнит ночного ввода, накат из ночи в новый день и т.п.) Но это работает.
Я не знаю что такое hiload. Видимо, что-то из разряда realtime. Некое качественное понятие, характеризующее внутреннее устройство системы. Те, кто релаьно работает с реалтаймом, оперируют количественными понятиями — гарантированное время отклика системы. Думаю с hiload что-то подобное.
Так вот. Только таблица клиентов в Альфе — несколько десятков миллионов записей. А каждая запись в таблице клиентов тянет за собой еще кучу клиентских данных (карточки клиентов, счета, карты и еще много чего...) Итого нагрузка на систему по оценкам составляет (в обычном режиме) порядка 3млрд изменений БД в сутки. Это только изменений. Обращений к БД на чтение там как минимум на порядок больше. С таким hiload работали?
Highload это например Google, Yandex, Skype, WhatsApp.
Я около 8 лет назад делал часть backend'а Skype и там пользователей было больше миллиарда. Кластер из обычных серверов с postgresql вполне справлялся. Не знаю, сколько информации нужно на одного клиента (допустим 1кб), то на 1e7 клиентов это 10ГБ. Можно в памяти прокешировать. 3e9 изменений ~ 300 транзакций в среднем на клиента в сутки? Ну я так часто в магазин не хожу :-)
А по поводу Альфа-банка — быстро работают только рублевые платежи у физлиц. Валютный перевод (любой) или конвертация у юрлица — только по рабочим дням и медленно.
Там зависит какие операции. Если только отдавать контент, у вас хорошо все горизонтально масштабируется, актуальность не критична — то проблем нет.
В банках же идет суровый OLTP и деньги. Там так просто на кластер не переведешь.
Конечно, это возможно все перевести на PG и т.п. и большинство шопов или уже перевели, или в процессе или задумываются. Но процесс не быстрый и дорогой.
Почему Альфа упорно держится за i… Была хорошая статья по теме, не могу сейчас найти. Там смысл в психологии менеджмента. Менеджерам спокойнее продолжать платить IBM ежегодно предсказуемую сумму (стоимость владения i относительно невелика), чем рисковать затевать миграцию где сразу нужны большие затраты и успех не гарантирован. В больших инертных организациях менеджмент крайне консервативен в данном вопросе. Пока какой-то внешний фактор явно не припрет (типа санкции), никто ответственность на себя брать не будет.
С точки зрения технической, конечно, открытые технологии и стандарты дают гораздо более высокий уровень гибкости и являются предпочтительными.
В банках же идет суровый OLTP и деньги. Там так просто на кластер не переведешь.
Конечно, это возможно все перевести на PG и т.п. и большинство шопов или уже перевели, или в процессе или задумываются. Но процесс не быстрый и дорогой.
Почему Альфа упорно держится за i… Была хорошая статья по теме, не могу сейчас найти. Там смысл в психологии менеджмента. Менеджерам спокойнее продолжать платить IBM ежегодно предсказуемую сумму (стоимость владения i относительно невелика), чем рисковать затевать миграцию где сразу нужны большие затраты и успех не гарантирован. В больших инертных организациях менеджмент крайне консервативен в данном вопросе. Пока какой-то внешний фактор явно не припрет (типа санкции), никто ответственность на себя брать не будет.
С точки зрения технической, конечно, открытые технологии и стандарты дают гораздо более высокий уровень гибкости и являются предпочтительными.
Тут ключевой вопрос — надежность и стабильность. Сама по себе гибкость никуда не уперлась ибо есть огромное количество уже работающего кода и весь он написан по определенному стандарту и весь последующий код будет писаться по этому же стандарту просто с точки зрения просто ты его дальнейшей поддержки и доработки.
Одно дело, когда все типовые программы написаны по одному шаблону и ты сразу знаешь где что искать и где что менять если потребуется, и совсем другое, когда прежде чем вносить изменения, ты вынужден постигать глубины сумеречного гения того васи, который ваял все это в припадке озарения три года назад, после чего уволилися.
Вполне, кстати, реальная ситуация — в конце прошлого года попала такая задачка. Но там полный п. был. ТЗ толком нет — обрывочные «записки на манжетах», разработчик был человек сильно творческий и уволился. Аналитик тоже уволился. В общем, консультант направления мне просто на пальцах объяснял как это должно работать, а я пытался соотнести все это с кодом и привести все в порядок.
Потому я и возражаю против описанного в статье АСОД. Не потому что плохая идея. Идея хорошая. Если все писать с нуля, я бы пошел примерно тем же путем почти наверняка.
И дисплейные сессии вещь хорошая и полезная. Когда все на них сделано.
Но сейчас в банке есть определенные стандарты и есть команда, которая с этими стандартами работает.
Вот уволится команда, разрабатывающая АСОД — кто будет поддерживать все ими созданное?
Одно дело, когда все типовые программы написаны по одному шаблону и ты сразу знаешь где что искать и где что менять если потребуется, и совсем другое, когда прежде чем вносить изменения, ты вынужден постигать глубины сумеречного гения того васи, который ваял все это в припадке озарения три года назад, после чего уволилися.
Вполне, кстати, реальная ситуация — в конце прошлого года попала такая задачка. Но там полный п. был. ТЗ толком нет — обрывочные «записки на манжетах», разработчик был человек сильно творческий и уволился. Аналитик тоже уволился. В общем, консультант направления мне просто на пальцах объяснял как это должно работать, а я пытался соотнести все это с кодом и привести все в порядок.
Потому я и возражаю против описанного в статье АСОД. Не потому что плохая идея. Идея хорошая. Если все писать с нуля, я бы пошел примерно тем же путем почти наверняка.
И дисплейные сессии вещь хорошая и полезная. Когда все на них сделано.
Но сейчас в банке есть определенные стандарты и есть команда, которая с этими стандартами работает.
Вот уволится команда, разрабатывающая АСОД — кто будет поддерживать все ими созданное?
Надежность и стабильность современных систем c IBM i во многом является коммерческой рекламой IBM, а не реальным состоянием дел.
Железо Power Systems сейчас абсолютно одинаковое для i, AIX и Linux. И я бы не сказал, что оно надежнее серверов Fujitsu или HP, например.
Безопасность системы, которая раньше гарантировалась закрытостью системы и возможностью запускать исключительно скомпилированный для i код, исключительно компиляторами IBM, порушена появлением PASE и возможностью запускать код скомпилированный где угодно и чем угодно. Более того, IBM перетащил еще и кучу опенсоурсного софта, типа ssh, ssl. Так что теперь эти системы не менее уязвимы, чем линукс системы, где этот софт используется. А чаще еще и более уязвимы, так как патчи доходят медленнее.
Более того, скажу страшное… Как известно, безопасность всей системы основывается на том факте, что предполагается возможность генерировать исполняемый код исключительно через доверенный компилятор — память то плоская, и защиты памяти на уровне ISA CPU нету. Т.е. любой процесс может обратиться по любому адресу и чего нибудь туда попытаться записать. Если в старых моделях AS400 использовалась специальная «тагетированная» память, то сейчас это обычные планки. Компилятор этот не лишен ошибок. И кто надо тот знает, как его запутать и получить желанный таг. Но я не буду здесь вдаваться глубоко в эту тему ;-). Вот так вкратце обстоят дела с надежностью и безопасностью.
А что касается наличия легаси кода который дорого переписывать, а переносить на другие платформы невозможно — так кто же с этим спорит. Гибкость же предполагает возможность запускать программы на других платформах.
Железо Power Systems сейчас абсолютно одинаковое для i, AIX и Linux. И я бы не сказал, что оно надежнее серверов Fujitsu или HP, например.
Безопасность системы, которая раньше гарантировалась закрытостью системы и возможностью запускать исключительно скомпилированный для i код, исключительно компиляторами IBM, порушена появлением PASE и возможностью запускать код скомпилированный где угодно и чем угодно. Более того, IBM перетащил еще и кучу опенсоурсного софта, типа ssh, ssl. Так что теперь эти системы не менее уязвимы, чем линукс системы, где этот софт используется. А чаще еще и более уязвимы, так как патчи доходят медленнее.
Более того, скажу страшное… Как известно, безопасность всей системы основывается на том факте, что предполагается возможность генерировать исполняемый код исключительно через доверенный компилятор — память то плоская, и защиты памяти на уровне ISA CPU нету. Т.е. любой процесс может обратиться по любому адресу и чего нибудь туда попытаться записать. Если в старых моделях AS400 использовалась специальная «тагетированная» память, то сейчас это обычные планки. Компилятор этот не лишен ошибок. И кто надо тот знает, как его запутать и получить желанный таг. Но я не буду здесь вдаваться глубоко в эту тему ;-). Вот так вкратце обстоят дела с надежностью и безопасностью.
А что касается наличия легаси кода который дорого переписывать, а переносить на другие платформы невозможно — так кто же с этим спорит. Гибкость же предполагает возможность запускать программы на других платформах.
Безопасность системы, которая раньше гарантировалась закрытостью системы и возможностью запускать исключительно скомпилированный для i код, исключительно компиляторами IBM, порушена появлением PASE и возможностью запускать код скомпилированный где угодно и чем угодно.
Чтобы пользоваться PASE, его надо сначала установить :-) Это не неотъемлемая часть системы, а дополнительно устанавливаемое ПО.
Т.е. любой процесс может обратиться по любому адресу и чего нибудь туда попытаться записать.
И получить MCH0601 или MCH3601. Он может что-то попробовать записать только в рамках выделенной под задачу памяти.
Что касается защищенности… Ну если Вы так хорошо в курсе — попробуйте похулигатить на PUB400 — он на 50-м уровне защиты работает :-)
И, опять же, ниже MI так просто не пробраться. В отличие от того же лунуха, где можно копаться в самом ядре при некоторых навыках.
Но в целом я не готов спорить на эту тему предметно — знаний пока нехватает именно на уровне таких глубоких потрохов.
Ну я не знаю что у вас там такое не свежее. Но вот тут решил вспомнить молодость (в стародавние времена немного работал с АС-ками) и зарегался на pub400…
Добро пожаловать под кат...
Картинки кликабельны.
Утилита dig на Power System, на pub400.com v 9.11.5
Утилита dig на роллинг дистрибутиве Manjaro, на котором версии всегда последние или почти последние. v 9.16.6
И не факт, что на pub400 стоит самая последняя версия системы и обновлений.
Утилита dig на Power System, на pub400.com v 9.11.5
Утилита dig на роллинг дистрибутиве Manjaro, на котором версии всегда последние или почти последние. v 9.16.6
И не факт, что на pub400 стоит самая последняя версия системы и обновлений.
И? 9.11.5=9.16.6?
pub400, к слову, одни из лучших админов, которых я видел.
А я игрался с их сервисом еще лет 20 назад когда они только начинали и объявляли конкурс на взлом.
На реальных энтерпрайзных энвайроментах зачастую с апдейтами все очень плохо. И, да, по моему опыту, сильно хуже чем с тем же linux, например.
pub400, к слову, одни из лучших админов, которых я видел.
А я игрался с их сервисом еще лет 20 назад когда они только начинали и объявляли конкурс на взлом.
На реальных энтерпрайзных энвайроментах зачастую с апдейтами все очень плохо. И, да, по моему опыту, сильно хуже чем с тем же linux, например.
Ну на LTS дистрибутивах линукс, с релизной моделью обновления, справедливости ради, бывает не лучше. Версии софта могут быть заморожены на довольно старых версиях. В них только security фиксы бэкпортят и всё. Я-ж не зря упомянул, что на моей домашней машине дистрибутив у которого софт всегда на фронтире. Всегда последней или почти последней версии.
Недостатки вроде очевидны: вендор-лок, сложно искать и удерживать специалистов и подозреваю, что есть и другие сложности.
А что хорошего взамен? Должны быть какие-то существенные преимущества перед более распространёнными технологиями, чтобы использование этой технологии было обосновано, т.к. сложность поиска специалистов обычно чуть ли не основной аргумент за или против применения той или иной технологии. Однако ни в статье, ни в вашем ответе я таких существенных причин не нашёл. Хотя возможно пропустил по невнимательности.
Особой сложности тут нет. При приеме нового разработчика есть три месяца на обучение. Обычно человек через полтора-два уже выходит на уровень выполнения несложных боевых задач.
Тут больше времени уходит на вникание в предметную область, а она от технологии не зависит.
Ну а выбор платформы зависит от того, какую АБС выбрал банк изначально. По нее уже и платформа будет конфигурироваться.
А АБС выбирается по функционалу. Альфа, Райф и Росбанк в свое время выбрали MiSys Equation под платформу IBM i. Ничего страшного в этом нет. Сложности с поиском специалистов нет, берут и обучают под себя. Удерживать специалистов тут в целом получается просто нормальным к ним отношением.
Но все это исключительно на уровне глубокого бэка. НА фронтах там все попсово и современно. Фронт с беком через WS общается.
Тут больше времени уходит на вникание в предметную область, а она от технологии не зависит.
Ну а выбор платформы зависит от того, какую АБС выбрал банк изначально. По нее уже и платформа будет конфигурироваться.
А АБС выбирается по функционалу. Альфа, Райф и Росбанк в свое время выбрали MiSys Equation под платформу IBM i. Ничего страшного в этом нет. Сложности с поиском специалистов нет, берут и обучают под себя. Удерживать специалистов тут в целом получается просто нормальным к ним отношением.
Но все это исключительно на уровне глубокого бэка. НА фронтах там все попсово и современно. Фронт с беком через WS общается.
В 80х годах RSX-11M была уже намного более удобнее этого, с WYSIWYG редакторами, нормальными файлами итд
А кто сказал что привычные файлы «нормальны»?
AS/400 — объектно-ориентированная система. Основной принцип «все есть объект». Над каждым системным объектом допустимы только те действия, которые предписаны его системными свойствами.
Например, там нельзя открыть программный объект HEX редактором и поправить в нем пару байтиков. Просто потому что такая операция недопустима для данного типа объекта на уровне системы.
AS/400 — объектно-ориентированная система. Основной принцип «все есть объект». Над каждым системным объектом допустимы только те действия, которые предписаны его системными свойствами.
Например, там нельзя открыть программный объект HEX редактором и поправить в нем пару байтиков. Просто потому что такая операция недопустима для данного типа объекта на уровне системы.
Например, там нельзя открыть программный объект HEX редактором и поправить в нем пару байтиков. Просто потому что такая операция недопустима для данного типа объекта на уровне системы.
наверное отлаживать такую систему еще то веселье...
Она просто объектная. Не объектно-ориентированная. Между объектами, к примеру, нет свойства наследования.
Насколько я понимаю, наследование в ООП используется при создании нового типа объекта на основе старого. Просто взять два существующих типа объектов и «установить между ними наследование» невозможно.
В AS/400 не предусмотрено создание новых типов объектов. Соответственно, негде и наследование применить.
Возможно, что все типы объектов AS/400 унаследованы от одного общего предка (можно так предположить судя по однотипности работы MI с объектами).
Не исключено, что объекты, создаваемые из DDS исходников (PF-DTA, LF, DSPF, PRTF), имеют общего предка — у них много общих свойств, общая структура (команды CL DSPFD, DSPFFD, системные API, возвращающие структуру таких объектов, работают со всеми ними одинаково).
Также есть наследование определенных свойств (права доступа, Job Description...) при создании объектов некоторых типов.
В AS/400 не предусмотрено создание новых типов объектов. Соответственно, негде и наследование применить.
Возможно, что все типы объектов AS/400 унаследованы от одного общего предка (можно так предположить судя по однотипности работы MI с объектами).
Не исключено, что объекты, создаваемые из DDS исходников (PF-DTA, LF, DSPF, PRTF), имеют общего предка — у них много общих свойств, общая структура (команды CL DSPFD, DSPFFD, системные API, возвращающие структуру таких объектов, работают со всеми ними одинаково).
Также есть наследование определенных свойств (права доступа, Job Description...) при создании объектов некоторых типов.
Прошу не подменять смысл сказанного.
Разговор об объектах AS/400. Объекты машинного интерфейса MI и объекты AS/400 — две абсолютно разные группы сущностей, которые практически никак не пересекаются (ну разве кроме того, что MI контекст == AS/400 библиотека, как так вышло — отдельная забавная история).
Когда говорят про объекты IBM i всегда имеют в виду объекты AS/400. Они состоят из одного и более MI объекта, здесь речь о вложении а не о наследовании.
Да, все объекты имеют стандартную для всех часть и специальную часть (как пишет Солтис). Но это не делает структуры объектно-ориентированными.
Ваш пример с объектами, создаваемыми из DDS исходников (PF-DTA, LF, DSPF, PRTF) в принципе здесь не уместен, потому что у всех них тип объекта — один *FILE. DSPF, PRTF, LF и др — это атрибуты объекта. Внимательно посмотрите в WRKOBJ прежде чем вводить людей в заблуждение.
А наследование определенных свойств здесь как может решить вопрос объектной ориентированности? Job description — это вообще отдельная структура, которая подготавливается ОС при старте задачи и указатель на нее записывается в PCO job-а, сущность исключительно runtime-а.
Разговор об объектах AS/400. Объекты машинного интерфейса MI и объекты AS/400 — две абсолютно разные группы сущностей, которые практически никак не пересекаются (ну разве кроме того, что MI контекст == AS/400 библиотека, как так вышло — отдельная забавная история).
Когда говорят про объекты IBM i всегда имеют в виду объекты AS/400. Они состоят из одного и более MI объекта, здесь речь о вложении а не о наследовании.
Да, все объекты имеют стандартную для всех часть и специальную часть (как пишет Солтис). Но это не делает структуры объектно-ориентированными.
Ваш пример с объектами, создаваемыми из DDS исходников (PF-DTA, LF, DSPF, PRTF) в принципе здесь не уместен, потому что у всех них тип объекта — один *FILE. DSPF, PRTF, LF и др — это атрибуты объекта. Внимательно посмотрите в WRKOBJ прежде чем вводить людей в заблуждение.
А наследование определенных свойств здесь как может решить вопрос объектной ориентированности? Job description — это вообще отдельная структура, которая подготавливается ОС при старте задачи и указатель на нее записывается в PCO job-а, сущность исключительно runtime-а.
Ну хорошо. Пусть она не будет объектно-ориентированной, пусть будет просто объектной :-) Как Вам будет угодно.
Я давно уже отучился упираться в концепцию ради концепции.
Кстати, из того с чем сталкивался — *USRQ Системный объект, он же объект MI. Уверен, что есть и другие.
И вложенность объектов никак не противоречит ООП. А вот строгая типизация объектов и наличие у каждого типа определенного набора свойств и допустимых операций — это вполне себе признаки объектно-ориентированного подхода при разработке системы (представления ее как набора взаимодействующих между собой объектов).
Я давно уже отучился упираться в концепцию ради концепции.
Кстати, из того с чем сталкивался — *USRQ Системный объект, он же объект MI. Уверен, что есть и другие.
И вложенность объектов никак не противоречит ООП. А вот строгая типизация объектов и наличие у каждого типа определенного набора свойств и допустимых операций — это вполне себе признаки объектно-ориентированного подхода при разработке системы (представления ее как набора взаимодействующих между собой объектов).
Не могу согласиться. Потому что тогда бы все команды OS для всех объектов *FILE можно было бы применять друг к другу, а это не так. Создаются эти объекты разными командами, специфичными для конкретного класса. Например, для создания логического файла используется команда CRTLF, а для дисплейного — CRTDSPF. Если бы было по вашему, то существовала бы единая команда типа CRTFILE, которыой бы создавались все варианты объектов данного класса, и логические файл и физические и дисплейные.
При этом, объекты наследуют ряд свойств от базового класса и есть команды применимые ко всем объектам наследующим от *FILE.
Файлы же в свою очередь наследуют от общего класса, и потому WRKOBJ работает не только с файлами но и другими объектами.
При этом, объекты наследуют ряд свойств от базового класса и есть команды применимые ко всем объектам наследующим от *FILE.
Файлы же в свою очередь наследуют от общего класса, и потому WRKOBJ работает не только с файлами но и другими объектами.
Не обязательно в моем случае должна быть одна команда типа CRTFILE. Структура данных, описывающая файл, может вкладывать в себя поля от всех типов атрибутов файла, прямо или по указателю.
Только очень сложно и неудобно работать с одной CRTFILE с очень большим количеством параметров, удобнее иметь несколько разных функций инициализации. Таким образом получаются разные CRTxxx. При этом наследование дало бы практически такой же эффект.
Френк Солтис (архитектор AS/400 по чьей диссертации можно сказать мы работаем) пишет в Fortress Rochester (2001 года книга, не та которая обрубленная «Основы AS/400» от 96го) о том, что все объекты имеют в себе общую часть, — системный заголовок, и специальную часть.
Объекты AS400 вкладывают в себя 1 или более MI-объектов, потому как эти части писались разными командами в разных странах. Могу ошибиться в цифрах, но в книге приводилась информация, что V4R? содержал более 7000 С++ классов, и внутри безусловно используется ООП.
Но в рамках объектов AS400 для нас, пользователей, эти объекты закрыты.
А WRKOBJ работает с объектом MI контекста (или библиотеки AS/400), один из простейших объектов, просто именованный список системных указателей в Single Level Storage с доп инфо.
Системный указатель (любопытное отличие этой системы от других, здесь 7 или 8 различных типов указателей на уровне виртуальной машины ILE) отличается от других как раз тем, что он спозиционирован на адрес SLS на системный заголовок. И когда выполняется resolve system pointer, в зависимости от параметров будет выполнен поиск по контексту и возвращен системный указатель на объект. Инструкция вообще там много всего умеет, в том числе сразу же ограничивать права доступа к объекту по указателю (в системном указателе права доступа «кэшируются» в нем же либо системой в зависимости от объекта авторизации job-а, либо можно самому подкорректировать их усиление, создавая свою модель безопасности).
Тема огромная, все это в книге Солтиса описано. К сожалению книгу очень сложно достать, полной онлайн версии не нашел, только отрывки в виде страниц некоторых глав.
Только очень сложно и неудобно работать с одной CRTFILE с очень большим количеством параметров, удобнее иметь несколько разных функций инициализации. Таким образом получаются разные CRTxxx. При этом наследование дало бы практически такой же эффект.
Френк Солтис (архитектор AS/400 по чьей диссертации можно сказать мы работаем) пишет в Fortress Rochester (2001 года книга, не та которая обрубленная «Основы AS/400» от 96го) о том, что все объекты имеют в себе общую часть, — системный заголовок, и специальную часть.
Объекты AS400 вкладывают в себя 1 или более MI-объектов, потому как эти части писались разными командами в разных странах. Могу ошибиться в цифрах, но в книге приводилась информация, что V4R? содержал более 7000 С++ классов, и внутри безусловно используется ООП.
Но в рамках объектов AS400 для нас, пользователей, эти объекты закрыты.
А WRKOBJ работает с объектом MI контекста (или библиотеки AS/400), один из простейших объектов, просто именованный список системных указателей в Single Level Storage с доп инфо.
Системный указатель (любопытное отличие этой системы от других, здесь 7 или 8 различных типов указателей на уровне виртуальной машины ILE) отличается от других как раз тем, что он спозиционирован на адрес SLS на системный заголовок. И когда выполняется resolve system pointer, в зависимости от параметров будет выполнен поиск по контексту и возвращен системный указатель на объект. Инструкция вообще там много всего умеет, в том числе сразу же ограничивать права доступа к объекту по указателю (в системном указателе права доступа «кэшируются» в нем же либо системой в зависимости от объекта авторизации job-а, либо можно самому подкорректировать их усиление, создавая свою модель безопасности).
Тема огромная, все это в книге Солтиса описано. К сожалению книгу очень сложно достать, полной онлайн версии не нашел, только отрывки в виде страниц некоторых глав.
Ну, я уже как-то приводил здесь ссылку на книжку. Если есть интерес, то вот еще раз. Обращаю внимание, что книга во многом устарела, но об этом ниже.
Теперь к сути вопроса. Я думаю, вы путаете модель с внутренней реализацией. Мне ваши рассуждения напомнили следующую аналогию. Взять какой нибудь OOП язык (типа С++) для которого существует транслятор в процедурный (типа C). Вы смотрите в полученный C код и говорите: ага, да там же все плоские структуры, никакого наследования! Ну все, С++ никакой не объектно ориентированный.
Да, с точки зрения MI структура плоская. Вернее, там все сложнее, но не важно. Важно что MI — это внутренняя реализация. Более того, то что вы называете MI — сегодня не более чем анахронизм и рудимент. Он давно заменен на NMI аka w-code, который глубоко закрыт, никогда не публиковался и существует сегодня только лишь в виде транслятора MI -> NMI для легаси кода в OPM.
CRTLF и CRTDSPF — это никакие не «удобные функции». Это конструкторы объектов конкретных классов. И эти классы разные, хотя и наследуют от общего предка. Короче говоря, система IBM i именно объектно ориентированная с точки зрения клиента. А уж какая там внутренняя реализация — это дело десятое.
Теперь к сути вопроса. Я думаю, вы путаете модель с внутренней реализацией. Мне ваши рассуждения напомнили следующую аналогию. Взять какой нибудь OOП язык (типа С++) для которого существует транслятор в процедурный (типа C). Вы смотрите в полученный C код и говорите: ага, да там же все плоские структуры, никакого наследования! Ну все, С++ никакой не объектно ориентированный.
Да, с точки зрения MI структура плоская. Вернее, там все сложнее, но не важно. Важно что MI — это внутренняя реализация. Более того, то что вы называете MI — сегодня не более чем анахронизм и рудимент. Он давно заменен на NMI аka w-code, который глубоко закрыт, никогда не публиковался и существует сегодня только лишь в виде транслятора MI -> NMI для легаси кода в OPM.
CRTLF и CRTDSPF — это никакие не «удобные функции». Это конструкторы объектов конкретных классов. И эти классы разные, хотя и наследуют от общего предка. Короче говоря, система IBM i именно объектно ориентированная с точки зрения клиента. А уж какая там внутренняя реализация — это дело десятое.
Да, книжка эта очень устарела и там уровень детализации низкий, в Fortress Rochester более глубоко написано. Ссылка. Это неплохое расширение первой. И про W-Code там тоже есть пара слов, сейчас Cube-3 кажется называется.
Видимо мы друг друга не поняли про MI, я когда говорил про него, имел в виду машинный интерфейс, доступный разработчику. Конкретно вот этот.
И он совсем не рудимент, документированный низкоуровневый интерфейс, когда хочется выжать максимум.
Про аналогию с транслятором C++ в Си я понял идею. Согласен, меня занесло в сторону. Но это не суть важно.
Видимо мы друг друга не поняли про MI, я когда говорил про него, имел в виду машинный интерфейс, доступный разработчику. Конкретно вот этот.
И он совсем не рудимент, документированный низкоуровневый интерфейс, когда хочется выжать максимум.
Про аналогию с транслятором C++ в Си я понял идею. Согласен, меня занесло в сторону. Но это не суть важно.
Я думаю, надо принципиально решать насчет продолжения использования 5250, а не пытаться искать заместители DDS. DDS отлично делает свое дело. Пример с результатами SQL запроса притянут искусственно. Пользователям никто не даст запускать непредсказуемые запросы. А тех-персоналу все эти «украшательства» не нужны.
Из PRG уже давно можно и в HTTP и во что угодно. Не хочется самим делать — есть куча готовых решений на рынке. Самое известное — profoundlogic.
Хотя сама идея поиграться с возможностью напрямую писать в 5250 поток, конечно, интересная.
Из PRG уже давно можно и в HTTP и во что угодно. Не хочется самим делать — есть куча готовых решений на рынке. Самое известное — profoundlogic.
Хотя сама идея поиграться с возможностью напрямую писать в 5250 поток, конечно, интересная.
Sign up to leave a comment.
О разработке интерактивных приложений под ОС IBM i (aka AS/400)