Да, книжка эта очень устарела и там уровень детализации низкий, в Fortress Rochester более глубоко написано. Ссылка. Это неплохое расширение первой. И про W-Code там тоже есть пара слов, сейчас Cube-3 кажется называется.
Видимо мы друг друга не поняли про MI, я когда говорил про него, имел в виду машинный интерфейс, доступный разработчику. Конкретно вот этот.
И он совсем не рудимент, документированный низкоуровневый интерфейс, когда хочется выжать максимум.
Про аналогию с транслятором C++ в Си я понял идею. Согласен, меня занесло в сторону. Но это не суть важно.
Не обязательно в моем случае должна быть одна команда типа 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-а, либо можно самому подкорректировать их усиление, создавая свою модель безопасности).
Тема огромная, все это в книге Солтиса описано. К сожалению книгу очень сложно достать, полной онлайн версии не нашел, только отрывки в виде страниц некоторых глав.
Прошу не подменять смысл сказанного.
Разговор об объектах 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-а.
Во-первых, АСОД это «собирательное понятие» и оно намного больше чем интерфейс. 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 — это просто адаптер над данными. Реализуя специальный интерфейс, можно написать запрос и на прямом доступе, если попали в такую ситуацию, что другого решения не видно.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Видимо мы друг друга не поняли про MI, я когда говорил про него, имел в виду машинный интерфейс, доступный разработчику. Конкретно вот этот.
И он совсем не рудимент, документированный низкоуровневый интерфейс, когда хочется выжать максимум.
Про аналогию с транслятором C++ в Си я понял идею. Согласен, меня занесло в сторону. Но это не суть важно.
Только очень сложно и неудобно работать с одной 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-а, либо можно самому подкорректировать их усиление, создавая свою модель безопасности).
Тема огромная, все это в книге Солтиса описано. К сожалению книгу очень сложно достать, полной онлайн версии не нашел, только отрывки в виде страниц некоторых глав.
Разговор об объектах 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-а.
Во-первых, АСОД это «собирательное понятие» и оно намного больше чем интерфейс. 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 — это просто адаптер над данными. Реализуя специальный интерфейс, можно написать запрос и на прямом доступе, если попали в такую ситуацию, что другого решения не видно.