Команда IBM i (AS/400) работает локально, но не удаленно

Question

У меня есть служба Windows, написанная на VB.NET 2.0, которая подключается к серверу IBM AS/400. Запросы работают нормально, но когда я пытаюсь сделать что-то вроде удаления файла спула, я получаю ошибки. Например:

CPYSPLF FILE(PO630A) TOFILE(MPLCDATPAR/PO630APF) JOB(083064/ARUSER/POASYNCMON) SPLNBR(80) MBROPT(*REPLACE)

Выполнение этой команды с ExecuteNonQuery дает:

CPF3342 - Job not found 083064/ARUSER/POASYNCMON

Однако, если я запускаю эту же команду локально в AS/400, она работает просто отлично. Мы уже проверили разрешения. Что еще может вызвать сбой команды таким образом? Как я могу получить больше информации об ошибке или устранить ее?

РЕДАКТИРОВАТЬ: эта проблема (и многие другие) появилась, когда мы перенесли наш сервер (где работает служба.NET) из Windows Server 2003 в Windows Server 2008.

Answer 1

Как я могу получить больше информации об ошибке или устранить ее?

Прежде всего необходимо убедиться, что сервер IBM AS/400 [какой выпуск версии и уровень модификации, уровень технического обновления (TR) (если вместо IBM i), накопительный уровень PTF были опущены.?.?] Использовался для соединения тот же сервер, который использовался для вызова из командной строки; т. е. на сервере, где будет выполнен вызов командной строки для проверки работоспособности команды, найдите задание активного сервера, на котором CPF3342 еще виден в журнале.

Второе, что нужно сделать, - это получить список заданий из буфера, показывающий полную информацию о CPF3342 [и, возможно, любые предшествующие сообщения, которые могут быть связаны]. Если, например, сообщение на самом деле не является этим сообщением или не отправлено ожидаемой программой QSPCPYF, то, возможно, сразу же изменится направление расследования. То, что показано, очевидно, то, что представлено на клиенте, а не то, что пришло из журнала заданий сервера; Я считаю, что американское форматирование - "Job &5/&4/&3 not found". для которого сомнительно форматирование "CPF3342 - Задание не найдено &5/&4/&3".

Чтобы обеспечить наиболее подходящее сравнение с запросом, сделанным клиентом: • локальный пользователь, выполнивший вход для выполнения того же запроса, должен быть тем же пользователем, что и текущий пользователь активного задания, которое, как было установлено, обслуживает запрос клиента; локальный пользователь должен создать тот же список системных библиотек, что и активное задание, которое, как было установлено, обслуживает запрос клиента

Если такой инцидент повторяется или даже если тот же инцидент продолжается, то еще раз проверьте, что повторное создание все еще возможно, используя тот же интерфейс [т.е. условие \ сбой сохраняется], и снова убедитесь, что запрос командной строки успешен [т.е. подтверждается, что такой же запрос можно выполнить в командной строке]; и в соответствии с моим предыдущим комментарием, сначала убедитесь, что тот же сервер, найдя активную работу, которая регистрирует CPF3342. Сразу после этого:

• Собрать трассировку задания для запроса "Копировать буферный файл" (CPYSPLF); в случае сбоя проверьте наличие любых исключений \ условий прерывания [с или без сообщения в качестве сопровождающих данных трассировки], которые предшествуют потоку программ для выдачи сообщения CPF3342.

• Просмотрите журнал аудита на наличие T-AF или чего-то странного \ неожиданного в момент, близкий ко времени неудачного запроса; расширенный аудит должен быть установлен еще до подключения к серверу.

• Сравните эти данные в случае сбоя с данными, полученными в результате успешной обработки.

Хотя симптом [как слегка описано, без полного журнала заданий] возможность выхода из команды кажется отдаленным, трассировка выявила бы, если команда в любом сценарии была перехвачена точками командного выхода; их можно просмотреть отдельно [вместо поиска в трассировке] для любой Программы выхода, используя Работу с регистрационной информацией (WRKREGINF), чтобы просмотреть любые записи QIBM_QCA* в репозитории, чтобы выяснить, какие программы выхода могут повлиять на запрос команды CL. Но в IIRC данные трассировки показывают, какая команда была вызвана, поэтому трассировка также показывает, разрешены ли неквалифицированные запросы команд для различных * объектов CMD.