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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
