ibmi_spooled_file_data fails on iconv

[spirjade]

Hello,

Am using this ansible module to get spool data but it fails with error "Error occurred when run command : iconv -f IBM-000 -t UTF-8 /TMP/<>.TXT, error:cannot open converter

Anyone faced such an error on ansible module for ibmi. Any advice?

Thank you in advance

[changlexc]

ansible module calls the iconv command underneath to convert a specific CCSID file to UTF-8 so python can read. I think you can test the iconv command directly in QSH console to see why it has error.

[spirjade]

Already tried. I don't get any error when I run in QSH. only error with ansible

[changlexc]

Could you please tell me the recreate steps so I can debug it on my system?

[cmh716]

I have the same issue. When running via playbook it'll fail on something like this:

iconv -f IBM-000 -t UTF-8 /tmp/somefile.txt and we'll get "cannot open converter"

The cause is the IBM-000 in this parm, which should usually be IBM-037. If you go into QSH and paste the same command, it works fine. BUT, if you SSH into the IBMi and run the command, you'll get the same error IF you are using the bash shell, which is the default. This is because the ibmi_spoolfile_data python program is doing:

attr /tmp/thefilename.txt -- but if this is run via bash shell, nothing is returned. This only seems to work via KSH

If you replace IBM-000 to IBM-037, it works fine via SSH.

The issue can be corrected by modifying sshd_config and entering:

ibmpaseforishell /QOpenSys/usr/bin/ksh and restart SSHD

But, this is a global, potentially risky change for 400+ LPARs. I tried modifying just the user's PASE shell via: QSYS2.SET_PASE_SHELL_INFO, but that did not work. Can you suggest a solution that doesn't require a global sshd_config change?

Not as elegant, but DSPATR OUTPUT(*PRINT) | grepped on Coded can return the CCSID too. I have just opened an IBM case on this too: TS008646754

Thank you.

[pengzengyufish]

@cmh716 Thank you very much for your investigation. It's very helpful. We are looking on this. I will update if we have any progress. Thank you.

[pengzengyufish]

@cmh716 @spirjade We found the root cause for another customer, he doesn't use STRTCPSVR or QSH to start the SSHD, but use QP2SHELL. QP2SHELL does NOT set up standard descriptors properly. This can cause sporadic failures.

Please double check your SSH on IBM i, end this, then restart using STRTCPSVR or QSH.

[cmh716]

Thank you, This was the cause of the issue. Once starting via QSH, it works.