Bingo!

I remember that pain well.
But I was on CMS and could do a pair of 'SET OUTPUT' commands to get proper behavior with a 3279. (And matching 'SET INPUT' commands.) If you're on ISPF then I don't know what to tell ya. But if you find a fix, do share!

Hang in there Tronguy.


-- R; <><


On 5/28/24 8:46 AM, Jay Maynard wrote:
As it happens, I'm dealing with this...have a small task to do some C, and
discovered the hard way that the 3279, while having the square brackets in
its normal character set, doesn't have them at the same code points as
later IBM OSes expect. tn3270 shows them fine, though.

On Tue, May 28, 2024 at 7:43 AM Rick Troth <
[email protected]> wrote:

Hi Tom --

You're not wrong.
The musical code pages have led to multiplied complexities.

Living in the US, I've had it easier than some, and in most cases I can
(and do) treat "EBCDIC" as CP1047 (with an exception around not and
circumflex). CP37 came first, and was "close" but got the square
brackets wrong (as most US installations used them). But with "CP37v2"
there is a one-for-one mapping with ISO-8859-1, and that's the A/E table
from which I start. It's not just me, many official implementations
(witness Dignus) use the same A/E mapping as their default.

EBCDIC representations like "CP 37 version 2" were drummed-up by
customers. In the early 1990s, there was a concerted effort (including a
SHARE project) to solidify a standard. IBM took the requirements to
heart, thus we have CP1047 (which is "CP37v2" except for logical not
versus circumflex). But this all remains an 8-bit solution.

The ASCII world also had multiple code pages (such as ISO-8859-1) but
then embraced Unicode and such encodings as UTF-8.
But mapping EBCDIC of any code page into UTF-8 is more than I know how
to do (reliably, unless I had source to the FTP client and hacked it
appropriately).
So to the original question, best practice is to have the z/OS side
handle the translation. ISO-8859-1 is most closely covered by CP819, so
the "*10470819*" mapping is what you want.
On the ASCII side, ISO-8859-1 *might* be usable as-is, but if not then
it can be easily converted to UTF-8. But that's a question for the ASCII
consumers of the data.

-- R; <><




On 5/8/24 12:45 PM, Tom Marchant wrote:
"This" is the link that Gil provided in the email that I replied to, at
the bottom of the post. The assertion was that IBM erred in not making the
System/360 ASCII only.
The availability of multiple EBCDIC code pages seems to me to make
Beemer's assertion that there is a 1 to 1 correspondence between ASCII and
EBCDIC even more dubious.
----------------------------------------------------------------------
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

Reply via email to