Musings on a holiday weekend

[Steve Comstock]

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

Musings on a holiday weekend, 2

[Steve Comstock]

Oh, yeah, I forgot. The keyboard would have a simple
switch to allow data to be sent to the computer in
UTF-8, UTF-16, or UTF-32.

And those old existing programs where you don't have
the source module could run in a single 2GiB piece of
a 64-bit address space. Like a virtual machine, but
perhaps a little simpler.


-Steve

--
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

Re: Musings on a holiday weekend

[Eric Bielefeld]

Steve

Would this new system be compatable with all existing programs that now 
still run on z/OS?  I think you have to have that.  That's what makes 
z/OS such a great platform.  The program wrote 25 years ago still runs 
today.  Unless you maintain full compatability, you have nothing.  If 
you can't keep running all your old software, you may as well go to 
windows or unix.

Eric Bielefeld
Sr. Systems Programmer
414-475-7434
Milwaukee, Wisconsin


- Original Message -
From: Steve Comstock <[EMAIL PROTECTED]>
Date: Sunday, July 2, 2006 2:39 pm
Subject: Musings on a holiday weekend
To: IBM-MAIN@BAMA.UA.EDU> 
> 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.

--
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

Re: Musings on a holiday weekend

[Arthur T.]

On 2 Jul 2006 14:01:49 -0700, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] wrote:


Would this new system be compatable with all existing 
programs that now still run on z/OS?  I think you have to 
have that.  That's what makes z/OS such a great 
platform.  The program wrote 25 years ago still runs 
today.  Unless you maintain full compatability, you have 
nothing.  If you can't keep running all your old software, 
you may as well go to windows or unix.


 An even bigger problem for compatibility would be the 
data files.  If the native coding of U/OS is to be UTF-16, 
I'd expect that all of the files would also have to be 
UTF-16.  None of the existing programs could read them.


 Assembler programs would be much more difficult to 
write without some major additions of instructions.  Think 
for instance, about MVC, ED, and TRT.  Or, do you mean to 
make a byte 16 bits?  That would break *everything*.


 Also, while storage is very cheap in comparison to 
what it used to be, files would nearly double in size (as 
would memory requirements).  What would it cost do double 
your DASD farm and your memory?


 While I can admire the idea of UTF-16 as a native 
encoding, I'm not sure you can get there from here.  I 
agree with Eric that if you can't run your old programs, 
you wouldn't migrate to it; you'd run something else that 
has a track record.


--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

--
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

Re: Musings on a holiday weekend

[Steve Comstock]

Arthur T. wrote:
On 2 Jul 2006 14:01:49 -0700, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] wrote:


Would this new system be compatable with all existing programs that 
now still run on z/OS?  I think you have to have that.  That's what 
makes z/OS such a great platform.  The program wrote 25 years ago 
still runs today.  Unless you maintain full compatability, you have 
nothing.  If you can't keep running all your old software, you may as 
well go to windows or unix.


Right; so run un-convertable stuff as emulation in a 64-bit
address space; to get new system benefits you must recompile
at least, and often re-examine your code. New stuff is
golden, however.




 An even bigger problem for compatibility would be the data files.  
If the native coding of U/OS is to be UTF-16, I'd expect that all of the 
files would also have to be UTF-16.  None of the existing programs could 
read them.


 Assembler programs would be much more difficult to write without 
some major additions of instructions.  Think for instance, about MVC, 
ED, and TRT.  Or, do you mean to make a byte 16 bits?  That would break 
*everything*.


Data _could_ remain unchanged where needed; keep the existing
instruction set; would not _have_ to add any new ones. Bytes
remain at 8 bits. Look at all the new instructions already in
place for working with character and string data:

  CLST   - Compare Logical STring
  CUSE   - Compare Until Substring Equal
  MVST   - MoVe STring
  SRST   - SeaRch STring

  MVCLE  - MoVe Character Long Extended
  CLCLE  - Compare Logical Character Long Extended

  TRE- TRanslate Extended

  CUUTF  - Convert Utf-16 to UTF-8
  CUTFU  - Convert UTF-8 to Utf-16

