I have a Windows service written in VB.NET 2.0 which connects to an IBM AS/400 server. Queries work fine, but when I try to do something like deleting a spool file, I get errors. For example:
CPYSPLF FILE(PO630A) TOFILE(MPLCDATPAR/PO630APF) JOB(083064/ARUSER/POASYNCMON) SPLNBR(80) MBROPT(*REPLACE)
Running this command with ExecuteNonQuery yields:
CPF3342 - Job not found 083064/ARUSER/POASYNCMON
However, if I run that same command locally in AS/400, it works just fine. We already checked permissions. What else could be causing the command to fail this way? How can I get more information about the error, or go about troubleshooting this?
EDIT: This problem (and a lot of other ones) appeared when we migrated our server (where the .NET service runs) from Windows Server 2003 to Windows Server 2008.
How can I get more information about the error, or go about troubleshooting this?
The first thing is to verify that the IBM AS/400 server [what OS Version Release and Modification level, Technical Refresh (TR) level (if instead IBM i), Cumulative PTF level were all omitted.?.?] used for the connection is the same server used to perform the command-line invocation; i.e. on the server where the command-line invocation will be made to verify the command is functional, find the active server job in which the CPF3342 is still visible in the log.
The second thing to do is to get the spooled joblog showing the full details of the CPF3342 [and possibly any preceding message(s) that might be related]. If for example the message is not actually that message or is not sent by the expected program QSPCPYF, then immediately the direction of investigation probably would change. What is shown is apparently what is presented at the client, not what came from the server joblog; the USEnglish formatting I believe is "Job &5/&4/&3 not found." for which the formatting "CPF3342 - Job not found &5/&4/&3" is suspect.
To ensure the most appropriate comparison to the request made from the client: • the local user that is signed-on to perform the same request should be the same user as the Current User of the active job found to be servicing the client request • the local user should establish the same System Library List as the active job found to be servicing the client request
If such an incident recurs or even if the same incident persists, then verify the once again the re-create is still possible using the same interface [i.e. the condition\failure persists] and again verify the command-line request is successful [i.e. the circumvention is confirmed, that the same request is possible to be performed at the command-line]; and according to my earlier comment, first ensuring the same server by finding the active job that logs the CPF3342. Immediately afterward:
• Collect a job trace for the Copy Spooled File (CPYSPLF) request; for the failing case, review for any exception\interrupt conditions [with or without a message as accompanying trace data] that precede the program flow for the issuance of the msg CPF3342.
• Review the audit log for any T-AF or anything odd\unexpected at very close to the time of the failing request; expansive auditing should have been established since before the connection to the server.
• Contrast those data collections of the failing case with the same data taken from the successful processing.
Although the symptom [as lightly described, without the full joblog] the possibility of command-exits seems remote, the trace would reveal if the command in either scenario were intercepted by the Command Exit points; these can be reviewed separately [rather than looking in the trace] for any Exit Program, using the Work With Registration Information (WRKREGINF) to review any QIBM_QCA* entries in the repository for what exit programs might impact the CL Command request. But IIRC the trace-data shows which command was invoked, so the trace would also reveal if the unqualified command requests resolved to different *CMD objects.