RE: Musings on a holiday weekend
- From: SKnutson@xxxxxxxxxxxx (Knutson, Sam)
- Date: 3 Jul 2006 07:41:38 -0700
Hi Steve,
Compatibility for customers existing investment in business
applications, and infrastructure (HW/SW) should be the primary
consideration one which might seem to doom any attempt to bury z/OS and
reinvent it as U/OS. I think the move to z/Architecture was driven by
customer need some existing and some foreseen by IBM to scale and
utilize 64 bit memory architecture especially including ported/portable
applications. What is the business driver to toss our zbaby out and
adopt a Ubaby? We have a lot of needs to continue to open the mainframe
up for SOA but UNICODE support is already sufficient (complicated but
sufficient) so it doesn't seem to be the one big problem around which an
effort should be launched. It seems like now is the time for IBM to
focus on SOA to make the zbaby speak any language we need to other
servers/apps/boxen/enterprise, basic RAS enhancements to make the zbaby
stronger, Install, Service, Usability improvements all to make it easier
to keep updated and support less time consuming for the limited cadre of
highly skilled zGuri on staff.
Perhaps the real reason not to do it is that it's so much fun watching
the wizards continue to innovate the platform under our feet without
dropping us all into the dirt. It would just be too easy to start over
what would be the fun in that? Reminds me of the old joke about the
Mechanic and the Surgeon......
A mechanic was removing a cylinder head from the motor of a motorcycle
when he spotted a well known heart surgeon in his shop. The surgeon was
there waiting for the service manager to come take a look at his bike.
The mechanic shouted across the garage,
"Hey Doc, can I ask you a question?"
The surgeon, a bit surprised, walked over to the mechanic working on the
motorcycle. The mechanic straightened up, wiped his hands on a rag and
asked,
"So, Doc, look at this engine. I open its heart, take valves out, fix
'em, put 'em back in and when I finish, it works just like new. So how
come I get such a small salary and you get the really big bucks, when
you and I are doing basically the same work?"
The surgeon paused, smiled and leaned over and whispered to the mechanic
...
"Try doing it with the engine running!"
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:sknutson@xxxxxxxxx
(office) 301.986.3574
Everything should be made as simple as possible, but not simpler.
Albert Einstein
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@xxxxxxxxxxxx
Behalf Of Steve Comstock
Sent: Sunday, July 02, 2006 3:39 PM
To: IBM-MAIN@xxxxxxxxxxx
Subject: Musings on a holiday weekend
Here in the US we have a major national holiday (July 4) coming up on a
Tuesday. That means that many folks won't be at their desks on Monday
(in fact, many took off last Friday or even Thursday); people will start
to drift back to work Wednesday.
Except, of course, sysprogs and the like who "get" to work on holidays
because they can have the systems largely to themselves and can get a
lot of mainenance, testing, installing, and so on, done with little or
no interruption.
--
I've been toying with ideas around the future of z/OS (if there is such
a future) and just thought I'd throw some of them out for consideration.
This should probably be on a blog or a Wiki, but I'm too swamped to set
one of those up right now.
I'd like to see z/OS last for another 5-7 years and the to be replaced
with something I call U/OS - for Unicode/OS.
Major pieces:
* A new operating system integrating all the pieces that
have been grafted on over the years; building on what
we know now about security, recovery, correction,
self-tuning, self-healing, and so on.
Many of the shortcomings we have realized about z/OS
could be addressed at the same time. Not exactly a
clean slate because we would want to incorporate all
the really good stuff we've seen develop.
* 64-bit only, from the ground up; no line; no bar
* Character data normally encoded in UTF-16! This would
take no new hardware instructions. Abolish EBCDIC, but
do not replace it with ASCII but rather with UTF-16.
No more codepage issues, except for a set of utility
programs to convert existing files and databases to
UTF-16
* All external communications (that is, messages and
commands) would be displayed in UTF-16 and accepted
as UTF-16. All system messages would not be hard coded
in programs, but accessed from message libraries where
the correct words, phrases, and text is used to build
messages, depending on the local language of the
person who will see the message (LE does this now, in
a very simplistic fashion)
* One of the major problems is Unicode input, and I've
found an interesting possible solution. A Russian
company is beginning to produce a keyboard where
each key has a small LCD. Each key can be programmed
to map to a character and a glyph of that character
can be displayed on the key.
Cool idea. The keyboard would have enough memory to
store all the Unicode characters in a basic font
like the one used by the Unicode consortium in their
book; (updates to the standard could be added by
downloads to keyboards!)
People could construct (and even sell) keymaps -
preset keyboard mappings; so the mix of characters
available on the keyboard changes dynamically by
select a keymap. You need to type Russian? Use
control keys to select the keymap you need. The
key LCDs now reflect the current assignments; when
you press the keys, the corresponding Unicode characters
are sent to the workstation or server; Languages like
Japanese and Chinese could have sets of keymaps that
would be easily changeable, so characters that tend
to be used together could be put on the same keymap
and an experienced operator would quickly learn how
to switch among the keymaps they need. Languages
with fewer characters could use a single keymap;
but users could change the location of where every
character appears on the keyboard if they so choose.
Details for the keyboard are at:
http://www.artlebedev.com/portfolio/optimus/
This just seems to be a perfect time for a merging of new technologies
for the next generation of computing.
Anyway, sorry to ramble. Just some ideas that intrigue me and thought
they might be worth tossing about a litte.
Especially if the right folks at IBM happen to be listening.
Kind regards,
-Steve Comstock
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Follow-Ups:
- Re: Musings on a holiday weekend
- From: Judah
- Re: Musings on a holiday weekend
- Prev by Date: Re: Using model DSCB
- Next by Date: Re: Using model DSCB
- Previous by thread: RE: Musings on a holiday weekend
- Next by thread: Re: Musings on a holiday weekend
- Index(es):
Relevant Pages
|
Loading
