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=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham 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: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-05 04:10:27 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!news.tele.dk!206.252.192.28!news.stealth.net!newspeer1.nac.net!news-xfer.newsread.com!bad-news.newsread.com!netaxs.com!newsread.com!POSTED.newshog.newsread.com!not-for-mail From: "Gary Labowitz" Newsgroups: comp.lang.ada,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml,comp.lang.java.advocacy 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> Subject: Re: Market pressures for more reliable software 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 Message-ID: Date: Thu, 05 Jul 2001 11:10:23 GMT NNTP-Posting-Host: 207.16.153.182 X-Complaints-To: Abuse Role , We Care X-Trace: newshog.newsread.com 994331423 207.16.153.182 (Thu, 05 Jul 2001 07:10:23 EDT) NNTP-Posting-Date: Thu, 05 Jul 2001 07:10:23 EDT Organization: ENTER.net (enter.net) Xref: archiver1.google.com comp.lang.ada:9459 comp.lang.java.programmer:80641 comp.lang.pl1:1199 comp.lang.vrml:3981 comp.lang.java.advocacy:22676 Date: 2001-07-05T11:10:23+00:00 List-Id: 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 > >