Here is a final -- from my point of view anyway -- update on this.
I wrote in the PMR:
I had a further thought on this. I think the issue is very simple. I
don't think what you are doing between 1027 and 1208 is round trip
conversion -- I think it's enforced subset conversion. If you read the
definitions of roundtrip and enforced subset in the CDRA manual, what
you are doing between 1027 and 1208 does not conform to the definition
of roundtrip, but it conforms perfectly to the definition of enforced
subset.
Or look at it this way: suppose you DID offer enforced subset between
1027 and 1208: how would it be any different from what you do now for
technique 'R'?
Here is the reply:
In reviewing our exchanges over the last few days, I think I
misunderstood your objective in opening this PMR to begin with. I
thought your intent was to understand the meaning of "roundtrip". In
retrospect, I think more importantly you were reporting a problem in
roundtrip conversions. Now I think I see the disconnect our respective
positions on the issue.
Considering the cases you cited where characters are all converted to
x'1A' (sub character), this is because those characters are unassigned
in that code page. The following link (which will have to be pasted
back together) shows that for 41, 6A, etc. the chart is blank.
ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP010
27.pdf
To help resolve the concern, we have updated the Glossary entry for
Roundtrip to say the following:
Round trip. Encoding that occurs when every code
point in the source CCSID maps to a unique code point
in the target CCSID. Using round trip tables ensure the
capability of reversing the conversion, and recovering
the complete original source datastream.
Note: If the conversion is to Unicode, and the source code point
is undefined by the source standard it should not be used.
Because of this that point will become a substitution
code and will not round trip.
This will appear in the next revision of Unicode Services User's Guide
and Reference.
And here was my final update:
Thanks! I was trying to figure out the disconnect between my
internalized definition of round trip and the behavior of Unicode
Services in this situation.
I'm not unhappy with your response. It will let me resolve the
disconnect between the documentation I am responsible for and your
documentation.
I think changing Unicode Services so that the current conversion
behavior persisted but was reclassified as Enforced Subset would be a
better response, but it's your product, not mine.
Take care, and thank you, and again, I think Unicode Services is a
great product. It is a boon to productivity: why should every
programmer have to re-invent EBCDIC to ASCII translation?
I will close the SR.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Charles Mills
Sent: Tuesday, June 12, 2012 8:32 AM
To: [email protected]
Subject: Anyone a Unicode Services expert? -- roundtrip conversion
My understanding of "roundtrip conversion" is that every code point in the
from CCSID translates to a unique (possibly "meaningless") code point in the
to CCSID so that if for example a customer is so foolish as to transmit, for
example, an object deck from z/OS to a PC in "text" format, and then
transfer it back to z/OS the same way, he will have a good object deck.
I am running Kirk Wolf's excellent showtrtab with the command showtrtab -s
1027 -t 1208 -q R
The results I see include the following:
3F: 1A
40: 20
41: 1A
Several other EBCDIC code points also translate to ASCII sub, 0x1a. So the
question is if multiple EBCDIC code points all translate to 0x1a, how the
heck is this a round trip translation?
(I'm not alleging a bug in showtrtab. I am getting the same results with my
code and ran showtrtab as a reality check and a clearer example.)
Where am I going wrong?
Charles
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
