> Think of 52 different characters, not two typographic variants of 26
> characters.
Um. You seem to be suggesting that case-sensitivity is A Good Thing. I have yet
to find anyone who can justify that position, though many *IX people assert
it--and then basically just say "It's good" without any justification.
Humans are not particularly case-sensitive; computers shouldn't be either. I
contend that anyone who would create files foo Foo and FOO (and the other
variants) is just asking for trouble, and will surely find it. Same with
options: -r and -R on the same command, with different meanings, is insane. My
understanding is that the single-character tendency is an architectural
artifact of the PDP machines, which lacked a CLC equivalent. That doesn't make
that good, or something that needs to persist forever. Of course old command
formats need to be supported, but adding -recurse and -replace (or whatever
-r/-R mean on a given command) is well worth doing for usability.
For all its warts, Windows got this one right, IMHO.
And if I've misunderstood your point, apologies, of course!
P.S. Of course this doesn't excuse the 3277; I assume that behavior was due to
some cost issue, but oy, am I glad I never quite used one--I was using
Volker-Craig terminals in linemode in that era; the first 327x I ever used was
a Memorex 3278 clone.
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf
Of Paul Gilmartin
Sent: Tuesday, August 26, 2025 12:10 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is HLASM efficient WAS: Telum and SpyreWAS: Vector instruction
performance
On 8/25/25 20:33, Jon Perryman wrote:
> Ask yourself, why are unix commands so strange (e.g. testcmd -x -v -f aaa -u
> mmm -t bbb ccc -u). Why is uppercase/lowercase important to Unix? It's
> because of C limitations. In C, you strchr('-') or strchr(' '). Since you
> can't search for 2 different characters, you must structure the command in a
> known easily parsed syntax.
> ...
Most UNIX facilities support search for 2 (or more) different characters, often
by [list].
> Searching and parsing is stunningly fast using 1 z instruction. So how does
> TSO parse commands such as:
>
> TSO ALloc DDN(abc) PATH('/u/user') DISP(NEW) catalog SPACE(1,1)
>
> You can't uppercase the command because of PATH requires lowercase. You use
> TRT CMD,TRT_TABLE where TRT_TABLE are the characters that represent parsing
> points.
> ...
"Doctor, it hurts when I uppercase the command."
"Don't do that."
Many mainframe conventions arose from an attemptto accommodate programmer
habits formed by the limitations of the 026 (no longer marketed by IBM,AFAIK),
aggravated by the 3277 which, unforgivably, transmitted minuscule while it
displayed majuscule.
Don't uppercase the command; uppercase the keyword at the point of symbol
lookup. Similarly, uppercase the argument of DSN; leave the argument of PATH,
SEND, ...
as is.
Outgrow your 026 mindset. Think of 52 different characters, not two
typographic variants of 26 characters.
But IBM could do better. It lacks common extensions such as:
find -iname
OptionL case-sensitive regex for DFSORt
...
--
gil
