On Tue, Dec 29, 2020 at 1:11 AM Tom Honermann via SG16 <email@example.com> wrote:
The summary for the SG16 meeting held December 9th, 2020 is now available. For those that attended, please review and suggest corrections:
Thanks for the notes.
With respect to the following:
Hubert stated that encompasing the console in a separate facility would pose challenges.
I raised at least one specific challenge:
Hubert stated that encompasing the console in a separate facility would pose challenges because it assumes the presence of a unique "console" in the environment.
Thank you! Fixed!
I also archived the notes for meetings in 2020. The link above is still active, but an extra level of indirection has been introduced. The direct link to the notes for this meeting is now https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2020.md#december-9th-2020.
With regards to:
Hubert explained that z/OS supports two modes:
ASCII: interfaces are provided that perform conversion from an internal encoding when writing to a stream; this is commonly used for simple encodings.
EBCDIC: this is a byte pass through mode.
I'm quite sure I didn't say that EBCDIC is a byte pass through mode.
My recollection is that I said something like:
On z/OS, an application could internally be in ASCII or EBCDIC mode. Open file handles can be imbued with the property of being ASCII or EBCDIC. The C-level I/O APIs can automatically translate at least single-byte encodings.
Thanks, it looks like I projected some of my own limited (mis)understanding there. I applied your update.
My understanding had been that, when in ASCII mode, the standard C interfaces transcode to EBCDIC. But I had not thought through the ability to tag files with an encoding in the filesystem; those tags presumably apply equally to programs running in ASCII vs EBCDIC mode. When you refer to open file handles being imbued with an encoding, is this via filesystem tags? Or are there other system interfaces to do this (I don't see, for example, a mode option for fopen()).