Re: Market pressures for more reliable software

["Gary Labowitz" <garyl@enter.net>]

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" <nospam@acm.org> 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
>
>