--- all of above introduced before 2000 ---
--- below are all included in latest zSeries machines --

  PKA- PacK Ascii digit string
  PKU- PacK Utf-16 digit string
  UNPKA  - UnPacK to Ascii digit string
  UNPKU  - UnPacK to Utf-16 digit string

  MVIY   - MoVe character Intermediate Y ("long displacement")
  CLIY   - Compare Logical Intermediate Y
  CLMY   - Compare Logical under Mask Y

  TRTR   - TRanslate and Test Reverse

  CU21   - Convert Unicode 2 bytes to 1 (UTF-16 -> UTF-8)
   -- above is same as CUUTF before --
  CU12   - Convert Unicode 1 byte to 2 (UTF-8 -> UTF-16)
   -- above is same as CUTFU before --

  CLCLU  - Compare Logical Characters Long Unicode
  MVCLU  - MoVe Character Long Unicode

  TROO   - TRanslate One byte to One byte
  TROT   - TRanslate One byte to Two bytes
  TRTO   - TRanslate Two bytes to One byte
  TRTT   - TRanslate Two bytes to Two bytes

  CU24   - Convert Unicode 2 bytes to 4 bytes (UTF-16 -> UTF-32)
  CU42   - Convert Unicode 4 bytes to 2 bytes (UTF-32 -> UTF-16)
  CU41   - Convert Unicode 4 bytes to 1 byte  (UTF-32 -> UTF-8)
  CU14   - Convert Unicode 1 byte to 4 bytes  (UTF-8 -> UTF-32)

  SRSTU  - SeaRch STring Unicode

(not to mention the store and load and rotate instructions)




 Also, while storage is very cheap in comparison to what it used to 
be, files would nearly double in size (as would memory requirements).  
What would it cost do double your DASD farm and your memory?


 While I can admire the idea of UTF-16 as a native encoding, I'm not 
sure you can get there from here.  I agree with Eric that if you can't 
run your old programs, you wouldn't migrate to it; you'd run something 
else that has a track record.




That's why I was proposing an emulation in a 2 GiB piece of a 64-bit
address space.

I don't know if it is doable or not.

Just wishful thinking.

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

Re: Musings on a holiday weekend

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld
> Sent: Sunday, July 02, 2006 4:02 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Musings on a holiday weekend
> 
> 
> Steve
> 
> Would this new system be compatable with all existing 
> programs that now 
> still run on z/OS?  I think you have to have that.  That's what makes 
> z/OS such a great platform.  The program wrote 25 years ago 
> still runs 
> today.  Unless you maintain full compatability, you have nothing.  If 
> you can't keep running all your old software, you may as well go to 
> windows or unix.
> 
> Eric Bielefeld

>From what I've been told, that compatability "problem" is why FS (Future
System) did not take off as a replacement for the S/370. It eventually,
again from what I am told, became the AS/400 (iSeries). The i5/OS that
runs on the iSeries is simply amazing to me. We looked at it as a
possible replacement for z/OS. The z/OS "conversion" has been aborted by
the new CIO (nice man!). Not that we will necessarily stay on z/OS
"forever". But if we every get off of it, the plan now is because all
the functionality on it has been replaced with new systems on new
platform(s).

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law.  If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited. 
 

--
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

Re: Musings on a holiday weekend

[Knutson, Sam]

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:[EMAIL PROTECTED] 
(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:[EMAIL PROTECTED] On
Behalf Of Steve Comstock
Sent: Sunday, July 02, 2006 3:39 PM
To: IBM-MAIN@BAMA.UA.EDU
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 beginnin

Re: Musings on a holiday weekend

[Anne & Lynn Wheeler]

McKown, John wrote:

From what I've been told, that compatability "problem" is why FS (Future
System) did not take off as a replacement for the S/370. It eventually,
again from what I am told, became the AS/400 (iSeries). The i5/OS that
runs on the iSeries is simply amazing to me. We looked at it as a
possible replacement for z/OS. The z/OS "conversion" has been aborted by
the new CIO (nice man!). Not that we will necessarily stay on z/OS
"forever". But if we every get off of it, the plan now is because all
the functionality on it has been replaced with new systems on new
platform(s).


