On Sat, 3 Dec 2016 03:00:15 -0500, David Cole wrote:
>...
>But if the worlds of Apples, PCs, iPhones, and Androids
>has show us anything at all,
>it has shown us that skins matter,
>and that UIs matter.
>
>IBM has a decades long history of releasing unpolished products
>and then polishing them up over the next several releases.
>"Making it pretty" was always an afterthought.
>
But when the coarseness is in a programming interface, the
excuse is too often made, "Polishing it would introduce an
incompatibility with existing art." The analogy should
be pulling off adhesive tape: the quicker you do it, the better.
>I think that's a mistake that used to be tolerable
>in the closed world of expert customers of decades gone by.
>But even experts want nice things too.
>
About a half century ago, a programmer could sit down with
a stack of manuals and in a few days learn all that was necessary
about OS/360. Nowadays, it's essential that things be made
uniform to limit that learning burden.
>I think that "making it pretty" should be
>just as important an objective as "making it work".
>Didn't OS/2 losing the desktop wars of the '90s prove that?
>Didn't Steve Jobs prove that?
>
And z/OS stands to lose the enterprise war by making a
horrible first impression on talented individuals the
enterprise needs.
A couple weeks ago, Walt Farrell and Peter Relson jumped on
me with a harsh (snarky?) form of "RTFM". In fact, I had read
it; I merely didn't like what I read. It said that if the programmer
assigns SYSPRINT or SYSTERM to a UNIX file, the programmer
must specify FILEDATA=TEXT. Hmmm... What if ...? I tried it
and learned that if I tried FILEDATA=RECORD (a very new form)
or FILEDATA=BINARY (the default) the operand is ignored and
TEXT is presumed. No warning message; RC=0.
I think I know the history. Binder supported the equivalent of
FILEDATA=TEXT before the FILEDATA key existed in JCL or
in allocation. It's probably the most useful option; in that
sense a wise choice. When allocation introduced FILEDATA,
BINARY was made the default. Not outstandingly the best
choice, but I'll be neutral on it. But to respect the BINARY
default would have introduced a behavioral change; Binder
chose to override.
And another sentence appears in tne Reference; one more thing
for the programmer to memorize. On the whole, bad!
Walt and Peter both told me:
o If I read all the Binder documentation, I know what I must do.
o IBM is under no obligation to treat a programmer's disobedience
rationally, nor to to document the consequence of disobedience.
They didn't mention that if I want the behavior of BINARY or
RECORD, I'm SOL.
I'm reminded of the first pages of Hitchhiker.
A couple years ago, I noticed that if I supply Binder SYSLIN
with FILEDATA=TEXT ("RECORD" may not have been an available
option at the time), that was ignored and BINARY (admittedly
the default) is presumed. This can be a PITA. It means that I
must pad every record to 80 bytes; newlines have no particular
meaning.
I submitted an RCF (perhaps an SR; I don't recall). I don't know
if anything changed; I had promptly accommodated. But I'll
check, and if it still behaves as not documented, I'll submit an SR.
I'd bet on WAD and a DOC APAR. And the interface becomes more
complex, less polished. This practice will lead z/OS along the
path of OS/2.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
