----------------------<snip>--------------------------
Without knowing what your day-to-day role is, it's hard to say.
First, simply by not being in denial. Mainframes are not better because
the people who use them are older, the boxes are bigger, they were
around in 1979, and all of your professional peers work on them.
Mainframes are not better because we all know they're better, and that's
that, and anyone who disagrees with me is obviously one of "them."
-------------------------<unsnip>------------------------
Mainframes ARE better, for many BUSINESS-type applications. The average
business application needs to be able to do huge amounts of I/O, as
opposed to raw number-crunching. Let's face it: most businesses don't
spend a lot of time computing thousands of digits for pi, or evaluating
boundary-layer problems for fluids in pipes, or simulating weather or
nuclear explosions and analyzing individual particle movements, etc.
They're far more likely to be involved in processing invoices and
payments, or inventory management, or payrolls. All these are I/O
intensive operations, with only a few well-defined calculations
involved. But if an engineer needs to calculate flow resistance in a
pipeline, or lift over a particular wing section, on any of the millions
of other problems that require raw number crunching, sometimes the
"squatty box" is far superior.
--------------------------------<snip>-----------------------------
Second, many of the participants on this list, myself included, work for
(directly or indirectly) IBM or a software vendor. We have a direct or
potential influence on speed, cost, ease-of-use, reliability, and security.
--------------------------------<unsnip>---------------------------
No argument here. But the hardware evolution in terms of RAS has made
the MF KING in this area. MF had a poor record to start, but it's
improved immeasurably over the last 40+ years, with the evolution of
microcode and things like automatic recovery and fail-over to unaffected
components, sparing, etc. The "squatty boxen" will eventually arrive at
the same point in their evolution, but they haven't got there yet. In my
own experience, the hard drives in use today have a long way to go.
They've come a long way, compared to their abysmal past, but there's
still a lot of room for improvement. And I have a MAJOR problem with a
software vendor who tells me to "Reboot and see if that fixes it" or
"Re-install and see if that fixes it". Diagnostic tools and procedures
are a world apart between z/OS and the various Intel-based systems.
--------------------------------<snip>-----------------------
If you work for an end-user company, then you have some influence on,
for example, the ease-of-use of your systems. I often hear on this list
a defense of obscurity: "why would you want to change how JCL works --
it was good enough in 1968, it's good enough now." That is not a
productive attitude. Face it, the mainframe is in many ways
user-hostile. We are the people who invented the cult of the
unapproachable IT guru: "authorized personnel only." Changing those
attitudes would be a good step.
---------------------------------<unsnip>--------------------
"User-hostile"? I prefer to say "User-challenging". It's not "hostile"
as much as it is just plain complex. There's a myriad of messages and
codes to try an tell a user exacly what a ploblem is, but so many
programmers today aren't willing to do the research; even looking up a
message in the standard Messages and Codes manuals has become too much
work. JCL? Yes, it's a bit obscure at times, until you understand what
it means. Far too many people seem to think that since they know a
programming language (or think they do) that they're fully qualified.
When they learn to treat JCL as a language, instead of a simple (and
obscure) set of parameters, then obscurity drops away and the "comfort
level" skyrockets. Didn't we all think the same way about FORTRAN, once
upon a time? Or COBOL? Or BAL? In my mind, the label obscure means a
lack of understanding more than anything else.
I used to keep "System Message" and "System Codes" in large three-ring
binders on my desk. I also made sure that other groups had multiple
copies of both manual sets in their areas for reference. When a
programmer came to me the first time with a message, we'd look it up
together. The second time he came to me with the same message, I'd hand
him the binder; the third time I dropped it on his feet. Not "at", but
"ON" his feet. My point was that he should at least look it up and make
some attempt at understanding what it meant. If the message wasn't
understood after looking it up, then I'd work with him/her. But they had
to at least make the attempt. Is that an unreasonable approach? Some of
the organizations I've worked with have gone so far as to establish a
"HelpDesk", manned by Systems people in rotation, just to deal with
these types of issues. For some shops, it's worked out well; for others,
it was a dismal failure. YMMV.
-----------------------------<snip>-------------------------
And some things cannot be changed. Better to work to advocate
intelligently for the use of mainframes for the tasks they are good at,
than to operate in denial of the fact that it's not the best choice for
every computing task, or every company.
------------------------------<unsnip>-----------------------
Agreed.
Lord, grant me the serenity to accept what I cannot change, the courage
to change what I can, and the wisdom to know the difference.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
