Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!amdahl!acs From: acs@amdahl.UUCP (Tony Sumrall) Newsgroups: comp.sys.amiga Subject: Re: Workbench improvements Message-ID: <6439@amdahl.UUCP> Date: Sat, 2-May-87 14:33:03 EDT Article-I.D.: amdahl.6439 Posted: Sat May 2 14:33:03 1987 Date-Received: Sun, 3-May-87 06:22:55 EDT References: <1816@husc6.UUCP> <1987May2.003620.11966@gpu.utcs.toronto.edu> Reply-To: acs@amdahl.UUCP (Tony Sumrall) Organization: Amdahl Corporation, Sunnyvale CA Lines: 61 Keywords: compatibility versus radical improvements In article <1987May2.003620.11966@gpu.utcs.toronto.edu> gbs@gpu.utcs.UUCP (Gideon Sheps) writes: >In article <1816@husc6.UUCP> hadeishi@husc7.UUCP (Mitsuharu Hadeishi) writes: >>Re: Workbench improvements, compatibility, and computer revolutions > In a short reply to a long posting... Amen. Yes. Agreed. Go for it. > > Just look at ibm products (for the big machines) that make all > new advances look like 1960's technology so the os can cope! > I have a friend who uses CMS (?) and the machine considers his > terminal to be a "virtual card reader" why in 1987 is "card reader" > still in the vocabulary at ibm? IBM profits dropped sharply last year > as they have been doing for some time now. But, everythings compatible! > C-A is just off a losing streak, they should be looking at this > sort of thing for good ideas on what NOT to do. If it needs rewriting > rewrite! Damn the torpedoes full speed ahead! >-- >=========================================================================== >Gideon Sheps (or Cheops, as my Egyptian relatives spell it) >I am not a number ... ...I am a free variable ! >gbs@gpu.utcs.toronto.edu /// >gbs@utorgpu.bitnet/EARN/NetNorth \\\/// > I don't need a disclamer 'cause nobody listens to me. \\\/ >============================================================================ I'm not normally in the position of "defending" things but I'll make an exception in this case and also take this opportunity to correct a misconception (or misstatement): CMS considers your terminal to be a 3215, not a card reader. A CMS user *may* have a virtual card reader as well as a virtual printer (a 3800 if you like). The user may define 3270 terminals which other users may use. (This is an oversimplification but it is basically correct). Anyway, I've used the virtual card punch/reader many times to exchange data with other machines (let's not discuss why IBM won't support full-duplex or even intelligent half-duplex on their mainstay operating systems). It's not a problem, it's just an 80-byte wide hole thru which I shove/pull my data. Facilities exist to shove lines longer than 80 bytes through it and restore the file to its original state. When it comes to compatibility in the IBM-compatible mainframe community, the reasons are mostly economic. A large institution may have literally billions of dollars tied up in the thousands of modules that go to make up their applications. Even a simple re-compilation of the system to handle a single non-compatible item can take months and cost hundreds of thousands of dollars (something that most businesses don't generally take kindly to) and can take much longer if problems develop because of "assumptions" that programmer's have made about the system that is *not* true in the new, non-compatible system. Don't get me wrong, it *has* been done but it's not easy. There are still many many installations out there that have not yet gone to 370-XA mode (real storage sizes of 2G, smarter I/O subsystem) and that was introduced...what was it...5 years ago? The reason? - conversion costs. Should the Amiga be worried about maintaining compatibility? If the machine is ever gonna be anything other than a hacker's machine, yes. Why - for the same reasons outlined above albeit on a smaller scale. I'm not saying that change is bad, just that it must be planned and implemented very carefully (i.e. don't go off half-cocked - that's what got us into this situation in the first place). -- Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]