Thank you for the explanation, no problem for the delay. This week I was also very busy...
As for the -b option, I agree with you absolutely. IMHO, -b, bin, binary or similar should not perform any conversion.
As for using codepages in the host dsn_profile, I agree that it is not the optimal place.
Note that e.g. for DFS, both the source and target code pages are defined on the host
(well, it is somewhat simpler there since on the wire DFS always has ascii).
For dspipes, however, nothing else was allowing for me to set the default ascii codepage, that is why I gave dsn_profile a try.
Here are some reasons:
1) even from my linux pc, using LC_ALL=hu_HU.iso8859-2, fromdsn(linux) still assumes iso8859-1 (also with capital ISO8859-2)
Code: Select all
$ locale && fromdsn -ssh ???@??? -L T //???.b.txt
LANG=hu_HU
LANGUAGE=hu
LC_CTYPE="hu_HU.ISO8859-2"
LC_NUMERIC="hu_HU.ISO8859-2"
LC_TIME="hu_HU.ISO8859-2"
LC_COLLATE="hu_HU.ISO8859-2"
LC_MONETARY="hu_HU.ISO8859-2"
LC_MESSAGES="hu_HU.ISO8859-2"
LC_PAPER="hu_HU.ISO8859-2"
LC_NAME="hu_HU.ISO8859-2"
LC_ADDRESS="hu_HU.ISO8859-2"
LC_TELEPHONE="hu_HU.ISO8859-2"
LC_MEASUREMENT="hu_HU.ISO8859-2"
LC_IDENTIFICATION="hu_HU.ISO8859-2"
LC_ALL=hu_HU.ISO8859-2
fromdsn[T]: -> setTargetCodePage(ISO8859-1)
fromdsn[T]: <- setTargetCodePage()
fromdsn[D]: targetCodePage defaulted to COZ_CLIENT_CODEPAGE=ISO8859-1
fromdsn[T]: <- fromdsn.parseArgs()
fromdsn(???)[D]: initialize(): sourceCodePage="IBM-1165"(1165), targetCodePage="ISO8859-1"(819), srcSp=0x40, tgtCr=0xD, tgtLf=0xA, lineTerm=6
2) my standard setting is LC_*=hu_HU LC_TIME=C LC_ALL=(empty) - hu_HU meaning iso8859-2 since it is the default locale on my pc. I take from your explanation, that this would not let dspipes use my codepage instead of the wired default 8859-1.
3) I was trying to control centrally how the different clients would perform default translation.
Many clients use our correct locale, but some clients just missed localization, others may have compatibility reasons to use a different locale. However, unless using latin-2 or utf locale, the default conversion would lose national characters. What I was trying is similar to the pure ascii scenario where the host is iso8859-2 and transfers are considered binary (outside of z/OS, neither scp nor sftp would convert).
As for the differences between local omvs shell vs. local ssh shell, I must apologize. After checking it again, both cases translateidentically to ascii. However, what I hoped, was that dspipes would perhaps ignore default ***Codepage parameters for the ebcdic case.
I agree that allowing both ebcdic and ascii clients, the targetcodepage/sourcecodepage parameters are unusable on the host side. Perhaps an asciiCodepage or similar parameter would allow the setting of the default ascii code page in dsn_profile.
Best regards, Jenoe