While FS was incompatible ... there were lots of other issues. It was 
extremely ambitious with seemingly every blue-sky concept that ever 
existed being thrown into the pot. At the time, I somewhat ungraciously
compared it to a cult film that had been playing continously down in 
central sq for over a decade (as the inmates being in charge of the 
institution). I also claimed that what I had running at the time was 
"better" than what was described for resource management in the FS 
architecture documents.


I believe the "nail" in the FS coffin was a study by the Houston Science 
Center ... applications run on of a FS machine built out of the same 
level technology as used in 370/195 ... would have thruput approximately 
that of 370/145 (FS hardware complexity reduced thruput by over an order 
of magnitude).


After the death of FS ... some number of people went off to Rochester 
and created the s/38 that implemented some of the concepts from FS ... 
as/400 cisc was the followon to s/38. later as/400 was ported from cisc 
technology to power/pc technology. misc. collected posts on 801, romp, 
rios, power/ps, etc

http://www.garlic.com/~lynn/subtopic.html#801

old post (in this n.g./mailing list) that has some quotes from another 
source

http://www.garlic.com/~lynn/200f.html#16 FS - IBM Future System

as mentioned in the above ... a lot of FS was reaction to appearance of 
plug-compatible controllers. recent posts mentioning working on 
plug-compatible controller as undergraduate ... and subsequent article 
that blaimed that project for the plug-compatible controller business

http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
http://www.garlic.com/~lynn/2006m.html#40 Microcomputers As A Space Spinoff
http://www.garlic.com/~lynn/2006m.html#41 Why Didn't The Cent Sign or 
the Exlamation Mark Print?


past collected posts mentioning plug compatible controllers
http://www.garlic.com/~lynn/subtopic.html#360pcm

there is some folklore that the FS mantra/direction may have contributed 
to Amdahl leaving to do (plug-compatible) high-performance 370 (processors)


past collected posts mentioning FS
http://www.garlic.com/~lynn/subtopic.html#futuresys

--
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

Re: Musings on a holiday weekend

[Ted Macneil]

>past collected posts mentioning FS
http://www.garlic.com/~lynn/subtopic.html#futuresys

With all due respect!

Is there anything you don't have a web link on/about?

I have seen other people make comments, and I agree.

I have written articles (though not as many as you), but aside from mentioning 
them once, I let it go.

Could you do so too, please?

Sent from my BlackBerry® wireless device  

--
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

Re: Musings on a holiday weekend

[David Andrews]

On Mon, 2006-07-03 at 00:00 +, Ted Macneil wrote:
> >past collected posts mentioning FS
> http://www.garlic.com/~lynn/subtopic.html#futuresys
> 
> With all due respect!

Not that we're taking a vote or anything, but I've got to say that I
appreciate Lynn's pointers.  They're a lot more useful in the archives
than some of the hangar flying that takes place around here.

-- 
David Andrews
A. Duda and Sons, Inc.
[EMAIL PROTECTED]

--
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

Re: Musings on a holiday weekend

[Steve Samson]

Complexity? Blue sky? FS was the champion. From where I sat in FS 
Architecture in the 1973 time frame, it was appalling. PFCSKs full of 
themselves and full of the concepts of C++ were able to impose their 
vision of an object-oriented computer on the hardware design. Two 
additional layers of middleware were required to present a usable 
application programming interface.


The death of FS was a most welcome event to me; the announcement of 
System/38 was a shock but at least the performance demands at that end 
of the scale were modest.


I was so relieved to be reassigned to a spot in VS2 marketing support.

Your recollection may differ. That's OK.

Steve Samson

Anne & Lynn Wheeler wrote:


While FS was incompatible ... there were lots of other issues. It was 
extremely ambitious with seemingly every blue-sky concept that ever 
existed being thrown into the pot. At the time, I somewhat ungraciously
compared it to a cult film that had been playing continously down in 
central sq for over a decade (as the inmates being in charge of the 
institution). I also claimed that what I had running at the time was 
"better" than what was described for resource management in the FS 
architecture documents.


