On Linux, all applications seem to support UTF-8 by default. All
editors I've used on Linux appear to support editing UTF-8 documents
without issues. The Gnome desktop on Linux even includes built-in
support for entering arbitrary unicode characters that lack a keyboard
map, using Ctrl+Alt+u xxxx Space, where xxxx is the documented hex code
for the UTF-8 character. This means all Linux applications that allow
text input (including this Thunderbird email client) support this same
convention: Ctrl+Alt+u b0 gives the degree glyph, as in 78° and
Ctrl+Alt+u 2204 gives the mathematical "does not exist" glyph ∄, etc.
--works for any UTF-8 character that is not explicitly restricted in the
given context. This includes the Terminal command-line-interface
application and the Files app that allows you to create/rename files and
directories.
On Windows, most apps don't have any problem displaying UTF-8, or doing
copy/cut/paste of UTF-8 characters in text fields, but the input of
arbitrary UTF-8 characters is not part of Windows desktop support but
the responsibility of each App. Only some apps (MS Office, for certain)
support it, and the conventions for entry may vary. File Explorer under
Windows 11 is an example of an app that does not have UTF-8 input
support, so the only way on native Windows to rename a file or directory
to insert a UTF-8 character that is not mapped by a keyboard key is to
copy the character from an existing document that contains the desired
UTF-8 character and paste it into a rename field.
Clearly z/OS can store files with UTF-8 content within its Unix
Filesystems. I would assume, since it may need to interface with files
created on Linux systems, that it can also tolerate file and directory
names in UTF-8 as well; although perhaps currently the only effective
way to navigate and edit such content is remotely from an Operating
System like Linux with full UTF-8 display and entry capability.
I'm guessing that ISPF under VM/CMS is still constrained to full-screen
devices that use the 3270 Architecture, which would mean it has the same
limitations as TSO/ISPF.
As to the possibility of migrating a tool like jedit to z/OS. Yeah, I've
had similar wishes as java is supposed to be portable -- but surely
that's still limited by what the Operating System supports. All the
platforms listed as supporting jedit are Operating Systems that support
native hi-res hi-bandwidth graphic displays and which have all the APIs,
font definitions, etc for creating graphic windows with text displays,
mouse and keyboard interactions. Since z/OS doesn't directly support
such displays, AFAIK there are no native z/OS APIs for graphic window
creation and management that could be utilized by java, so unlikely that
Java on z/OS would support the management of application windows that
jedit obviously uses. I say unlikely, because it certainly could be
done if the graphic windows were only viewed from a remote Operating
system with graphic display support using something like remote X11
viewing or Remote Desktop protocol over TCP/IP, and if massive amounts
of graphics software support were added to Java on z/OS to do the
function of the window APIs that z/OS lacks, all for the dubious
"benefit" of sending character data remotely as dynamic graphic data
requiring a much larger bandwidth. Sort of goes against the mainframe
philosophy of designing efficient applications that scale up gracefully
to 1000's of users.
I don't see z/OS ever deciding to support native hi-res, hi-bandwidth
displays -- PC hardware is much more cost effective for that; and by the
same argument no one is going to design specialized channel-attached
terminal hardware that could handle a terminal protocol that would fully
support unicode when it is much cheaper to emulate such a terminal on a
PC using TCP/IP connections. So short of editing unicode as hex data
(which would be insane), the only way to reasonably edit unicode with
the editor code running on z/OS would be for that editor to somehow
utilize TCP/IP to connect to a remote user interface, in effect a new
emulated terminal type, on Windows/Linux/Mac, using a communication
protocol that allows character data to be sent as unicode characters,
not as images. Since there are already existing solutions to unicode
editing using editors on PCs, file sharing methods, etc,, it would be
impossible to cost-justify efforts to design new protocols and support
for new types of terminal emulators just get the actual editor code to
run on a more expensive platform under z/OS. I could only see someone
doing it as a challenge -- just to prove it could be done.
JC Ewing
On 7/8/23 13:45, Paul Gilmartin wrote:
On Sat, 8 Jul 2023 10:17:03 -0500, Joel C. Ewing > wrote:
...
There are so many useful glyphs available in UTF-8 that aren't in any
current 3270 terminal CCSID and which can't be in any 3270 terminal
CCSID without throwing out some other characters. it's a shame if ISPF
is still inseparably tied to 3270-architecture restrictions. I guess
another way to look at it is that any application that needs to fully
support UTF-8 data just can't be written as an ISPF application.
ISPF on CMS provides a choice of (two) editors. It fells as if it would
be a good Idea for ISPF on z/OS to do likewise; even further; and give
the user an arbitrary choice of editors.
When the "other" (did you guess it?) editor exits ISPF/CMS does its
best to synthesize stat, in a side-deck file.
Has jedit (or other) been ported to z/OS? I just tried it on Linux and it
seems competent with non-Latin UTF-8 files.
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
