When I try to use fromdsn-ssh from Windows with -t iso8859-1, the command fails, and I get message CEE3728S, which says a function has been used which is not supported by this release of Lamguage Environment.
Further details include translate exception: CCSID not supported by CUNLCNV, RC=8, REASON=3.

From entrypoint fromdsn: Entry offset is +00000232

What release of Z/OS is necessary to support this function in dataset pipes?

Will,

Thanks for reporting this problem.

The fromdsn and todsn commands for z/OS were built in a z/OS 1.7 system, with the C++ compiler options:

-W "c,TARGET(zOSV1R4),ARCH(3),TUNE(5)"

So, they should run on zOSV1R4 or later.

However, we have found that IBM introduced some incompatibilities in the C++ compiler in 1.6 that forces you to have some LE Compatability PTFs on pre-1.6 systems. (So much for the "TARGET" compiler option

I can't be certain, but I would guess that this is your problem.
The PTFS are:

UK03870 for z/OS 1.5, or
UK03869 for z/OS 1.4

So, please check to see if you have those on. If you do, please let us know and we will try to work with you to figure out what else could be wrong.

The error that you are getting from the CUNLCNV service (the high-performance z/OS Unicode Conversion service) is probably
because you don't have it configured/enabled. It is configured by default starting with z/OS 1.6, or if you have a later version of DB2 it will be configured as part of DB2 installation.

The manual SA22-7649 "Support for Unicode: Using the z/OS Conversion Service", has information on setting this up. This is a very nice / high performance service for doing codepage translation, but we were not really sure how many shops don't have it enabled. I'm wondering if we shouldn't offer a fallback method for converting codepages... how many other shops out there at z/OS 1.4 or later don't have this running?

Needless to say, since these tools are new, we are very interested in hearing of any problems or feature requests. We have gotten emails, but this forum is the best venue since it allows others to benefit from previous problem reports and solutions.

So, thanks for reporting this; please post back if you need any additional help.

Kirk Wolf

Kirk,

Thanks for the response. I'll look into getting the LE PTF installed. The person who would handle that is out sick. So I won't be able to test this again for a while.

I don't know if Purdue is typical, but we have not had to do anything yet to work with Unicode.

Thanks,

Will

Hi, I'm having a similar problem under z/OS 1.6 using todsn-ssh

J:\tmpinst>copy ta00405.txt con: | todsn-ssh -pw xxxx t330@mvsoz.hiw.com -s iso
8859-1 -r ta00405.ptf
++APAR(TA00405)
DESCRIPTION(PREVENT S0C1 IN TSFADGAS)
REWORK(20062430)
.
++VER(Z038) FMID(ATSF210) .
++ZAP(TSFADCSB) DISTLIB(ATSFMOD1) .
NAME TSFADCSB
VER 0C54 A72400AA
REP 0C54 A7F400AA
IDRDATA TA00405
todsn: TranslateException: CCSID not supported by CUNLCNV, RC=8, Reason=3

Any ideas?

There may be something wrong with the z/OS Unicode Conversion Services in your environment, or your default process codepage may not be setup right.

First, find out what CCSIDs that you are trying to use, by adding the "-vv" switch as the first argument after the hostname in "todsn-ssh".

For example:
copy ta00405.txt con: | todsn-ssh -pw xxxx t330@mvsoz.hiw.com -vv -s iso
8859-1 -r ta00405.ptf

To stderr, you should get a message like this:

RecordExtractor.initialize(): sourceCodePage="iso8859-1"(819), targetCodePage="IBM-1047"(1047), lineTermRule=5, roRule=0, fixedLenRecords=false

This tells you that you are converting from CCSID(819) to CCSID (1047).

If you are not getting IBM-1047 as the target, then your user/process default codepage is set to something else. If that's the case, try adding "-t ibm=1047" to see if that works. The "LANG=C" environment variable is typically used to enable IBM-1047 as the default codepage. This is documented in the USS Customization manual.

Then, you can do the "DISPLAY UNI,ALL" console command to verify that the IBM Unicode conversion services are enabled.

You can also look at the messages at IPL to see:
CEE3739I LANGUAGE ENVIRONMENT INITIALIZATION COMPLETE
IEE252I MEMBER CUNUNIXX FOUND IN SYS1.PARMLIB
CUN2005I CONVERSION ENVIRONMENT SUCCESSFULLY INITIALIZED

This will tell you what CUNUNIxx parmlib member is being used.
Its bad to see the following:
CUN2046I AN EMPTY UNICODE ENVIRONMENT HAS BEEN ESTABLISHED

The manual SA22-7649 "Support For Unicode: Using Conversion Services"
is the reference.

If you need help, please post a reply with the above information.

I tried the -vv, but I got the same results.

todsn: 0.3 2006-05-19
todsn: Copyright (C) Dovetailed Technologies, LLC. 2006. All rights reserved.
todsn: TranslateException: CCSID not supported by CUNLCNV, RC=8, Reason=3

Where is stderr going. I also tried with the -t ibm-1047, and received the above error, so apparently I have not translation setup for that. What suprises me, is that fromdsn-ssh down to my pc has no issues whatsoever. The file gets translated just fine without specifing any codepage. I didn't list the entire results.

CUN3000I 08.23.40 UNI DISPLAY 652
ENVIRONMENT: CREATED 08/22/2006 AT 20.04.10
MODIFIED 08/22/2006 AT 20.18.36
IMAGE CREATED 08/05/2003 AT 13.03.23
SERVICE: CHARACTER CASE NORMALIZATION COLLATION
STORAGE: ACTIVE 9862 PAGES
LIMIT 25600 PAGES
CASECONV: NONE
NORMALIZE: DISABLED
COLLATE: DISABLED

Thanks,
Steve

Well, it looks like conversion services are enabled, based on the number of active pages in your DISPLAY UNI output.

It looks like you aren't getting debugging messages because it gets the exception too soon. We will fix this.

What you are saying is that it seems to work in one direction, but not another. If you put -vv on fromdsn-ssh (which works), what CCSIDs does it say that it using?

Also, as a test, you can specify the raw CCSID numbers. Try this command:

copy ta00405.txt con: | todsn-ssh -pw xxxx t330@mvsoz.hiw.com -vv -s 819 -t 1047 -r ta00405.ptf

If this gives you the same error, then there would seem to be a missing translate table in the z/OS conversions services. The ones that you should have are:

00819-01047-R
00819-01047-L
01047-00819-R
01047-00819-L

If you are using the IBM-supplied sample tables, these should be there.
Note: these names aren't listed under DISPLAY UNI,ALL until they are actually loaded/used.

Since so many people seem to have problems with z/OS Unicode Services, we've built a new version of dspipes that will fall back to iconv if needed. Please feel free to download this new package and see if this fixes your problem.