Задание сервера (например, экземпляр сервера базы данных для ODBC / JDBC) выполняется под системным профилем пользователя. Для сохраненных процедур пользователь системы обычно будет QUSER. Объекты, созданные в задании, обычно принадлежат пользователю задания.
Задания сервера обычно выполняют работу от имени других пользователей. Вы сообщаете серверу, какой пользователь, когда вы устанавливаете соединение. (И обратите внимание, что в течение своего срока жизни задание на сервере может работать от имени разных пользователей.)
В частности, для буферизованного вывода, это проблема, потому что подсистема спулинга работала дольше, чем у нас был «Интернет» и до того, как у нас было значительное количество пользователей, подключающихся к удаленным базам данных. Поведение перехода от пользователя к пользователю просто не является частью структуры подсистемы спулинга, и поставщик, такой как IBM, не может определить, когда буферный файл должен принадлежать конкретному пользователю задания или пользователю соединения. (И спулинг не является основным элементом соединений с базой данных.)
IBM адаптировала способ связывания вывода с пользователями, установив по умолчанию вывод «переключенных пользователей» для сбора в задания с именем QPRTJOB , но оно не совсем соответствует тому, как вы Я хочу, чтобы более поздняя RPG-программа обрабатывала вывод.
Однако, если вы создаете сохраненный процесс, который генерирует буферный вывод, он может выбрать, кому принадлежит выход, и тем самым решить оставить его в рамках той же работы. Рассмотрим эти примеры CALL, которые можно вставить в навигатор iSeries «Выполнить сценарии SQL»:
call qsys2.qcmdexc ('OVRPRTF FILE(*PRTF) SPLFOWN(*JOB) OVRSCOPE(*JOB)' , 48);
call qsys2.qcmdexc ('DSPMSGD RANGE(CPF9899) MSGF(QCPFMSG) OUTPUT(*PRINT)' , 51);
call qsys2.qcmdexc ('DLTOVR FILE(*PRTF) LVL(*JOB)' , 28);
Если вы запустите их как набор, они создадут буферные выходные данные, показывающие атрибуты описания сообщения для CPF9899. Если вы проверите впоследствии, вы увидите, что QUSER теперь владеет буферным файлом с именем QPMSGD и находится в задании QZDASOINIT, которое обрабатывает ваши запросы к удаленной базе данных. Программа RPG в этом задании может легко найти буферный файл "* LAST" в этом случае. Кроме того, если вы удалите первый и последний CALL и теперь запустите только средний, вы обнаружите, что у вас есть следующий буферный файл.
(QUSER является IBM по умолчанию. Если ваша система использует другой профиль пользователя, замените этого пользователя на «QUSER».)
Рекомендация:
Измените ваш SP для выдачи соответствующей команды OVRPRTF перед буферизацией вывода, который вам нужно захватить в задании, и для выдачи DLTOVR после генерации вывода.
Вы можете использовать команды, подобные приведенным здесь, для создания процедуры тестирования. Поэкспериментируйте с другими настройками OVRSCOPE () и с FILE (* PRTF) или со специально названными файлами. Кроме того, создайте выходные данные до и после команд переопределения, чтобы увидеть, как они ведут себя по-разному.
Имейте в виду, что задание сервера может обрабатывать другого пользователя после завершения вашего SP (или другой SP может быть вызван позже в работе), поэтому вы должны быть уверены, что DLTOVR выполняется. (Это одна из причин держать его близко к OVRPRTF.)