Talk:EBCDIC

message: The infobox claims that EBCDIC was "succeeded by UTF-16".  A citation has been requested, with the edit comment "add cn on succeeded by UTF-16 in infobox -- it is non-trivial to source (I have not found one yet); and i'm interested in more detail such as when it was succeeded by utf-16."
I'm curious in what fashion it was succeeded by UTF-16.
Deciding whether to store data as UTF-8 or UTF-16 on IBM's Web site says that DB2 supports either encoding, but that "COBOL and PL/I on z/OS use UTF-16 for Unicode data. Neither language supports UTF-8."
And they also say on the "Unicode on IBM i" page that "The IBM® i operating system provides support for Unicode.", although "Mapping of data" says "The IBM® i operating system uses the EBCDIC encoding scheme. However, not all clients attached to the system use an EBCDIC encoding scheme to store, retrieve, and process data. Therefore, some clients use Unicode as an exchange mechanism that is safe across all platforms."
So perhaps 1) IBM's adding support Unicode even in their EBCDIC-based OSes (as opposed to their ASCII-and-extended-versions-thereof-based AIX, and as opposed to the similarly ASCII-and-extended-versions-thereof-based Linux on both IBM Z and IBM Power Systems) and 2) when they're not constrained to use UTF-8, they're choosing UTF-16.
However, are they completely switching to Unicode (in some encoding), so that, for example, a z/OS data set catalog can have entries in Unicode?  Can system services that take character strings as arguments take Unicode strings (in some encoding) - in particular, for services that formerly took EBCDIC strings, are there versions that take Unicode strings?
And are they uniformly using UTF-16 as the encoding, except for cases where they're constrained to use UTF-8 (such as for most Internet protocols, and for whatever they call their UNIX environments on IBM i and z/OS these days)? Guy Harris (talk) 03:11, 16 December 2018 (UTC)
replies: text: Absolutely not. I can assure you 100% that the primary character set of IBM z/OS is still EBCDIC and is likely to remain so for the foreseeable future. It is so basic to the environment that I am having trouble finding a reference to cite -- it seems to be just kind of assumed, but I assure you that working in z/OS every day I work primarily in EBCDIC. Charlesm20 (talk) 13:43, 17 June 2019 (UTC)

text: Here is something of a reference:  Charlesm20 (talk) 13:54, 17 June 2019 (UTC)
replies: text: Somebody removed the claim that it was succeeded by UTF-16 in this edit.  I've seen nothing to indicate that we should put the claim back, and your comments further support its removal. Guy Harris (talk) 17:13, 17 June 2019 (UTC)
thread_title:  "Succeeded by UTF-16" 

message: Is not colon (EBCDIC 7a, ASCII 3a) part of the EBCDIC invariant character set? It is included here https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/nls/rbagsinvariantcharset.htm which would seem to me to be authoritative.
Apologies if I am not doing this edit correctly. It's about my third edit in about 20 years.
Charlesm20 (talk) 22:39, 13 June 2019 (UTC)
replies: text: That looks like a pretty authorative reference, probably should be used to update the table and add as a citation.Spitzak (talk) 02:36, 14 June 2019 (UTC)
replies: text: Heck, the EBCDIC chart in Appendix F of Form A22-6821-0, IBM System/360 Principles of Operation - no date, but the "-0" suggests this is the first edition - has 0x7a for colon, so that dates back a while.  I'm guessing that only the empty spaces in that chart are eligible to be different between different EBCDIC code pages. Guy Harris (talk) 03:47, 14 June 2019 (UTC)
replies: text: It does date back. So do I. I basically started my coding career with that manual. The date would be ~1964. I have been working with EBCDIC basically my entire career. No, some of those EBCDIC characters did not survive the sixties. And from bitter experience cent and exclamation point are DEFINITELY not invariant. When IBM discovered there were places that did not use the American alphabet they stole some of those spots for British pound signs and so forth -- that is how we ended up with variant EBCDIC. Charlesm20 (talk) 13:33, 17 June 2019 (UTC)
replies: text: The article says the invariant character set is "characters that should have the same assignments on all EBCDIC code pages" - emphasis theirs, not mine.  I don't know whether an emphasized "should" means "should have, but don't have in practice" or what, so I'm not sure what should :-) be in the invariant character set by that definition.  Should :-) we change the definition to "that have the same assignments", and either make sure it's true on all the code pages whose definitions we can find or find an IBM reference giving the invariant character set? Guy Harris (talk) 17:18, 17 June 2019 (UTC)
replies: text: If you remove all of the characters that don't change in any set called "EBCDIC" I think you will remove all the letters, so probably not. I like the idea of using the reference above to fix the colors in the table to match what that document claims is invariant.Spitzak (talk) 22:00, 18 June 2019 (UTC)
thread_title:  Question regarding invariant character set 

