During a recent IBM i high availability exercise, we found that we couldn’t use FTP on our Capacity BackUp server (CBU). Every time, we tried to start a FTP session to the CBU, the server would close the session and we weren’t able to transfer our files. Here’s what happened.
The CBU had recently been updated to IBM i 6.1 from i5/OS V5R4, and this was the first time we tried FTPing to the updated box. When we started an FTP session, it would refuse the connection and put the following CPI93B9 error message in the QSYSOPR message queue.
Software problem data for QTMFSRVR has been logged. Refer to help text for additional information
It would also log a software problem entry in the Work with Problems screen (WRKPRB). The problem entry had a system reference code of B900FDC7 and a symptom string of ‘5761 F/QTMFSRVR RC09010005’.
Talked to IBM and it wasn’t an operating system problem or a bug or corruption in our TCP/IP utilities program. It was the inactivity timeout that we had set for our FTP server. IBM advised us to look at our FTP attributes by running the Change FTP Attributes command (CHGFTPA) and pressing F4 to view all the attributes.
When we did that, we found that our Inactivity timeout parameter (INACTTIMO) was set to 999999999. The highest inactivity timeout parameter that IBM i 6.1 FTP will accept is 315680096. When FTP saw the large timeout, it freaked and ended the connection. We changed the inactivity timeout to 315680095 (one less than the FTP limit) and FTP immediately started working again after we restarted the IBM i FTP server.
IBM didn’t tell us why this is happening but the only thing I can figure is that the IBM i 6.1 FTP server is less forgiving of large timeout parameters than the i5/OS V5R4 FTP server was. That’s the only reason I can come up with for why this happened after we upgraded to i 6.1.
So if you run into this issue, try decreasing your FTP server’s inactivity timeout parameter to a value less than 315680096 and restart the server. That might solve the issue.
The funny thing is that this isn’t the first FTP failure we ran into after upgrading an i5/OS V5R4 box to i 6.1.1. Last month, I documented another situation where FTP sessions on my production box stopped working because IBM changed the default FTP send and receive mode to Extended Passive Mode (ESPV). If you’re experiencing that problem and looking for the fix, check out my blog post on that FTP problem by clicking here.
**************************************************
Follow Joe Hertvik on Twitter @JoeHertvik. You can also add Joe to your professional network on LinkedIn by clicking here.
Hi, Joe. Looking for a solution for this error found this post. On my case, the error CPI93B9 was generated by the parameter ALWSSL set to *yes. Just change this to *No and ftp work fine. Thanks