Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #158899 > unrolled thread
| Started by | philo <philo@privacy.net> |
|---|---|
| First post | 2016-02-05 11:25 -0600 |
| Last post | 2016-02-13 11:33 +0000 |
| Articles | 20 on this page of 190 — 34 participants |
Back to article view | Back to alt.folklore.computers
Qbasic philo <philo@privacy.net> - 2016-02-05 11:25 -0600
Re: Qbasic Gene Wirchenko <genew@telus.net> - 2016-02-05 14:56 -0800
Re: Qbasic philo <philo@privacy.net> - 2016-02-05 18:13 -0600
Re: Qbasic Michael Black <et472@ncf.ca> - 2016-02-05 22:40 -0500
Re: Qbasic philo <philo@privacy.net> - 2016-02-05 22:32 -0600
Re: Qbasic "Gene Buckle" <gene.buckle@bbs.retroarchive.org.remove-3hg-this> - 2016-02-11 10:22 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-11 17:16 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-11 18:49 -0800
Re: Qbasic philo <philo@privacy.net> - 2016-02-12 05:25 -0600
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-12 11:50 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-12 14:02 +0000
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-12 23:24 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:50 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-12 06:53 -0500
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-12 13:40 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:53 -0800
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-13 14:37 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-12 14:04 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:55 -0800
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-12 20:49 +0000
Re: Qbasic Bob Eager <news0006@eager.cx> - 2016-02-12 23:21 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 15:55 -0800
Re: Qbasic Bob Eager <news0006@eager.cx> - 2016-02-13 00:26 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 15:55 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-12 21:09 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-12 17:11 -0600
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-12 23:27 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 06:26 -0500
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 15:54 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:34 -0800
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-17 19:56 +0000
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-17 12:48 -0800
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-17 18:52 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 19:23 -0800
Re: Qbasic "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-18 12:00 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-18 15:02 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 20:36 -0500
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-19 04:14 +0000
Re: Qbasic "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-19 20:05 -0600
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-19 21:34 -0500
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-20 08:03 -0600
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-20 11:09 -0500
Re: Qbasic JimP <solosam90@gmail.com> - 2016-02-20 10:39 -0600
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-20 12:05 -0600
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 13:47 -0600
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-20 14:21 -0600
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 18:06 -0600
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-20 18:57 +0000
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 14:02 -0600
Re: Qbasic Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-02-20 16:51 -0400
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-18 21:34 +0000
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-18 06:25 +0000
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-18 14:17 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-18 11:33 -0600
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-18 17:41 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-18 14:54 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-17 18:41 -0700
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 20:14 -0500
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-18 20:54 -0600
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-19 11:44 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-13 12:24 -0600
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-12 23:26 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-13 07:43 -0700
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 10:29 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 08:20 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 09:21 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 12:44 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 11:31 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 15:52 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 13:02 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 16:58 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 20:24 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 21:39 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 14:17 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 20:00 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 17:52 -0800
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-13 19:28 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 21:32 -0800
Re: Qbasic David Wade <dave.g4ugm@gmail.com> - 2016-02-14 14:59 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-14 10:15 -0800
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-14 09:48 -0800
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-14 12:01 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 19:36 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 20:35 -0800
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 10:15 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 08:20 -0800
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-14 14:31 -0600
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 19:33 -0500
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-16 18:52 -0700
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 14:04 -0800
Re: Qbasic Morten Reistad <first@last.name,invalid> - 2016-02-13 23:18 +0100
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-13 17:25 -0600
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 19:42 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 20:30 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 21:49 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 06:36 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 08:23 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 08:27 -0800
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-16 18:52 -0700
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-15 21:27 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-15 14:30 -0800
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-15 23:38 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:23 -0800
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-15 20:49 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-16 07:07 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-16 10:33 +0100
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-16 13:43 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-16 15:21 +0100
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:30 -0800
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-17 19:49 +0000
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-18 13:58 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-18 16:53 +0100
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-19 14:24 +0000
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-20 05:09 +1100
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 03:30 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-20 19:06 +0100
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 05:55 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-20 21:42 +0100
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 12:05 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-20 16:24 -0600
Re: Qbasic Anonymous <no_email@invalid.invalid> - 2016-02-21 00:26 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-19 11:15 -0700
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-21 03:43 +1100
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 18:36 +0000
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 03:31 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-20 19:13 +0100
Re: Qbasic "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-21 06:00 +1100
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-16 10:10 -0800
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 18:32 +0000
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-16 21:08 +0000
Re: Qbasic Stan Barr <plan.b@bluesomatic.org> - 2016-02-16 08:20 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-16 18:52 -0700
Re: Qbasic Lawrence Statton <lawrence@senguio.mx> - 2016-02-16 20:30 -0600
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-17 04:17 +0000
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-17 11:25 -0800
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 17:25 +0100
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-13 11:34 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 16:47 -0500
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-14 04:09 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-14 12:12 -0500
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 19:39 -0500
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-14 19:55 -0500
Re: Qbasic Dan Espen <despen@verizon.net> - 2016-02-14 20:08 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-14 20:41 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-15 12:06 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-15 09:21 -0800
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-15 09:29 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-15 21:22 +0000
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-15 13:39 -0500
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-15 21:20 +0000
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 09:18 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 13:07 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 10:48 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 15:49 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 14:09 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 19:56 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 17:43 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-14 04:16 +0000
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 23:35 +0100
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 20:08 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-13 17:55 -0800
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-14 04:14 +0000
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-14 08:48 -0700
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 16:13 +0100
Re: Qbasic "Blanco" <rko4410@gmail.com> - 2016-02-14 04:44 +1100
Re: Qbasic Morten Reistad <first@last.name.invalid> - 2016-02-13 23:30 +0100
Re: Qbasic "Blanco" <rko4410@gmail.com> - 2016-02-14 13:27 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-14 13:43 -0600
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-15 07:31 +1100
Re: Qbasic pechter@pechter.dyndns.org (William Pechter) - 2016-02-12 17:38 +0000
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-12 19:33 -0500
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-12 09:51 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-12 19:24 -0500
Re: Qbasic jmfbahciv <See.above@aol.com> - 2016-02-13 14:37 +0000
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-13 10:24 -0500
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-12 23:20 -0800
Re: Qbasic "gareth" <no.spam@thank.you.invalid> - 2016-02-13 11:09 +0000
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-14 00:53 +0000
Re: Qbasic Roberto Waltman <usenet@rwaltman.com> - 2016-02-15 23:30 -0500
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-16 15:56 +0000
Re: Qbasic Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-13 11:33 +0000
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-02-13 12:24 -0600 |
| Message-ID | <n9ns72$44p$1@dont-email.me> |
| In reply to | #159212 |
On 13-Feb-16 01:27, hancock4@bbs.cpcn.com wrote: > Stephen Sprunk wrote: >> You don't need a 30-year-old CPU; a modern CPU will run 16-bit code >> just fine under a 16-bit or 32-bit OS, just not under a 64-bit OS. > > Can the 64 bit OS be 'adjusted' somehow to accept 16 bit code? 16-bit protected mode applications could run under a long mode OS, in theory, but there are so few* that it's not worth the effort. 16-bit real mode applications can only run in real or virtual modes, but neither is available under a long mode OS. Neither AMD nor Intel seems interested in removing that limitation. 16-bit unreal mode applications can only run in real mode; they can't even run under a protected mode OS, much less a long mode one. * Except Win16 installers for older Win32 apps; Win64 recognizes (most of) these and substitutes a special Win32 installer that can read the Win16 installers' data files and emulate their behavior. Clever. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-12 23:26 -0800 |
| Message-ID | <f3a17520-f710-4750-9fac-fb1211f81547@googlegroups.com> |
| In reply to | #159201 |
On Friday, February 12, 2016 at 4:09:48 PM UTC-5, Scott Lurndal wrote: > It wasn't a mistake, it was a smart decision. You want to run 30 year > old software, buy a 30-year old CPU. Just as an aside, in the mainframe world, we routinely ran 30 or even 40 year old software. The 30 y/o stuff runs native mode. If the 40 y/o stuff was written for S/360, it will run native mode. If it was written for a prior generation of hardware, it would run under emulation.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-13 07:43 -0700 |
| Message-ID | <630582847.477066945.696306.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159211 |
<hancock4@bbs.cpcn.com> wrote: > On Friday, February 12, 2016 at 4:09:48 PM UTC-5, Scott Lurndal wrote: > > >> It wasn't a mistake, it was a smart decision. You want to run 30 year >> old software, buy a 30-year old CPU. > > Just as an aside, in the mainframe world, we routinely ran 30 or even > 40 year old software. The 30 y/o stuff runs native mode. If the 40 y/o > stuff was written for S/360, it will run native mode. If it was written > for a prior generation of hardware, it would run under emulation. > > Most companies try to develop products that give the customer what he wants. Microsoft develops products that give the customer what microsoft wants. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-02-13 10:29 -0500 |
| Message-ID | <MPG.312915dabccb039989f6c@news.eternal-september.org> |
| In reply to | #159230 |
In article <630582847.477066945.696306.peter_flass- yahoo.com@news.eternal-september.org>, peter_flass@yahoo.com says... > > <hancock4@bbs.cpcn.com> wrote: > > On Friday, February 12, 2016 at 4:09:48 PM UTC-5, Scott Lurndal wrote: > > > > > >> It wasn't a mistake, it was a smart decision. You want to run 30 year > >> old software, buy a 30-year old CPU. > > > > Just as an aside, in the mainframe world, we routinely ran 30 or even > > 40 year old software. The 30 y/o stuff runs native mode. If the 40 y/o > > stuff was written for S/360, it will run native mode. If it was written > > for a prior generation of hardware, it would run under emulation. > > > > > > Most companies try to develop products that give the customer what he > wants. Microsoft develops products that give the customer what microsoft > wants. We're currently porting some code written in Fortran in the early '70s to C, mostly because IBM hasn't issued a version upgrade of Fortran on the mainframe since some time in the '80s. It's not EOL--they'll fix bugs if they find them and when they add new features to the hardware they _may_ update the compiler to provide support for them.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-13 08:20 -0800 |
| Message-ID | <ee76a632-d12e-4ed1-9221-33c80c9b6a75@googlegroups.com> |
| In reply to | #159233 |
On Saturday, February 13, 2016 at 8:28:11 AM UTC-7, J. Clarke wrote: > In article <630582847.477066945.696306.peter_flass- > yahoo.com@news.eternal-september.org>, peter_flass@yahoo.com says... > > Most companies try to develop products that give the customer what he > > wants. Microsoft develops products that give the customer what microsoft > > wants. > We're currently porting some code written in Fortran in the early '70s > to C, mostly because IBM hasn't issued a version upgrade of Fortran on > the mainframe since some time in the '80s. It's not EOL--they'll fix > bugs if they find them and when they add new features to the hardware > they _may_ update the compiler to provide support for them. Well, that's IBM trying to serve the customers it has. It sells System z architecture at premium prices, mainly to people who want to use its premium database products that run the most robustly on its legacy hardware. Its main competition is Oracle. People wanting to do scientific computation on IBM hardware are expected to use PowerPC hardware, which offers better price-performance. Fortran for that hardware, I presume, is kept more up-to-date. John Savard
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-13 09:21 -0800 |
| Message-ID | <3ff4725a-c9ed-41e6-aa4d-1721afc59cae@googlegroups.com> |
| In reply to | #159236 |
On Saturday, February 13, 2016 at 11:20:43 AM UTC-5, Quadibloc wrote: > People wanting to do scientific computation on IBM hardware are expected to use > PowerPC hardware, which offers better price-performance. Fortran for that > hardware, I presume, is kept more up-to-date. There's a lot of stuff on the IBM website about their efforts in Power PC Fortran. I think big number crunchers like the weather bureau make use of it.
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-02-13 12:44 -0500 |
| Message-ID | <MPG.3129357287646d53989f6d@news.eternal-september.org> |
| In reply to | #159236 |
In article <ee76a632-d12e-4ed1-9221-33c80c9b6a75@googlegroups.com>, jsavard@ecn.ab.ca says... > > On Saturday, February 13, 2016 at 8:28:11 AM UTC-7, J. Clarke wrote: > > In article <630582847.477066945.696306.peter_flass- > > yahoo.com@news.eternal-september.org>, peter_flass@yahoo.com says... > > > > Most companies try to develop products that give the customer what he > > > wants. Microsoft develops products that give the customer what microsoft > > > wants. > > > We're currently porting some code written in Fortran in the early '70s > > to C, mostly because IBM hasn't issued a version upgrade of Fortran on > > the mainframe since some time in the '80s. It's not EOL--they'll fix > > bugs if they find them and when they add new features to the hardware > > they _may_ update the compiler to provide support for them. > > Well, that's IBM trying to serve the customers it has. The thing is they have updated their C and C++ to support 64-bit operation, there's a new Cobol coming if it's not already out, they've put Java on it, but they've left Fortran stuck in the '80s. > It sells System z architecture at premium prices, mainly to people who want to > use its premium database products that run the most robustly on its legacy > hardware. Its main competition is Oracle. > > People wanting to do scientific computation on IBM hardware are expected to use > PowerPC hardware, which offers better price-performance. Fortran for that > hardware, I presume, is kept more up-to-date. And how about people who have been doing financial computation since the '60s on that hardware?
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-13 11:31 -0800 |
| Message-ID | <1a4a2937-26e2-4d6e-be09-37bb5fa4ea86@googlegroups.com> |
| In reply to | #159244 |
On Saturday, February 13, 2016 at 10:42:53 AM UTC-7, J. Clarke wrote: > The thing is they have updated their C and C++ to support 64-bit > operation, there's a new Cobol coming if it's not already out, they've > put Java on it, but they've left Fortran stuck in the '80s. I agree that Fortran is more applicable to System z than C/C++, which are basically written around an alien architecture, being designed with the PDP-11 mindset that haunts the x86 as well. However, even IBM cannot escape the dominance of the C/C++ juggernaut, even though that language is spectacularly ill-suited to the general programming it is most often used for - as opposed to serving as a substitute for assembler, which K&R C did admirably well. John Savard
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-02-13 15:52 -0500 |
| Message-ID | <MPG.312961a3f10dedff989f73@news.eternal-september.org> |
| In reply to | #159257 |
In article <1a4a2937-26e2-4d6e-be09-37bb5fa4ea86@googlegroups.com>, jsavard@ecn.ab.ca says... > > On Saturday, February 13, 2016 at 10:42:53 AM UTC-7, J. Clarke wrote: > > > The thing is they have updated their C and C++ to support 64-bit > > operation, there's a new Cobol coming if it's not already out, they've > > put Java on it, but they've left Fortran stuck in the '80s. > > I agree that Fortran is more applicable to System z than C/C++, which are > basically written around an alien architecture, being designed with the PDP-11 > mindset that haunts the x86 as well. > > However, even IBM cannot escape the dominance of the C/C++ juggernaut, even > though that language is spectacularly ill-suited to the general programming it > is most often used for - as opposed to serving as a substitute for assembler, > which K&R C did admirably well. Quadi, please reread the first sentence of my post, the one that says: "they have updated their C and C++ to support 64-bit operation".
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-13 13:02 -0800 |
| Message-ID | <b6b41540-0ab2-403e-b956-9136c34a5d85@googlegroups.com> |
| In reply to | #159263 |
I guess I wasn't clear what my point was. I meant that it also seemed odd to me that they would neglect Fortran when they are updating C, because I, at least, didn't view C as well suited to IBM mainframes and their operating systems. John Savard
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-02-13 16:58 -0500 |
| Message-ID | <MPG.31297119984b2b02989f75@news.eternal-september.org> |
| In reply to | #159265 |
In article <b6b41540-0ab2-403e-b956-9136c34a5d85@googlegroups.com>, jsavard@ecn.ab.ca says... > > I guess I wasn't clear what my point was. I meant that it also seemed odd to me that they would neglect Fortran when they are updating C, because I, at least, didn't view C as well suited to IBM mainframes and their operating systems. > > John Savard Oh, sorry. It does seem odd. Even odder is that they've got Java available--I wouldn't expect that to fit in with mainframes at all. Note that some of our people looked into using Java for the same purpose for which we use Fortran and found it wanting, but it's been upgraded since and the IT guys would love to get funded to give it a second go.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-02-13 20:24 -0800 |
| Message-ID | <55e05f3f-9dda-4dcd-bbf0-6ed1f008700d@googlegroups.com> |
| In reply to | #159268 |
On Saturday, February 13, 2016 at 2:57:32 PM UTC-7, J. Clarke wrote: > Even odder is that they've got Java > available--I wouldn't expect that to fit in with mainframes at all. At least I understand their excuse for that: some web sites use server-side Java. So if IBM wants to sell System z boxes as web servers, they had better support Java. John Savard
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-13 21:39 -0800 |
| Message-ID | <a0387a53-975a-43a8-9dc3-d65007026170@googlegroups.com> |
| In reply to | #159320 |
On Saturday, February 13, 2016 at 11:24:35 PM UTC-5, Quadibloc wrote: > So if IBM wants to sell System z boxes as web servers, they had better support > Java. I don't work with it, but I'm told that a GUI front-end and classic COBOL CICS back-end works very well. Both IBM COBOL and CICS have all sorts modern new technology features to them. How often they're actually used I don't know.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-14 08:48 -0700 |
| Message-ID | <195574715.477156900.741647.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #159328 |
<hancock4@bbs.cpcn.com> wrote: > On Saturday, February 13, 2016 at 11:24:35 PM UTC-5, Quadibloc wrote: > > >> So if IBM wants to sell System z boxes as web servers, they had better support >> Java. > > I don't work with it, but I'm told that a GUI front-end and classic COBOL > CICS back-end works very well. > > Both IBM COBOL and CICS have all sorts modern new technology features > to them. How often they're actually used I don't know. > My last POE was all COBOL/CICS/DB2 and, I believe, still is. I think we were fairly typical. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-13 14:17 -0800 |
| Message-ID | <db106e35-ebe9-40ac-b602-b8b016462d93@googlegroups.com> |
| In reply to | #159265 |
On Saturday, February 13, 2016 at 4:02:53 PM UTC-5, Quadibloc wrote: > I guess I wasn't clear what my point was. I meant that it also seemed odd to me that they would neglect Fortran when they are updating C, because I, at least, didn't view C as well suited to IBM mainframes and their operating systems. Agreed. I don't understand why IBM pushes Fortran on another hardware line and has basically abandoned it on the mainframe (though old stuff still compiles and runs.) However, I can understand why Fortran isn't used as much in _some_ applications. A lot of engineering work that once required Fortran is now done in packages or with CAD/CAM. One engineer told me that even spreadsheets are used. Indeed, a lot of Fortran work years ago was basically using the computer as a super-calculator that could easily be done on a spreadsheet. For instance, they'd have sensors hooked up to a keypunch to punch out cards representing measurements, and the cards would get read in and processed by a formula. Presumably today a PC could do all that a lot easier. However, for "supercomputer" applications, I _guess_ that IBM no longer markets the Z series, but rather other products, like "Blue Blue". I find this curious since the Z series has enhanced instructions for doing number crunching, like several ways of floating point, 128 bit words, etc.
[toc] | [prev] | [next] | [standalone]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-02-13 20:00 -0500 |
| Message-ID | <MPG.31299bb74b919d28989f78@news.eternal-september.org> |
| In reply to | #159272 |
In article <db106e35-ebe9-40ac-b602-b8b016462d93@googlegroups.com>, hancock4@bbs.cpcn.com says... > > On Saturday, February 13, 2016 at 4:02:53 PM UTC-5, Quadibloc wrote: > > I guess I wasn't clear what my point was. I meant that it also seemed odd to me that they would neglect Fortran when they are updating C, because I, at least, didn't view C as well suited to IBM mainframes and their operating systems. > > Agreed. I don't understand why IBM pushes Fortran on another hardware > line and has basically abandoned it on the mainframe (though old stuff > still compiles and runs.) > > However, I can understand why Fortran isn't used as much in _some_ > applications. A lot of engineering work that once required Fortran is > now done in packages or with CAD/CAM. One engineer told me that even > spreadsheets are used. > > Indeed, a lot of Fortran work years ago was basically using the computer > as a super-calculator that could easily be done on a spreadsheet. For > instance, they'd have sensors hooked up to a keypunch to punch out cards > representing measurements, and the cards would get read in and processed > by a formula. Presumably today a PC could do all that a lot easier. > > However, for "supercomputer" applications, I _guess_ that IBM no longer > markets the Z series, but rather other products, like "Blue Blue". I find > this curious since the Z series has enhanced instructions for doing number > crunching, like several ways of floating point, 128 bit words, etc. I have wondered what a building full of Z cores could do and wondered why IBM has never done it, but then I wondered why the PC wasn't based on the single-chip 360 that IBM demonstrated some time before. On the other hand, nobody ever accused MVS of being user-friendly and IBM would have never second-sourced the architecture.
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-13 17:52 -0800 |
| Message-ID | <4a762613-d897-4924-b2cf-cd50dbd14b8b@googlegroups.com> |
| In reply to | #159293 |
On Saturday, February 13, 2016 at 7:59:22 PM UTC-5, J. Clarke wrote: > I have wondered what a building full of Z cores could do and wondered > why IBM has never done it, but then I wondered why the PC wasn't based > on the single-chip 360 that IBM demonstrated some time before. On the > other hand, nobody ever accused MVS of being user-friendly and IBM would > have never second-sourced the architecture. As for the PC chip, my understanding is that back in the 8088 days, low powered chips were still quite expensive. Also, the 8088 architecture initially was far simpler than S/360, and the original PC DOS was far simpler than S/360-DOS. That is, to build a chip and supporting hardware that could do everything S/360 could do would've added too much to the original cost. Remember, floating point required an extra chip, and initially, PC's maxed at 640K memory. It was later on that they added all sorts of features. In addition, while I am weak on the internals, I _suspect_ the PC chip was a better design for its application. Certainly, running a program under PC-DOS and the C:> prompt was easier than coding a series of // EXEC cards. I don't know the internals of the "Big Blue" machines vs. Z architecture. My _guess_ is that Z is more intended to serve many users--thousands of CICS terminals--while Big Blue is intended to focus on heavy number crunching. I also guess that Big Blue can do math problems faster than Z.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-02-13 19:28 -0800 |
| Message-ID | <87lh6ox96f.fsf@garlic.com> |
| In reply to | #159298 |
hancock4@bbs.cpcn.com writes: > I don't know the internals of the "Big Blue" machines vs. Z architecture. > My _guess_ is that Z is more intended to serve many users--thousands of > CICS terminals--while Big Blue is intended to focus on heavy number > crunching. I also guess that Big Blue can do math problems faster than Z. z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000 z990, 32 processors, 9BIPS, (281MIPS/proc), 2003 z9, 54 processors, 18BIPS (333MIPS/proc), July2005 z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008 z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010 EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012 z13 published refs is 30% move throughput than EC12 (or about 100MIPS) with 40% more processors ... or about 710MIPS/proc part of the issue is that memory latency when measured in count of processor cycles ... is compareable to 60s disk access when measured in count of 60s processor cycles. earlier press is that half the per processor improvement from z10 to z196 is introduction of features like out-of-order execution, branch prediction, etc. that have been in other chips for decades ... aka masking/compensation for increasing mismatch between memory latency and processor speed. per processor z196 to ec12 has more features. e5-2600v1 blade about concurrent with z196 ... 400-500+ BIPS (depending on model). A e5-2600v3 blade is rated at 2.5 times a e5-2600v1 blade, and e5-2600v4 blade is rated at 3.5 times a e5-2600v1 blade ... or over 1.5TIPS (single e5-2600v4 blade with processing power of fifteen max. configured latest z13 mainframes?) 4341 was leading edge of distributed computing tsunami (large corporations ordering hundreds at a time for placing out in departmental areas) as well as datacenter 4341 clusters had much more processing power and I/O capacity, much lower price, much less physical and environmental footprint. At one point head of POK felt it was such a threat to 3033, that he convinced corporate to cut allocation of critical 4341 manufacturing component in half. Before 4341s first shipped, I was con'ed into doing a benchmark on 4341 engineering machine in disk product test lab (bldg. 15) for LLNL who was looking at getting 70 for compute farm (leading edge of new supercomputing and cloud computing paradigm). some old email http://www.garlic.com/~lynn/lhwemail.html#4341 past posts getting to play disk engineer in bldgs14&15 http://www.garlic.com/~lynn/subtopic.html#disk in 1980, IBM STL was growing fast and had to move 300 people from the IMS group to offsite building (with computer access back into the STL datacenter). They looked at "remote" 3270 support ... but found the human factors totally unacceptable. I got sucked into do channel extension support for local channel attached 3270 controllers at the remote building. Optimization with downloading channel programs to the remote end for execution help eliminate enormous latency in channel protocol chatter ... and they didn't notice between "local" 3270 channel operation at the remote end ... and "local" 3270 channel operation in STL. some past posts http://www.garlic.com/~lynn/submisc.html#channel.extender The hardware vendor tried to get IBM to release my support for the channel extender ... but there was group in POK that objected ... they were afraid that it would make it harder to justify getting some serial stuff they were playing with, released. In 1988, I'm asked to help LLNL get some serial stuff they had standardized, which quickly morphs into fibre-channel standard ... including lots of stuff to minimize round-trip protocol chatter latency. Then the POK engineers (from 1980) finally get their stuff released as ESCON with ES/9000 when it is already obsolete. some past posts http://www.garlic.com/~lynn/submisc.html#escon Later some POK engineers get involved in fibre-channel standard and define a heavy-weight protocol that drastically reduces native throughput, which is finally released as FICON. IBM publishes a "peak i/o" benchmark for z196 that uses 104 FICON (over 104 fibre-channel) getting 2M IOPS. About the same time, there is a fibre-channel announced for e5-2600v1 blade claiming over 1M IOPS (two such fibre-channel have higher throughput than 104 FICON running over 104 fibre-channel). some past posts http://www.garlic.com/~lynn/submisc.html#ficon old posts referencing jan1992 meeting in Ellison's conference room on (commercial/DBMS) cluster scaleup http://www.garlic.com/~lynn/95.html#13 also was working with national labs (including LLNL) on cluster scaleup for numeric intensive and filesystems ... some old email http://www.garlic.com/~lynn/lhwemail.html#medusa within a month of the ellison meeting, cluster scaleup is transferred, we are told we can't work on anything with more than four processors and it is announced as supercomputer, 17Feb1992 article announcement for scientific and technical "only" http://www.garlic.com/~lynn/2001n.html#6000clusters1 11May1992 article that national lab interest in cluster scaleup caught company by "surprise" (modulo going back to 1979 and 4341 computer farm/cluster) http://www.garlic.com/~lynn/2001n.html#6000clusters2 recent posts mention e6-2600: http://www.garlic.com/~lynn/2015.html#35 [CM] IBM releases Z13 Mainframe - looks like Batman http://www.garlic.com/~lynn/2015.html#36 [CM] IBM releases Z13 Mainframe - looks like Batman http://www.garlic.com/~lynn/2015.html#39 [CM] IBM releases Z13 Mainframe - looks like Batman http://www.garlic.com/~lynn/2015.html#46 Why on Earth Is IBM Still Making Mainframes? http://www.garlic.com/~lynn/2015.html#78 Is there an Inventory of the Inalled Mainframe Systems Worldwide http://www.garlic.com/~lynn/2015.html#82 Is there an Inventory of the Installed Mainframe Systems Worldwide http://www.garlic.com/~lynn/2015c.html#29 IBM Z13 http://www.garlic.com/~lynn/2015c.html#30 IBM Z13 http://www.garlic.com/~lynn/2015c.html#93 HONE Shutdown http://www.garlic.com/~lynn/2015d.html#39 Remember 3277? http://www.garlic.com/~lynn/2015e.html#14 Clone Controllers and Channel Extenders http://www.garlic.com/~lynn/2015f.html#0 What are some of your thoughts on future of mainframe in terms of Big Data? http://www.garlic.com/~lynn/2015f.html#5 Can you have a robust IT system that needs experts to run it? http://www.garlic.com/~lynn/2015f.html#35 Moving to the Cloud http://www.garlic.com/~lynn/2015f.html#93 Miniskirts and mainframes http://www.garlic.com/~lynn/2015g.html#19 Linux Foundation Launches Open Mainframe Project http://www.garlic.com/~lynn/2015g.html#42 20 Things Incoming College Freshmen Will Never Understand http://www.garlic.com/~lynn/2015g.html#93 HP being sued, not by IBM.....yet! http://www.garlic.com/~lynn/2015g.html#96 TCP joke http://www.garlic.com/~lynn/2015h.html#2 More "ageing mainframe" (bad) press http://www.garlic.com/~lynn/2015h.html#108 25 Years: How the Web began http://www.garlic.com/~lynn/2015h.html#110 Is there a source for detailed, instruction-level performance info? http://www.garlic.com/~lynn/2015h.html#114 Between CISC and RISC http://www.garlic.com/~lynn/2016.html#15 Dilbert ... oh, you must work for IBM http://www.garlic.com/~lynn/2016.html#19 Fibre Chanel Vs FICON http://www.garlic.com/~lynn/2016b.html#23 IBM's 3033; "The Big One": IBM's 3033 -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-02-13 21:32 -0800 |
| Message-ID | <f29d8552-cfbb-487d-8772-52ded488ab66@googlegroups.com> |
| In reply to | #159313 |
On Saturday, February 13, 2016 at 10:28:12 PM UTC-5, Anne & Lynn Wheeler wrote: > z13 published refs is 30% move throughput than EC12 (or about 100MIPS) > with 40% more processors ... or about 710MIPS/proc 1976: COBOL compile 10 minutes wall clock, S/360-40, sole use of machine. 2016: COBOL compile 30 seconds wall clock, Z13, lots of other users. I have no idea of the significance of the above, if any, but that's my story and I'm sticking to it. But it would be neat to somehow go back in time to '76 and run some benchmark programs on the 360-40, then run them on the Z today and compare the results. Presumably a 3390 disk drive is faster than a 2314, and caching helps. When I changed jobs, one huge difference in speed was from the 2415 "bargain" tape drives to the 6250 bpi tape drives. I think the 6250 bpi drive could read a tape faster than the 2415 could rewind the tape. Those suckers flew!
[toc] | [prev] | [next] | [standalone]
| From | David Wade <dave.g4ugm@gmail.com> |
|---|---|
| Date | 2016-02-14 14:59 +0000 |
| Message-ID | <n9q4pb$7bj$1@news.albasani.net> |
| In reply to | #159298 |
On 14/02/2016 01:52, hancock4@bbs.cpcn.com wrote: > On Saturday, February 13, 2016 at 7:59:22 PM UTC-5, J. Clarke wrote: > > >> I have wondered what a building full of Z cores could do and wondered >> why IBM has never done it, but then I wondered why the PC wasn't based >> on the single-chip 360 that IBM demonstrated some time before. On the >> other hand, nobody ever accused MVS of being user-friendly and IBM would >> have never second-sourced the architecture. > > As for the PC chip, my understanding is that back in the 8088 days, > low powered chips were still quite expensive. Also, the 8088 architecture > initially was far simpler than S/360, and the original PC DOS was far > simpler than S/360-DOS. That is, to build a chip and supporting hardware > that could do everything S/360 could do would've added too much to the > original cost. Remember, floating point required an extra chip, and > initially, PC's maxed at 640K memory. It was later on that they added > all sorts of features. > > In addition, while I am weak on the internals, I _suspect_ the PC chip > was a better design for its application. Certainly, running a program > under PC-DOS and the C:> prompt was easier than coding a series of // EXEC > cards. > > I don't know the internals of the "Big Blue" machines vs. Z architecture. > My _guess_ is that Z is more intended to serve many users--thousands of > CICS terminals--while Big Blue is intended to focus on heavy number > crunching. I also guess that Big Blue can do math problems faster than Z. > IBM already had CMS which uses human understandable commands like "COPYFILE" "ERASE" and is pretty similar to MS-DOS in many ways. However don't think even that doesn't well in 256K memory. Dave
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web