message: The article speaks of 36-bit machines having 5 7-bit ASCII characters per word where, presumably, they'd have to go with 4 8-bit characters per word if they used EBCDIC.
The PDP-10, running either TOPS-10 or TENEX, did store ASCII in that fashion (with TOPS-10, at least, also using a 6-bit ASCII-derived subset, SIXBIT).  Multics on various 36-bit GE and Honeywell machines, however, stored 4 9-bit bytes per word, with ASCII characters in those bytes, and the UNIVAC 1100/2200 series running EXEC 8 through OS 2200 apparently also went with 9-bit ASCII or 6-bit FIELDATA.
So 5 7-bit ASCII characters per word wasn't universal with newer (post-ASCII) 36-bit machines (the older 36-bit machines, such as the IBM 700/7000 machines, didn't adopt ASCII because it didn't exist yet).  DEC may have picked ASCII because it only required 7 bits, but also may have picked it because it was the character encoding used by Teletype models such as the Teletype Model 33, as those were often used as terminals. Guy Harris (talk) 03:21, 25 May 2020 (UTC)
replies: text: A good explanation, I think the PDP-10 as with other machines of that time used ASCII where the interface to teletypes had become important. The bit saving idea sounded very odd to me (even though as an assembler programmer of the time, we were always trying to save bits in memory and storage). Indeed most machines of this period were using 6 bit bytes and 36 bit words which is far more sensible SO LONG AS YOU ONLY WANT CAPITALS lol. Brian R Hunter (talk) 01:20, 26 May 2020 (UTC)
thread_title:  36-bit machines more likely to adopt ASCII than EBCDIC? 

message: I liked the old format for the character chart much better. I thought it was a lot more readable than the current  version.Peter Flass (talk) 20:23, 17 November 2021 (UTC)
replies: text: Can you explain exactly how? The whole point of doing this is to make the tables readable and to match the style used elsewhere in Wikipedia.Spitzak (talk) 20:30, 17 November 2021 (UTC)

text: I thought the colors made it more readable, and the stippling detracts from it. I know this table has been the subject of a lot of back-and-forth, but I thought it had been gotten into pretty good shape. Peter Flass (talk) 02:30, 18 November 2021 (UTC)

text: The people doing the Unicode block charts were rather insistent in the dotted boxes, I tried a version without them first.Spitzak (talk) 02:54, 18 November 2021 (UTC)
replies: text: Yes, because the dotted boxes carry semantic information in Unicode charts (and isn't limited to control characters). I'm not convinced they have to be used for these character charts though. There's an argument for consistency between the two types of charts but another syntax (like parenthesis in IBM's charts) could work.  I would oppose removing them from the Unicode block charts, of course.  DRMcCreedy (talk) 04:32, 18 November 2021 (UTC)
thread_title:  New character chart format 

message: indicates that there are code pages that supported at least some "country-specific character repertoires" in the past and were extended to support ISO 8859-1, which suggests at least some level of support for accented letters.
 claims that the bank that was accused of a GDPR violation because a customer's name couldn't include properly-accented versions of some letters in the name response "included the fact that their system used EBCDIC, as well as that it did not support letters with diacritics (or lower case, for that matter)."  the GDPRHub page about this case has a mangled machine translation of the original case information in Dutch (Flemish?).  Google Translate won't translate the PDF if you hand it the URL, and, if you just copy and paste the text of the bank's response, it also mangles the translation (the phrase "De Bank X" appears to mess it up; I'm not sure why it can't translate it as "The Bank X", or just "Bank X" - the "X" is presumably to preserve the banks' anonymity, just as the references to the customer as "Y" is presumably meant to preserve their anonymity).  The mangled translation says:
I added a comment to the GDPRhub page giving the result of an attempt to improve the translation by using various tricks to work around Google Translate's problems. The fixed translation says
In both versions, the bank does note that EBCDIC now can support accented letters (probably by, in their case, choosing a code page that supports, at minimum, French accented letters), but that their application was not updated to allow that. The improved translation may make this clearer.
It appears that, having made a GDPRhub account, I could edit the machine translation myself.  Not knowing Dutch (other than "de", "het", and words that are sufficiently close to the English equivalent :-)), I considered that to be above my page grade :-), so I leave it up to Somebody Else there to fix it.
That also means that the page is a Wiki, so maybe it's not a WP:RS, and that the original page should be used as a reference - perhaps preferably by somebody who knows Dutch, so that, if "manually shoving it through Google Translate to try to get a non-mangled translation" is considered original research, they can post it as a reference (possibly with a translated quote). Guy Harris (talk) 09:55, 5 May 2024 (UTC)
thread_title:  Does EBCDIC support accented letters or not?