tofile 1.1.2 fails on iconv request

Discussion of the Co:Z Toolkit Dataset Pipes utilities
Post Reply
john.mckown
Posts: 48
Joined: Tue Jun 12, 2007 2:46 pm

tofile 1.1.2 fails on iconv request

Post by john.mckown »

I am trying to send a file from my Fedora Linux machine (fc20 x86_64) to a file in my ${HOME} directory on a z/OS 1.12 system. The transcript looks like:

$ echo "// SET SERVERIP=$(cat ~/zos/linux.ip.addr) ${isodate}" | /opt/dovetail/coz/bin/tofile -ssh tsh009@lih1 -L T /home/tsh009/bubba
tofile[D]: sourceCodePage defaulted to COZ_CLIENT_CODEPAGE=ISO-8859-1
tofile[D]: setTextMode: sourceCodePage=ISO-8859-1, targetCodePage=, linerule=flexible, technique=
tofile[T]: PosixFile: -> setTextMode(, ISO-8859-1, flexible, )
tofile[T]: PosixFile: <- setTextMode()
tofile[T]: <- tofile.parseArgs()
tofile(/home/tsh009/bubba)[T]: PosixFile: -> open("/home/tsh009/bubba", 0x0091, 0x30001B6)
tofile(/home/tsh009/bubba)[T]: PosixFile: -> configureTranslator(isWrite=true, fileCodePage=, streamCodePage=ISO-8859-1, technique=)
tofile(/home/tsh009/bubba)[W]: Translator: Unable to initialize iconv. sourceCodePage="ISO-8859-1", targetCodePage="IBM-1047"
tofile(/home/tsh009/bubba)[T]: PosixFile: <- configureTranslator()
tofile(/home/tsh009/bubba)[E]: PosixFile: PosixFile.open(): TranslateException: Unable initialize Translator, fallback to iconv failed., RC=121, Reason=-1037303780
tofile(/home/tsh009/bubba)[T]: PosixFile: <- open(fd=-1, filename=/home/tsh009/bubba, mode=0, errno=122)
tofile(/home/tsh009/bubba)[T]: CoZServerUtil: -> writeErrorStatusPacket(tofile(/home/tsh009/bubba): msg="Error opening output file", rcvd=0, sent=0, rc=103, emsg="EDC5122I Input/output error. (errno2=0xC22C001C)", errno=122, errno2=0XC22C001C)
tofile-client(21506)[E]: tofile(/home/tsh009/bubba): Error opening output file, rc=103, msg="EDC5122I Input/output error. (errno2=0xC22C001C)"
tofile(/home/tsh009/bubba)[T]: CoZServerUtil: <- writeErrorStatusPacket()
tofile(/home/tsh009/bubba)[T]: <- tofile.run()
tofile(/home/tsh009/bubba)[T]: -> ~tofile()
tofile(/home/tsh009/bubba)[T]: <- ~tofile()
tofile(/home/tsh009/bubba)[D]: tofile current thread cpu time: 0.005512 secs
tofile(/home/tsh009/bubba)[D]: Exiting main(), rc=103
tofile-client(21506)[E]: server exit_code=103
tofile-client(21506)[E]: transmitted byte counts do not match, server sent/received = 0/0, client received/sent = 0/49


If I do a binary transfer, it works just fine. tofile on Linux is 1.1.2. tofile on z/OS is 3.0.0

z/OS:
tofile -v
3.0.0 2014-11-12
uname -a
OS/390 LIH1 22.00 03 2096
bpxmtext 115C006C
BPXVFRPH 08/27/08
JRFileNotThere: The requested file does not exist

Action: The service cannot be performed unless the named file exists.

Linux:
tofile -v
1.1.2 2013-03-19
uname -a
Linux it-johnmckown-linux 3.17.2-200.fc20.x86_64 #1 SMP Tue Nov 4 18:04:56 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
john.mckown
Posts: 48
Joined: Tue Jun 12, 2007 2:46 pm

