В рамках работ по "автоматизации процессов комплаенс-контроля" есть тема по поиску и фиксации совпадений по разным признакам между данными клиентов и данными "субъектов списков Росфинмониторинга" (разного рода террористы-экстремисты).

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

Нормализация адреса - приведение его к верхнему регистру, удаление лишних пробелов и удаление всяких "город", "г.", "улица", "ул." и т.п. Т.е. "Российская Федерация, г.Мухосранск, ул.Коммунистический тупик, д.13, кв.666" нормализуется в "МУХОСРАНСК КОММУНИСТИЧЕСКИЙ ТУПИК 13 666". "Элементом" адреса является отдельное слово (разделенное пробелами).

Дабы облегчить себе жизнь, есть т.н. "витрины адресов" - три таблицы. В первой содержится идентификатор клиента/субъекта + идентификатор адреса (для субъектов есть еще т.н. "ключевое слово" - элемент адреса субъекта, который реже всего встречается в витрине адресов клиентов). Во второй - набор связей адрес-элемент - идентификатор адреса + идентификатор элемента + номер элемента в строке адреса. И в третьей - список элементов - элемент + идентификатор элемента. Т.о. имеем две "витрины" - адреса клиентов и адреса субъектов.

На промсреде витрина адресов клиентов содержит порядка 96млн адресов. Витрина адресов субъектов - порядка 8тыс адресов. Сравнить надо всех со всеми - 768млрд комбинаций где-то...

RPG - это совсем не то, что приходит на ум обычному человеку. Это не только ролевые игры (Role Play Games), но еще и язык программирования. Здесь уже была статья Первый взгляд на RPG: оказывается, это не только ролевые игры, но она носила достаточно обзорный характер и не отражала современного состояния дел.

Будучи “широко распространенным в узких кругах” (достаточно сказать что более 80% кода на платформе IBM i написано и пишется именно на RPG), это язык практически не используется за пределами этой платформы.

Да, были попытки распространить этот язык за пределы его родной платформы - компания ASNA выпускала свою версию Visual RPG (в т.ч. и для .NET), но широкого распространения все это не получило.

Стоит сразу отметить, что RPG не является ЯВУ общего назначения. Это специализированный язык для работы с БД и коммерческих расчетов. Именно так его и надо воспринимать. И тут сравнения “что лучше - RPG или C/C++/C#/Rust/[подставить по вкусу]” бессмысленны. RPG создавался и развивался для решения вполне определенного класса задач и там он хорош - эффективен и прост. Для решения иных задач он будет крайне неудобным.

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

IBM i (AS/400) является "объектной" системой, построенной на концепции "все есть объект". У каждого объекта есть имя (может меняться в течении его жизненного цикла), тип (устанавливается единожды при создании и далее не меняется) и, в некоторых случаях, атрибуты ("подтип", аналогично типу, устанавливаются при создании и не могут быть изменены). Также объект может иметь текстовое описание (необязательное) - строка до 50-ти символов, которое может быть задано как при создании, так и после.

Действия, разрешенные над данным конкретным объектом, определяются его типом. Простейший пример - тут нельзя открыть программу в hex редакторе и поправить пару байтиков - такая операция просто не предусмотрена для объекта типа *PGM.

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

Цитата из предисловия к книге Френка Солтиса "Основы AS/400":

Более 6-ти лет занимаюсь разработкой под IBM i (бывшая AS/400). В основном, конечно, это работа с БД и разная бизнес-логика, но иногда приходится и что-то низкоуровневое писать.

Не так давно занимался разработкой удобного и простого в использовании API для работы с User Queue (есть на АС-ке такой системный объект - очередь *USRQ). И в заголовке извлекаемого из очереди сообщения есть такой параметр - message enqueue time (время размещения сообщения в очереди). Который описан как _MI_Time. Которое, в свою очередь, определено как