One that I’m not sure I want to admit how long it took me to find the answer, so I figure instead I’ll tell you all a story and hopefully it’s one more link out there with the solution.

A bit of background, for one of our customers we have a utility to handle passthrough between their live and development/test partitions. Their dev partition isn’t on the network proper so you have to telnet across, to avoid user having to sign in twice the passthrough offers a username & password to get them into the relevant test menu. This has been running for many moons at this point and working smoothly.

I wanted to do something similar with one of my internal servers, we’re building a test environment and I want to make sure it can’t talk to the outside world so great I have a program to handle my passthrough! Naturally it didn’t work….

The error message said:

Message ID . . . . . . :   CPIAD06       Severity . . . . . . . :   10       

Message type . . . . . :   Information                                       

Date sent  . . . . . . :   01/06/20      Time sent  . . . . . . :   12:52:11 

Message . . . . :   Password not correct for user profile.                   

Cause . . . . . :   The password received for user SHEARSD was not correct.  

Recovery  . . . :   Correct the password and try the request again. If the   

  problem continues, verify that the current system password level (system   

  value QPWDLVL) is compatible with the level being used on the client system.

   If they are compatible, contact your system administrator.                

Well ok, but I’ve just logged in using the credentials (telnet without then manual sign-on) so clearly the password is correct.

Into my system values I go, making sure I’ve set QRMTSIGN to verify instead of frcsignon on the receiving partition, apparently my master partition was on password level 1 and the dev partition was on 2 so let’s try changing that. My customer has never moved off level 0 and I really don’t fancy trying to backtrack to that on my test system to get this working.

Much cursing at Dr. Google for not giving me an answer later, I found the right combination of terms to get directed to a page on the IBM website: https://www.ibm.com/support/pages/bypass-sign-fails-telnet-ibm-i-ibm-i

* If OS/400 on the remote system is at release level V4R5 or earlier, specify *DES7.
* If OS/400 on the remote system is at release level V5R1 or later, and QPWDLVL has a value of ‘0’ or ‘1’, specify *DES7.
* If OS/400 on the remote system is at release level V5R1 or later and QPWDLVL has a value of ‘2’ or ‘3’, specify *SHA1.

Naturally as the utility had only ever run on the customer server, where both partitions are on level 0, it had never been setup to account for different encryption keywords (RMTPWDENC) which defaults to *DES7

Once the utility was amended to allow the keyword, surprise now it works! There are a few morals of the story you could take away:

1. Get the customer onto a proper level of security, then you would’ve hit the problem sooner.
2. Practise your search engine skills, as you must invoke the right terms to get the answer you seek.
3. Never setup your utility to just use the keywords you “think” you need, never know when you’ll trip over a new one.

Hopefully this helps one person out there not waste as much time as I did to get to the end zone.