Re: tofile 1.1.2 fails on iconv request

Post by john.mckown »

I didn't notice the source page being ISO-8859-1 instead of ISO8859-1. If I enter the Linux command: export COZ_CLIENT_CODEPAGE=ISO8859-1 before doing the tofile, it works fine. I don't know where the ISO-8859-1 is coming from. The iconv on z/OS 1.12 (and 2.1) will accept ISO8859-1 but not ISO-8859-1.
john.mckown
Posts: 48
Joined: Tue Jun 12, 2007 2:46 pm

Re: tofile 1.1.2 fails on iconv request

Post by john.mckown »

Don't you just hate it when you find the "problem" a short time _after_ asking for help? Apparently this is a related to the locale on my Linux system. I have it set up as the "C" language, but looking at:

$locale -m | grep 8859
ISO-8859-1
ISO-8859-10
ISO-8859-11
ISO-8859-13
ISO-8859-14
ISO-8859-15
ISO-8859-16
ISO-8859-2
ISO-8859-3
ISO-8859-4
ISO-8859-5
ISO-8859-6
ISO-8859-7
ISO-8859-8
ISO-8859-9
ISO-8859-9E
ISO_8859-1,GL
ISO_8859-SUPP

Shows the problem. No ISO8859-1 in that, but the problematic ISO-8859-1.
john.mckown
Posts: 48
Joined: Tue Jun 12, 2007 2:46 pm

Re: tofile 1.1.2 fails on iconv request

Post by john.mckown »

Well, I'm still running off at the keyboard (vice mouth). It turns out that ISO8859-1 is _NOT_ valid at all according to IANA (ref: https://www.iana.org/assignments/charac ... sets.xhtml) ISO-8859-1 has some aliases, but ISO8859-1 is not one of them. Too bad IBM (and Microsoft who apparently also uses ISO8859-1 at times) don't need to be bothered with standards. I'm going to use the COZ_CLIENT_CODEPAGE environment variable and mutter under my breath about IBM and MS.

Penguinista and Proud!
John McKown
dovetail
Site Admin
Posts: 2022
Joined: Thu Jul 29, 2004 12:12 pm

Re: tofile 1.1.2 fails on iconv request

Post by dovetail »

What is happening is that the default client codepage is taken from the current locale. This can be overridden using the *client* environment variable: COZ_CLIENT_CODEPAGE).
The actual codepage conversion is done on z/OS.

You can also add name mappings by using the following z/OS environment variable:
export COZ_TRSUB_ISO-8859-1=ISO8859-1

Also, the iconv reason code (which we should really be printing in hex) is this:

zos$ bpxmtext C22C001C
JrEdcIcntEinval16: The from CCSID cannot be determined.
Action: The from converter name is invalid. Fix it and try again.

And we can confirm that z/OS iconv_open() doesn't know about ISO-8859-1 -

zos$ EDC_ADD_ERRNO2=1 iconv -f ISO-8859-1 -t IBM-1047 ascii_file | wc
iconv: Conversion from codeset "IBM-1047" to "ISO-8859-1": EDC5121I Invalid argument. (errno2=0xC22C001C)

It would be nice if someone would report this as a bug to IBM.

Perhaps we should patch up names "ISO-8859-*" to ISO8859-*" ?
john.mckown
Posts: 48
Joined: Tue Jun 12, 2007 2:46 pm

Re: tofile 1.1.2 fails on iconv request

Post by john.mckown »

Thanks for the update. I'm using the COZ_CLIENT_CODEPAGE on my Linux system. I also reported this error on IBM's part on the MVS-OE forum, just so that others would know of it. I no longer put in problem reports to IBM because I no longer have access to IBMLink (false economy, IMO) and so cannot open an ETR or PMR on line. As to whether to put in a "fix" in your code to change ISO- to ISO if iconv() fails, I defer that decision to your greater knowledge. "It is better to light a flamethrower than curse the darkness" ... or something like that.
Post Reply