2015-05-08 33 views
0

我有一個用VB.NET 2.0編寫的連接到IBM AS/400服務器的Windows服務。查詢工作正常,但是當我嘗試執行類似於刪除假脫機文件的操作時,出現錯誤。例如:IBM i(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,它工作得很好。我們已經檢查了權限。還有什麼可能導致命令以這種方式失敗?我怎樣才能獲得有關錯誤的更多信息,或者去解決這個問題?

編輯:這個問題(和許多其他的人)的出現,當我們遷移我們從Windows Server 2003服務器(其中.NET服務運行)到Windows Server 2008

回答

1

我怎樣才能獲取有關錯誤的更多信息,或者進行故障排除?

的第一件事是驗證IBM AS/400服務器 [什麼操作系統版本發佈和修改級別,技術更新(TR)級(如果不是IBM我),累積PTF級別都用於連接的是用於執行命令行調用的相同服務器;即在將執行命令行調用以驗證命令是否有效的服務器上,查找活動服務器作業,其中CPF3342在日誌中仍可見。

第二件要做的事情是讓假脫機作業日誌顯示CPF3342的全部細節[以及可能相關的任何前面的消息]。例如,如果該消息實際上不是該消息或者不是由期望的程序QSPCPYF發送的,那麼立即調查的方向可能會改變。顯示的內容顯然是在客戶端呈現的內容,而不是來自服務器工作日誌的內容;我相信USEnglish格式是「找不到。」找不到& 5/& 4/&。「對此格式「CPF3342 - 找不到作業」& 5/& 4/& 3「是可疑的。

爲了確保最合適的比較,從客戶提出的要求: •已簽名上執行相同的請求,本地用戶應該是相同的用戶活動作業的當前用戶發現服務客戶請求 •本地用戶應建立與發現爲客戶請求服務的活動作業相同的系統庫列表

如果發生此類事件或者即使同一事件持續存在,然後再次驗證重新創建仍然可以使用相同的界面[即條件\失敗依然存在],並再次驗證命令行請求是否成功[即該規避已被證實,相同的請求可能在命令行執行];並根據我先前的評論,通過查找記錄CPF3342的活動作業首先確保相同的服務器。緊接着:

•收集複製假脫機文件(CPYSPLF)請求的作業跟蹤;對於發生故障的情況,請檢查發出msg CPF3342的程序流程之前的任何異常\中斷條件[帶或不帶消息作爲伴隨跟蹤數據]。

•在非常接近失敗請求時間的時候,檢查審覈日誌中是否有任何T-AF或奇怪的\意外事件;應該在連接到服務器之前建立廣泛的審計。

•將失敗案例的數據收集與取自成功處理的相同數據進行對比。

儘管症狀[如上所述,沒有完整的工作日誌]出現命令退出的可能性似乎很小,但跟蹤將顯示任一情況下的命令是否被命令退出點攔截;可以使用註冊信息處理(WRKREGINF)來查看存儲庫中的任何QIBM_QCA *條目,以查看哪些退出程序可能會影響CL命令請求,這些可以單獨進行審查[而不是查看跟蹤中的任何退出程序]。但是IIRC跟蹤數據顯示哪個命令被調用,因此跟蹤還會顯示是否將非限定命令請求解析爲不同的* CMD對象。

相關問題