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.3 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-Thread: fdb77,c9f2b97a84c48976 X-Google-Attributes: gidfdb77,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-ArrivalTime: 2001-07-02 23:42:25 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Lao Xiao Hai 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: Mon, 02 Jul 2001 23:43:01 -0700 Organization: AdaWorks Software Engineering Message-ID: <3B416975.D7F0691D@ix.netcom.com> 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> Reply-To: richard@adaworks.com NNTP-Posting-Host: 9e.fc.c5.ed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 3 Jul 2001 06:41:57 GMT X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:9358 comp.lang.java.programmer:80215 comp.lang.pl1:1188 comp.lang.vrml:3973 comp.lang.java.advocacy:22544 Date: 2001-07-03T06:41:57+00:00 List-Id: "Shmuel (Seymour J.) Metz" wrote: > Lao Xiao Hai wrote:"Perhaps. But, for most organizations, emphasis on the word most, > computing > > > resources within an organization was under the centralized managment of > > one central authority. Moreover, most of the computing was located in one > > place. It is true that some very large corporations had computers distributed > > across their divisions, but that was a luxury not affordable by most of industry. > > You're missing the point the centralized equipment does not imply centralized use of > the equipment. I must be missing the point. What was not centralized? 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. Most of the data processing was in batch mode. > > This centralization, during the 70's and through the mid-80's even extended to > > collections of companies. Ever hear of a service bureau. > > ROTF,LMAO! Heard of them? I've worked for them. I've never heard of a service bureau > where the programming was centralized; the norm was that the customer did his own > programming. That is not how I remember it. 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. Usually, this task was contracted by the programmers within the service bureau. Later, there were independent contractors who could do this for hire by the service bureau customer. > > Networks were still a mystery for most people. > > Most people didn't work with computers. Dialup access was common in the late '60s. Not that common. And it was expensive. We used it quite sparingly in most places. > > Programmers were busy > > grinding out programs in COBOL. > > I take it that you never had anything to do with scientific computing? 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. > > Compilers needed large memory spaces > > and operating systems and these were hosted on million dollar plus machines, > > Yeah, like the 650, 1401, 1620 and 1130? Maybe they weren't glamorous, and they were > too small to be of interest to service bureaus except for the odd 1401 used as c/t and > t/p, but there were a lot of them. The IBM 1401 was the workhorse of industry for a long time. It was the first machine I learned to program. It was not cheap. In the companies where I worked on that computer, we usually had more than one, just to get the work done. There were almost no programmers from outside the company. The other computers you named were certainly small, but they were also under the control/guidance of the MIS manager at many companies. Oh, and you forgot one of my personal favorites, the CDC 160 series. 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. Most of those machines were still centralized up through the mid-1970's when the minicomputers became common. Even those minicomputers were pretty much centralized in the small businesses that leased them. There was some decentralization. But I don't recall it being as widespread as you do. This is particularly true of data processing, which was almost always centralized in those early days. It was certainly not decentralized in the way it is today. Even so, 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. Richard Riehle