Для информации.
Новая RU-операция манипулирования сплитами RUSP работает неправильно при использовании в отношении таблицы ORT (функции PORT/POGRT). Точнее, воспользоваться операций RUSP можно только один раз.
Представим такие действия. У нас есть ORT, загруженной функций IMPRT O, откуда нам нужно перенести в IT определенный ВО. Перенос нужно выполнить в контексте определенного сплита, например CNTR2. Правило обработки выглядело так
Code:
ELIMI *
RESET 2
Делаю замену на RUSP
Code:
RUSPEO* E-elimi, O-мы работаем в контексте ORT
RUSPRO2 R-reset
Второй вызов RUSP работает ошибкой. В чем проблема? Если раньше мы просто работали со сплитами 1-3, то теперь требуется операция распаковки сплитов. Распаковка требует указания таблицы RUCNX, а если мы работаем с ORT, то нужно использовать таблицу ORUCNX. Таким образом, для распаковки появляется понятие контекста.
Операция RUSP начинается с распаковки текущей записи OT и заголовка IT, где в момент работа PORT находится состояние записи на момент начала работы правила (именно по ней происходит reset). Для распаковки OT и IT нужно указать контекст ORUCNX (за это отвечает буква O при вызове RUSP). Отмечу, что этот контекст получается единым и для OT, и для IT.
Далее, собственно выполняется работа над сплитами. Затем запись OT нужно упаковать. И это выполняется уже относительно RUCNX.
При следующем вызове RUSP нужно снова начинать с распаковки OT/IT. Повторю, контекст распаковки этих записей может быть только один общий, либо RUCNX, либо ORUCNX. Но мы помним, что в прошлом вызове RUSP упаковали OT относительно RUCNX, тогда как контекст для IT не изменился - ORUCNX. Это значит, что распаковка одной из записей будет происходить неверно, а значит определение сплитов ID_1/ID-8 будет происходить с ошибкой.
Ошибка может сопровождать появлением сообщения "Inconsistent content in RUCNX and payroll results table", но это происходит только при отсутствии подходящей записи в указанном контексте RUCNX/ORUCNX. Зачастую заполнение этих таблиц близкое, поэтому добиться появления сообщения сложно. Мне пришлось создать пример с выходом из состояния совместимости заполнения RUCNX (переполнил RUDAT), чтобы гарантировано получить такое сообщение. Тем не менее, если сообщения нет, это еще не значит, что операция работает без ошибок.
Таким образом, второй вызов RUSP в контексте ORT работает неправильно. Аналогичная ситуация возникает после использования операции RUOC1. Там также конечная упаковка записи OT происходит относительно RUCNX. Это значит следующий вызов RUSP будет произведен с ошибкой.