If your java application starts encountering a ExtendedIOException error while trying to access files in the IFS, check to see if you’ve got a 3rd party security exit program in place.
I just had a rather frustrating diagnostic problem with a customer … they installed a recent upgrade to our product and the java application server wouldn’t start anymore.
After adding a JT400 trace to the servers start-up I saw that the ExtendedIOException we were getting had a reason code of 4636. Unfortunately, the JT400 routine didn’t deal with that code.
After a bit of digging around we determined that the security exit program (Power Lock in this case) was blocking the application server’s user id from accessing the ‘file server’ server.
We added an exception to the Power Lock configuration and it started working fine.
One of the problems we had with diagnosing this problem was the fact that there was no specific error indicating that the server’s request was rejected for a specific reason.
The return code (which was only revealed after putting the JT400 code in trace mode) was totally meaningless. A Google search only returned one meaningful hit (from 2007).
It was only after the customer remembered they had Power Lock active that we were able to figure out that this was the cause of the problem.
Welcome to JT400.
So imagine compounding the problem by having JT400 compiled into .Net format 🙂
We’ve had a couple issues where the customer was shutting down their File Server service, which didn’t show its face until we did the same type of low level trace.