I believe the "nail" in the FS coffin was a study by the Houston Science 
Center ... applications run on of a FS machine built out of the same 
level technology as used in 370/195 ... would have thruput approximately 
that of 370/145 (FS hardware complexity reduced thruput by over an order 
of magnitude).


After the death of FS ... some number of people went off to Rochester 
and created the s/38 that implemented some of the concepts from FS ... 
as/400 cisc was the followon to s/38. later as/400 was ported from cisc 
technology to power/pc technology. misc. collected posts on 801, romp, 
rios, power/ps, etc

http://www.garlic.com/~lynn/subtopic.html#801


--
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

Re: Musings on a holiday weekend

[Ray Mullins]

Me, too


Seriously - I enjoy reading his posts - they are shining a flashlight (or
torch, take your pick) on some of the obscure history behind decisions as to
why things are the way they are today.  And it's good for the IBM-MAIN
archives, too.

And Ted, if that was your article in the latest IBM Systems Journal, good
job!

Later,
Ray

-- 
M. Ray Mullins 
Roseville, CA, USA 
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/ 
http://www.the-bus-stops-here.org/ 

German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds. 

--ilvi 



 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews
> Sent: Monday 03 July 2006 09:27
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: Musings on a holiday weekend
> 
> On Mon, 2006-07-03 at 00:00 +, Ted Macneil wrote:
> > >past collected posts mentioning FS
> > http://www.garlic.com/~lynn/subtopic.html#futuresys
> > 
> > With all due respect!
> 
> Not that we're taking a vote or anything, but I've got to say 
> that I appreciate Lynn's pointers.  They're a lot more useful 
> in the archives than some of the hangar flying that takes 
> place around here.
> 
> --
> David Andrews
> A. Duda and Sons, Inc.
> [EMAIL PROTECTED]
> 
> --
> 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
> 
> 

--
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

Re: Musings on a holiday weekend

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/02/2006
   at 01:39 PM, Steve Comstock <[EMAIL PROTECTED]> said:

>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.

For that to be viable a lot of work would need to be put into the
transition and into inter-operability with existing systems. That
means that you would need to compromise on some things.

>* 64-bit only, from the ground up; no line; no bar

What do you do about legacy applications?

>* 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

You would still have code page issues due to communication with the
outside world.

>* One of the major problems is Unicode input,

Why is that a problem? There's UTF-8 support in, e.g., Linux, OS/2.

One thing missing from the list would be for all files to be memory
mapped.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: Musings on a holiday weekend

[Andy Wood]

On Mon, 3 Jul 2006 10:39:48 -0700, Steve Samson <[EMAIL PROTECTED]> wrote:

>Complexity? Blue sky? FS was the champion. From where I sat in FS
>Architecture in the 1973 time frame, it was appalling. PFCSKs full of
>themselves and full of the concepts of C++ were able to impose their
>vision of an object-oriented computer on the hardware design.

C++ in 1973 ???

--
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

Re: Musings on a holiday weekend

[Steve Samson]

Dunno if it was C++ for sure, but there was a lot of borrowing from some 
object-oriented programming language.


Andy Wood wrote:

On Mon, 3 Jul 2006 10:39:48 -0700, Steve Samson <[EMAIL PROTECTED]> wrote:


Complexity? Blue sky? FS was the champion. From where I sat in FS
Architecture in the 1973 time frame, it was appalling. PFCSKs full of
themselves and full of the concepts of C++ were able to impose their
vision of an object-oriented computer on the hardware design.


C++ in 1973 ???


--
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

Re: Musings on a holiday weekend, 2

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 07/02/2006
   at 01:55 PM, Steve Comstock <[EMAIL PROTECTED]> said:

>Oh, yeah, I forgot. The keyboard would have a simple
>switch to allow data to be sent to the computer in
>UTF-8, UTF-16, or UTF-32.

Why? That's the software's job.

>And those old existing programs where you don't have
>the source module could run in a single 2GiB piece of
>a 64-bit address space.

That's what we have now, but you'd also need to deal with old 64-bit
programs. Even if you have the source code it might not be
economically viable to make the requisite changes.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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