#db2 #ibm-midrange #rpgle #audit-trail
#db2 #ibm-средний уровень #rpgle #аудиторский след
Вопрос:
Эй, надеюсь, кто-нибудь сможет помочь или, по крайней мере, указать мне правильное направление.
Я хочу добавить некоторые поля аудита «Генерировать всегда» в некоторые из наших новых таблиц, чтобы помочь в процессе аудита, из того, что я обнаружил, в этом поле «генерировать всегда» можно использовать только специальные регистры.
С сайта IBM я нашел большую часть того, что нужно, но в частности одно поле, которое мы всегда используем, — это Имя программы. (Т. е. какая программа внесла обновление в таблицу)
Хоть убей меня, я не могу этого понять. В настоящее время мы используем структуру данных о состоянии программы и указываем там это значение, но это не соответствует цели, так как другие 6 полей аудита всегда будут заполняться, а это-нет.
Я также устал от следующего, но они предназначены для процедур и функций SQL и не подходят, если программа RPG выполняет обновление/вставку
SYSIBM.ROUTINE_SCHEMA SYSIBM.ROUTINE_SPECIFIC_NAME SYSIBM.ROUTINE_TYPE CREATE TABLE TSTAUDIT.policyInfo ( policy_id CHAR(4) NOT NULL, coverage INT NOT NULL, sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN , sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END , Change_Type CHAR(1) GENERATED ALWAYS AS (DATA CHANGE OPERATION), Change_User VarCHAR(128) GENERATED ALWAYS AS (SESSION_USER), Change_JobName VARCHAR(28) GENERATED ALWAYS AS (QSYS2.JOB_NAME) , Change_APPLNAME VARCHAR(255) GENERATED ALWAYS AS (CURRENT CLIENT_APPLNAME), Change_RSCHEMA VARCHAR(128) GENERATED ALWAYS AS (SYSIBM.ROUTINE_SCHEMA), Change_RName VARCHAR(128) GENERATED ALWAYS AS (SYSIBM.ROUTINE_SPECIFIC_NAME), Change_RType CHAR(1) GENERATED ALWAYS AS (SYSIBM.ROUTINE_TYPE)); Я также изучил (ТЕКУЩЕЕ ИМЯ КЛИЕНТА) (ТЕКУЩИЙ ИДЕНТИФИКАТОР ПРОГРАММЫ КЛИЕНТА) (ТЕКУЩИЙ ИДЕНТИФИКАТОР ПОЛЬЗОВАТЕЛЯ-КЛИЕНТА) (ТЕКУЩЕЕ ИМЯ КЛИЕНТА_WRKSTN)
Но они должны быть установлены для каждого соединения, что означает, что каждая новая вызываемая программа должна будет вызывать процедуру SYSPROC.WLM_SET_CLIENT_INFO (или вызывать соответствующий API), добавляя дополнительные накладные расходы в процесс.
Любой совет был бы очень признателен.
***** Дополнительная информация
Я забыл упомянуть, что это работает для входящих подключений, потому что эти ТЕКУЩИЕ поля CLIENT_ могут быть заданы как часть строки подключения.
Проблема, с которой я сталкиваюсь, связана с внутренними выполняемыми заданиями (интерактивными и пакетными), где мне пришлось бы устанавливать их для каждой вызываемой программы.
Теперь это не такая большая проблема, так как мы можем сделать это стандартом при использовании этих файлов, эти поля должны быть установлены, хотя проблема, которую я обнаружил сейчас, заключается в переключении между программами. Если программы A и B обе записывают в файл X. Когда запускается программа A, она устанавливает поле CLIENT_PROGRAMID, выполняет некоторые действия, а затем вызывает программу B. Программа B устанавливает поле CLIENT_PROGRAMID и делает то, что необходимо. Когда управление возвращается в программу A, CLIENT_PROGRAMID по-прежнему остается «ПРОГРАММОЙ B», что означает, что любые обновления, выполняемые Программой A, будут неверно отображаться каждый раз, когда она изменяет данные после вызова программы B.
Очень надеюсь, что это не сбивает с толку.
Комментарии:
1. «дополнительные накладные расходы на процесс» — насколько велики накладные расходы (по сравнению с общим временем, необходимым для создания нового сеанса), которые вызывают беспокойство?
2. Таким образом, «нового подключения» нет, аудиты, о которых я говорю, — это скорее интерактивные сеансы и пакетные процессы, которые выполняются на самой коробке. Извините, что я должен был упомянуть об этом. Поэтому, когда я вхожу в систему, они могут использовать различные варианты для внесения обновлений. Таким образом, одно соединение просто разные процессы.
3. Итак, вы согласны с добавлением этой информации в строку подключения, когда у вас есть новое соединение, но не хотите вызывать api, когда нет внешнего подключения? Похоже, именно так это и должно быть сделано, и накладные расходы будут одинаковыми в любом случае.
4. Дело не в том, что мы не хотим этого делать, если вы прочтете дополнительную информацию, добавленную к вопросу, вы увидите, что есть еще одна проблема с установкой этого значения. Должен быть способ проставить отметку в этом поле при изменении таблицы, если вы посмотрите на журналы, в которые записываются данные, чтобы они были доступны в любое время. Просто хочу посмотреть, не знает ли кто-нибудь, как мы можем его использовать.