Admittedly I've been away from 3270 devices, real or emulated, and ISPF
for over a decade now. ISPF support for the Unix filesystem was a
little rudimentary and confusing back then, partly because of
conflicting codeset definitions, but how on earth is it supported these
days from a full-screen device limited to variants of the 8-bit EBCDIC
code? Linux, and even Windows, now supports directory names and file
names using all but a few restricted UTF-8 characters. Surely that
means the Unix filesystems on z/OS must now support that as well? And
of course text data in files on non-z/OS systems these days frequently
uses UTF-8 by default. How can you even specify Unix file paths on an
ISPF panel when arbitrary UTF-8 characters with no counterparts in any
EBCDIC variant may be in the file path?
Has no one yet figured out how to create a successor to 3270
Architecture and 3270 communication protocol that supports the UTF-8
charset? If ISPF design is still centered around and restricted by an
architecture that can only support less than 256 different glyphs, that
would seem to be a serious deficiency in today's world.
JC Ewing
On 7/7/23 20:37, Attila Fogarasi wrote:
Codepage 1047 is obsolete, superceded by 942. Since this is mainframe, it
remains supported "forever". Euro did not exist at the time 1047 and 037
and 037-2 were created. That is one reason that 942 was created, with Euro
symbol amongst other changes. My suspicion is that the tangled codepage
history has to do with the multiple conflicting divisions at IBM with
printers, PCs, S/3x, 8100 and Series/1 all intersecting on codepage in
various ways. Most likely all divisions had veto power over codepage
standards. This is all ancient history and not relevant in the past 20
years, but we have the legacy of strange codepage sets (and hundreds of
them) to deal with. The politicized ISO standards at the time did not help
matters. Eventually the answer became Unicode -- and look how that has
struggled for 20+ years to become the standard.
On Sat, Jul 8, 2023 at 11:23 AM Paul Gilmartin <
[email protected]> wrote:
On Sat, 8 Jul 2023 09:37:23 +1000, Attila Fogarasi wrote:
Codepage 1047 was created to provide a bi-directional mapping to
ISO8859-1 character codes (this preserves values when going in either
That is not a valid rationale for codepage 1047. There is a bi-directional
mapping between 037 and ISO8859-1.
direction). It also included most EBCDIC control codes (mapped to
unused ASCII codepoints) and about half the ASCII control codes (as many
as
That is not a valid rationale for codepage 1047. It may be a reason for
ISO8859-1, which has 32 non-ASCII control codes at 128-159.
would fit). I think it was created in preparation for OpenEdition MVS
which became USS once it was Unix certified. Codepage 924 is an update of
CP1047 adding things like Euro sign, and matches ISO8859-15 (not
ISO8859-1). CP037-2 differs from CP037 at 4 codepoints and is more widely
Which 4? Did they usurp any USASCII graphic equivalents from 037? Was
there any reason that neither 037 nor 037-2 could have been used for OMVS?
used then CP037 (though I've encountered CP037-2 implemented with the name
CP037 by various products (!!)). Luckily for human readable data the
differences don't matter. I don't know if there are any other CP037-n
codepages, and these days it rarely matters.
"rarely matter" and "don't matter" are in the eye of the beholder.
Does 1047, 037, or 037-2 have €? why could neither 037 nor 037-2 have been
used for OMVS?
I remain unpersuaded of any rationale for 1047.
--
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
