I can't tell you how many times I have been bitten by this type
of problem.
Just wanted you to know you have not been the only one.
--
Regards,
Steve Thompson
Make Mainframes Great Again
They use far less Electricity than Clouds and can do more work
On 8/30/2025 1:54 PM, Paul Gilmartin wrote:
On 8/29/25 16:17, Robert Raicer wrote:
I remember once upon a time (in the mid 1980's) creating a bit
of an
embarrassment (resulting in the rapid production of a PTF)
caused by
my naivety. I had written some code which produced console
messages
(i.e., WTO's) in mixed case. Unbeknownst to me at the time, the
EBCDIC character codes for the lower case letters (0x81:0x89,
0x91:0x99, 0xA2:0xA9) produced katakana graphics on an IBM 3278KN
SBCS terminal. So, when my code was executed on a customer's
system
in Japan, the results were less than delightful.
...
About that time frame, perhaps for the same employer
but a different project, our little design group took
the same avant-garde approach to messages. But someone
was alert to the "katakana hazard" (I would have said
"characters", not "graphics".), so we provided a
configuration option to translate message texts to
upper case.
I had tendered an amendment to translate only the
message prototype and leave substituted text fields
as-is. Alas, I was outvoted.
When I was first learning a little CLIST, I experimented
with a command, "do". I was hardly surprised when it
got a syntax error. But the message:
ILLEGAL COMMAND: "DO".
Wtf‽
1. "DO" is a legal command.
2. I had typed not the reported "DO", but "do".
I remain firm that messages should echo text with no
unnecessary transformation. If a user enters katakana
and my product does not accept katakana, I should echo
the offending text as entered, not Roman caps.
