From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fdb77,c9f2b97a84c48976 X-Google-Attributes: gidfdb77,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-ArrivalTime: 2001-07-05 07:19:51 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!62.112.0.25!newsfeed.online.be!psiuk-p2!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml,comp.lang.java.advocacy Subject: Re: Market pressures for more reliable software Date: Thu, 5 Jul 2001 09:27:49 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9i1q0r$324$1@nh.pace.co.uk> References: <9gsvr7$7ho$1@nh.pace.co.uk> <9folnd$1t8$1@nh.pace.co.uk> <3B1FE1FE.B49AE27F@noaa.gov> <9fotpi$4k6$1@nh.pace.co.uk> <3b24dc21$1@news.tce.com> <3B25D5FB.15C9B240@dresdner-bank.com> <9g5as6$hbq$1@magnum.mmm.com> <9g5ipg$roq$1@nh.pace.co.uk> <9g614i$at4$1@magnum.mmm.com> <9g7r02$mni$1@nh.pace.co.uk> <3b366a2b$6$fuzhry$mr2ice@va.news.verio.net> <9h7guv$pt1$1@nh.pace.co.uk> <3B3879CE.AC550F8E@acm.org> <3B3E73E8.F9C36524@ix.netcom.com> <3B405DDF.5C3F9207@acm.org> <3B416975.D7F0691D@ix.netcom.com> <3B432AD8.3828FB9@acm.org> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 994339675 3140 136.170.200.133 (5 Jul 2001 13:27:55 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 5 Jul 2001 13:27:55 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:9470 comp.lang.java.programmer:80680 comp.lang.pl1:1201 comp.lang.vrml:3983 comp.lang.java.advocacy:22689 Date: 2001-07-05T13:27:55+00:00 List-Id: You're wasting your breath. Sometimes people have such a strong need to be right that they'll ignore all the reasoning and evidence to the contrary - convoluting logic, redefining terminology, etc.. Often the original point is totally forgotten in defending a position that isn't even related to it. Move on to more productive concerns. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Gary Labowitz" wrote in message news:zWX07.100$9d.9473@newshog.newsread.com... > This is getting ridiculous. You are SO hoping that computing and programming > were not centralized that you skip an entrie generation. > When most people talk about early days, they mean when computers actually > came into the marketplace and were large centralized systems. Certainly > programmers could be stationed anywhere. But terminal systems (starting with > the various 1050-type systems) weren't available in the "early days." > Actually, I remember the introduction of the 1050 as a big deal (about 1963 > or so, maybe a little later). To get programming into the machine it first > had to be keypunched, and that was almost always "centralized." You sent > your coding sheets to the center to be keypunched. Some of us would go there > ourselves and do our own keypunching (those that typed). On the Univac-I we > went to the computer and used the console keypunch. > Anyway, the later systems developed the RJE-type systems, which > decentralized the point at which program streams could be entered and > printed. They still connected to centralized processing, however. Since all > the terminals were dumb, there was only decentralized job entry and > printing. > The real point is: so what? So you said "in the early days we had > decentralized computing" and were wrong. > Live with it. > Let's get on with today's problems. > Gary > "Shmuel (Seymour J.) Metz" wrote in message > news:3B432AD8.3828FB9@acm.org... > > > > > > Lao Xiao Hai wrote: > > > > > I must be missing the point. What was not centralized? > > > > As I said multiple times, programming. > > > > > > > Programming was pretty > > > much centralized and under the control of a data processing manager. > Computers > > > were pretty much centralized, and there weren't that many that could > drive remote > > > terminals really well. > > > > Well enough. Can you say RAX? QUICKTRAN? CRBE? CRJE? RJE? SGJP? ATS? HASP > Multileaving? And > > that's just IBM supplied. There were also ALPHA, ROSCOE (nee WRAP) and > Wylbur on S/360, and > > others on non-IBM hardware. There was enough time sharing and remote batch > to drive a market > > in plug-compatible terminals and modems. > > > > > Most of the data processing was in batch mode. > > > > Which doesn't make it centralized. > > > > > > > That is not how I remember it. > > > > Clearly. Either your experience was limited or your memory is faulty. > > > > > > > > > Most of the programs I recall were written by the > > > programmers > > > at the service bureau. Some were packages purchased from elsewhere. > It was the rare > > > customer who had programming resources on which they could rely for > their own software. > > > > By the 70s most service bureaus were offering remote access. Ever wonder > why? > > > > > > > Not that common. > > > > Common enough to drive a market in brand X clones of terminals and modems, > e.g., Cope 45 for > > remote batch, Vadic modems. > > > > > > > And it was expensive. > > > > TI 700s were dirt cheap in the 70s and 80s, as were acoustic couplers. > > > > > > > I have done both. Certainly a lot of scientific computing was done > using remote > > > computers. However, I recall quite vividly those sites that had their > own IBM 1130 > > > and did their own Fortran programming. I spent many late night hours > writing Fortran II > > > and debugging on the 1130. > > > > And how many of those 1130s cost $150,000? To say nothing of the fact that > a lot of them were > > submitting jobs to larger machines. > > > > > > > The IBM 1401 was the workhorse of industry for a long time. > > > > And cost nowhere near $150,000. > > > > > > > Oh, and you forgot one of my personal favorites, the CDC > > > 160 series. > > > > I didn't forget it, any more than I forgot LGP or RCA; I omitted it > because I was > > concentrating on the IBM marketplace. > > > > > The IBM System 360 series came along in 1964 and, along with its > > > clones and cousins, did required lots of memory, lots of dollars, and > lots of > > > programming talent. > > > > The S/360 may have required lots of memory, but the most it would take was > 64K. The 360/20 was > > even smaller. > > > > > > > I am noticing that some very large organizations are moving back to a > more centralized > > > computing authority. User developed applications (UDA's) are getting > out-of-hand > > > and instead of saving money, are costing money. Worse, many of the > amateur > > > programmers who create UDA's are failing to build in the kinds of error > control and > > > security one would expect of more rigorously defined software. This is > creating > > > vulnerabilities that would not have been tolerated in the centralized > era. > > > > Those shops that were centralized in the old days had their own horror > stories. Things like > > configuration management and backups were often slipshod, if they existed > at all. Some of the > > decentralized shops had their act together better than some of the > centralized shops. > > > > -- > > Shmuel (Seymour J.) Metz > > > > > >