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.
David is a Principal Software Engineer for PTC, Integrity Business Unit. He cut his teeth on the S/36 and has more than 25 years of experience on the IBM i / System i / iSeries / AS400. He primarily works in Java and ILE RPG specializing in cross platform integrations. David has received the COMMON Distinguished Service award and was named an IBM Power Systems Champion. David is an active volunteer with the American Diabetes Association's Tour de Cure fundraising bike ride. He is currently captain of Team RED Chicago. David runs and maintains midrange.com. His personal blog is Geeky Ramblings.