Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #235712 > unrolled thread

Harvest time!

Back to article view | Back to alt.folklore.computers

Contents

  Harvest time! David Lesher <wb8foz@panix.com> - 2026-10-01 02:06 +0000
    Re: Harvest time! Anton Antimo <anton@safunu.org> - 2026-10-01 11:26 -0300
      Re: Harvest time! Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-01 23:44 +0800
      Re: Harvest time! David LaRue <huey.dll@tampabay.rr.com> - 2026-10-01 21:22 +0000
    Re: Harvest time! Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-01 22:11 +0000
      Re: Harvest time! Lars Poulsen <lars@beagle-ears.com> - 2026-10-01 20:05 -0700
        Re: Harvest time! Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 04:50 +0000
          Re: Harvest time! Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-10-02 18:17 +0000
            Re: Harvest time! Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-02 21:44 +0000
              Re: Harvest time! Lynn Wheeler <lynn@garlic.com> - 2026-10-02 13:43 -1000
                Re: Harvest time! James Dow Allen <user4353@newsgrouper.org.invalid> - 2026-10-03 19:31 +0000
                  Re: Harvest time! Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 21:43 +0000
                  Re: Harvest time! Lynn Wheeler <lynn@garlic.com> - 2026-10-03 16:16 -1000
                    Re: Harvest time! James Dow Allen <user4353@newsgrouper.org.invalid> - 2026-10-06 21:23 +0000
    Re: Harvest time! John Levine <johnl@taugh.com> - 2026-10-02 01:48 +0000

#235712 — Harvest time!

Stumbled across:
<https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>

Perhaps old news here.


-- 
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

[toc] | [next] | [standalone]

#235713

David Lesher <wb8foz@panix.com> writes:

> Stumbled across:
> <https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
>
> Perhaps old news here.

Even if it were old news here, that's the kind of subject that people
here would always like to talk about again.

[toc] | [prev] | [next] | [standalone]

#235714

On 10/1/2026 10:26 PM, Anton Antimo wrote:
> David Lesher <wb8foz@panix.com> writes:
> 
>> Stumbled across:
>> <https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
>>
>> Perhaps old news here.
> 
> Even if it were old news here, that's the kind of subject that people
> here would always like to talk about again.

I haven't read it, but /The Code Breakers/ by David Kahn doesn't seem to
cover this particular machine, by the table of contents.  So maybe this
is buried in the N.S.A. chapter, or is new evidence that will surface in
a later edition than I have?

In any case, we should always define the N.S.A. as a lurker here in alt.
folklore.computers, and I'm sure they'd love to comment, but are only
given read-only news servers.  Those poor N.S.A. agents.


Best wishes, and happy three letter agencies!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#235715

Anton Antimo <anton@safunu.org> wrote in news:87jyo18pk7.fsf@safunu.org:

> David Lesher <wb8foz@panix.com> writes:
> 
>> Stumbled across:
>> <https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
>>
>> Perhaps old news here.
> 
> Even if it were old news here, that's the kind of subject that people
> here would always like to talk about again.

Wonderful memories and so many more articles to read!

Thanks, David and Anton

[toc] | [prev] | [next] | [standalone]

#235716

On Thu, 1 Oct 2026 02:06:08 -0000 (UTC), David Lesher wrote:

> Stumbled across:
> <https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>

It’s not made clear in the description, but that machine seems to be
more some kind of bulk text comparator, not a number-cruncher like the
Cray.

That would make sense if you consider that IBM machines were always
more about data processing than powerful computations. The STRETCH
machine was mentioned as failing to meet its performance goals; that
was part, perhaps even the start, of IBM’s long history of
overpromising and underdelivering.

[toc] | [prev] | [next] | [standalone]

#235718

On 10/1/2026 15:11, Lawrence D’Oliveiro wrote:
> On Thu, 1 Oct 2026 02:06:08 -0000 (UTC), David Lesher wrote:
> 
>> Stumbled across:
>> <https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
> 
> It’s not made clear in the description, but that machine seems to be
> more some kind of bulk text comparator, not a number-cruncher like the
> Cray.
> 
> That would make sense if you consider that IBM machines were always
> more about data processing than powerful computations. The STRETCH
> machine was mentioned as failing to meet its performance goals; that
> was part, perhaps even the start, of IBM’s long history of
> overpromising and underdelivering.

I feel there is a bit more snark here than I find justified. The goal 
was a very large stretch, and the attempt to reach it did indeed advance 
the state of the art a great deal, paving the way for the 360 series.

-- 
Lars Poulsen - an old geek in Santa Barbara, California

[toc] | [prev] | [next] | [standalone]

#235719

On Thu, 1 Oct 2026 20:05:04 -0700, Lars Poulsen wrote:

> On 10/1/2026 15:11, Lawrence D’Oliveiro wrote:
>>
>> The STRETCH machine was mentioned as failing to meet its
>> performance goals; that was part, perhaps even the start, of IBM’s
>> long history of overpromising and underdelivering.
>
> I feel there is a bit more snark here than I find justified. The
> goal was a very large stretch, and the attempt to reach it did
> indeed advance the state of the art a great deal, paving the way for
> the 360 series.

That, too, led to another instance of overpromising and
underdelivering, with IBM’s FUD campaign to stop potential customers
buying machines from CDC.

[toc] | [prev] | [next] | [standalone]

#235720

On 2026-10-02, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:

> On Thu, 1 Oct 2026 20:05:04 -0700, Lars Poulsen wrote:
>
>> On 10/1/2026 15:11, Lawrence D’Oliveiro wrote:
>>>
>>> The STRETCH machine was mentioned as failing to meet its
>>> performance goals; that was part, perhaps even the start, of IBM’s
>>> long history of overpromising and underdelivering.
>>
>> I feel there is a bit more snark here than I find justified. The
>> goal was a very large stretch, and the attempt to reach it did
>> indeed advance the state of the art a great deal, paving the way for
>> the 360 series.
>
> That, too, led to another instance of overpromising and
> underdelivering, with IBM’s FUD campaign to stop potential customers
> buying machines from CDC.

To be honest, though, this was standard behaviour throughout the
industry.  I worked for Sperry->Unisys for four years, and saw
many instances of lowballing memory requirements to get a sale
(the customer would later have to spring for additional memory,
but the sale had been made by then).  I finally left when I got
tired of keeping salesmen's promises for them.

-- 
/~\  Charlie Gibbs                  |  In this world there are
\ /  <cgibbs@kltpzyxm.invalid>      |  two kinds of people:
 X   I'm really at ac.dekanfrus     |  1. Those who can extrapolate
/ \  if you read it the right way.  |  from incomplete data.

[toc] | [prev] | [next] | [standalone]

#235721

On Fri, 02 Oct 2026 18:17:24 GMT, Charlie Gibbs wrote:

> On 2026-10-02, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>
>> On Thu, 1 Oct 2026 20:05:04 -0700, Lars Poulsen wrote:
>>
>>> On 10/1/2026 15:11, Lawrence D’Oliveiro wrote:
>>>>
>>>> The STRETCH machine was mentioned as failing to meet its
>>>> performance goals; that was part, perhaps even the start, of
>>>> IBM’s long history of overpromising and underdelivering.
>>>
>>> I feel there is a bit more snark here than I find justified. The
>>> goal was a very large stretch, and the attempt to reach it did
>>> indeed advance the state of the art a great deal, paving the way
>>> for the 360 series.
>>
>> That, too, led to another instance of overpromising and
>> underdelivering, with IBM’s FUD campaign to stop potential
>> customers buying machines from CDC.
>
> To be honest, though, this was standard behaviour throughout the
> industry. I worked for Sperry->Unisys for four years, and saw many
> instances of lowballing memory requirements to get a sale (the
> customer would later have to spring for additional memory, but the
> sale had been made by then). I finally left when I got tired of
> keeping salesmen's promises for them.

IBM went much, much further. Remember, they pioneered the concept of
“FUD” (“Fear, Uncertainty and Doubt”) to scare customers off rivals’
products, as notoriously happened with CDC. They didn’t have product
superiority, but they had marketing superiority. Their products were
clunky, expensive and inflexible, as well as being outdated in many
ways, but they still dominated the market (at least for mainframes)
because “nobody got fired for buying IBM”.

[toc] | [prev] | [next] | [standalone]

#235722

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> IBM went much, much further. Remember, they pioneered the concept of
> “FUD” (“Fear, Uncertainty and Doubt”) to scare customers off rivals’
> products, as notoriously happened with CDC. They didn’t have product
> superiority, but they had marketing superiority. Their products were
> clunky, expensive and inflexible, as well as being outdated in many
> ways, but they still dominated the market (at least for mainframes)
> because “nobody got fired for buying IBM”.

Amdahl won the battle to make ACS, 360 compatible ... and he left when
it was killed (folklore that they were afraid ACS/360 would advance the
state of art too fast and IBM woould loose control of the market).
https://people.computing.clemson.edu/~mark/acs_end.html

above list most aggregate MIPS was 360/65 at 23%, univac 1108 2nd at 14%
and CDC 6600 3rd at 10%

About the same time, I was undergraduate and hired fulltime into small
group in Boeing CFO office to help with the formation of Boeing Computer
Service (consolidate all dataprocessing into independent business
unit). I think Renton datacenter largest in the world. 360/65s arriving
faster than they could be installed (boxes constantly staged in hallways
around the machine room) ... comments that Boeing was ordering 360/65s
like other companies ordered keypunch machines. Both IBM and Boeing told
story than day 360 was announced (7Apr1964), Boeing walks in with order
making the IBM marketing rep highest paid IBM employee that year (still
straight commission, following year IBM moves to quota). When I
graduate, I join the IBM Cambridge Scientific Center (instead of staying
with Boeing CFO).

In 1st part of 70s, IBM has "Future System" project. During "FS",
internal politics was killing off 370 efforts and the lack of new 370s
is credited with giving the clone 370 makers their market foothold (and
marketing "FUD", Fear, Uncertainty, Doubt; really came to
forefront. When FS finally implodes there is mad rush to get stuff back
into the 370 product pipelines ... including kicking off the quick and
dirty 3033 and 3081 efforts in parallel
http://www.jfsowa.com/computer/memo125.htm
https://en.wikipedia.org/wiki/IBM_Future_Systems_project
https://people.computing.clemson.edu/~mark/fs.html

... from "Computer Wars: The Post-IBM World"
https://www.amazon.com/Computer-Wars-The-Post-IBM-World/dp/1587981394/

... and perhaps most damaging, the old culture under Watson Snr and Jr
of free and vigorous debate was replaced with *SYNCOPHANCY* and *MAKE NO
WAVES* under Opel and Akers. It's claimed that thereafter, IBM lived in
the shadow of defeat ... But because of the heavy investment of face by
the top management, F/S took years to kill, although its wrong
headedness was obvious from the very outset. "For the first time, during
F/S, outspoken criticism became politically dangerous," recalls a former
top executive

... snip ...

trivia: 3081 was going to only be multiprocessor systems. The 1st 3081D
ship was 2-CPU that had less aggregate MIPs than the Amdahl single
processor. IBM doubles the 3081 processor caches for 3081K, bringing
aggregate MIPS up to about the same as Amdahl 1-CPU. However, IBM's
favorite son batch operating system ("MVS") documentation had its 2-CPU
only getting 1.2-1.5 times throughput of one CPU (because of inefficient
multiprocessor support), as a result a MVS 3081K (with approx same
aggregate MIPs) only had .6-.75 throughput as a MVS 1-CPU Amdahl.

trivia2: also after FS implodes, I got asked to help with 16-CPU 370 and
we con the 3033 processor engineers working on it in their spare time (a
lot more interesting than remapping 168 logic to 20% faster
chips). Everybody thought it was great until somebody tells the head of
POK (IBM high-end processors) that it could be decades before IBM's
favorite son batch operating system ("MVS") had (effective) 16-CPU
support (IBM doesn't ship 16-CPU system until after turn of the
century) and some of us were told to never visit POK again (and the 3033
processor engineers were told, "heads down and no distractions").

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#235723

Lynn Wheeler <lynn@garlic.com> posted: 
> Amdahl won the battle to make ACS, 360 compatible ... and he left when
> it was killed (folklore that they were afraid ACS/360 would advance the
> state of art too fast and IBM woould loose control of the market).
> https://people.computing.clemson.edu/~mark/acs_end.html

That acs_end.html file, discussing designs of the late 1960's
contains many lines like
> the current ACS design needs 7 levels of logic per stage,
> thus 12.5 nsec cycle time ...

This confuses me.  The 370/168 -- dominant until the 3033 in the late 1970's
-- had 80 nsec "cycle time", and logic gate delays
were about 2 nsec minimum even without considering line delays or anything
more complicated than OR or NOR.  Even the mini-"cycles" on the 370/135
were 55 nsec IIRC.  What are these super-short "cycle times" repeated
throughout that document?

I consulted for NatSemi in 1980; they had purchased Exsysco, which had
built a 370/158 "lookalike," and was then attempting a 3033 lookalike.
Two interesting anecdotes about these machines:

(1) Exsysco's "AS" (158 lookalike) machines came in two models,
one significantly faster (and more expensive) than the other.
An anecdote repeated so often that I assume it was true was that the
slow machine could be converted into the faster machine by adding
(or removing) a single wire!  Supposedly some of the NatSemi/Exsysco
FE's went into business removing that wire for customers!

(2) The 3033 lookalike was never completed:  A prototype was built but it
never ran at the 3033 57-nsec cycle time, and no slower speed was
acceptable.  I was consulting for a different project, but the 3033-
lookalike director wanted to hire me when that small project was complete.
Stupidly I began looking at their 3033-lookalike without a contract
and delivered a preliminary report.  Exsysco used much larger
circuit boards than IBM and I wondered if this "failure to take
advantage of the 3rd dimension" imposed a speed penalty.  Already
pessimistic, management canceled the whole project upon that
(uncompensated!) report.

I think IBM sought to make things difficult for these "lookalike"
competitors.  As just one example, consider the SE instructions
(E5 opcode?) introduced in 1978.  ALL previous instructions had
B+ddd as the meaning of the 2nd or 3rd halfword in an instruction.
Did IBM deviate (unnecessarily) from this in hope of making life
difficult for firms that were doing the B+ddd automatically?

[toc] | [prev] | [next] | [standalone]

#235724

On Sat, 03 Oct 2026 19:31:25 GMT, James Dow Allen wrote:

> I think IBM sought to make things difficult for these "lookalike"
> competitors.

Surprising they didn’t do what Intel and ARM did: claim copyrights
and/or patents on the instruction set.

IBM was already known as the single biggest holder (hoarder?) of
patents in the computing industry, possibly even any industry at the
time. They (in)famously held, and enforced, a patent on blinking a
terminal cursor by XORing bits. Surely an instruction set would be
something even less trivial than that?

[toc] | [prev] | [next] | [standalone]

#235725

James Dow Allen <user4353@newsgrouper.org.invalid> writes:
> This confuses me.  The 370/168 -- dominant until the 3033 in the late 1970's
> -- had 80 nsec "cycle time", and logic gate delays
> were about 2 nsec minimum even without considering line delays or anything
> more complicated than OR or NOR.  Even the mini-"cycles" on the 370/135
> were 55 nsec IIRC.  What are these super-short "cycle times" repeated
> throughout that document?

165 370 microcode finished 370 instruction on avg. of one every 2.1
machine cycle.

168 improved 370 microcode so it finished 370 instruction on avg of one
every 1.6 machine cycle.

3033 started out remapping 168 logic to 20% faster chips and then
improving 370 microcode so it finished 370 instruction on avg of one
every machine cycle

for the 303x "channel director" they took 158 engine with just
the integrated channel microcode.

a 3031 was two 158 engines, one with just the 370 microcode and
the other with just the integrated channel microcode..

a 3032 was 168 reworked to use 303x channel director (158 engine
with just the integrated channel microcode).

a "3033" could have up to three 303x channel directors (overall 3033 was
about 50% faster than 168-3, combination of 20% faster chips and more
optimizing of 370 microcode) but 303x channel director was slower
on parts of channel program execution (i.e. 168 extermal channels
had faster hardware the channel director 158 engine)

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#235726

Lynn Wheeler <lynn@garlic.com> posted:

> James Dow Allen <user4353@newsgrouper.org.invalid> writes:
> > This confuses me.  The 370/168 -- dominant until the 3033 in the late 1970's
> > -- had 80 nsec "cycle time", and logic gate delays
> > were about 2 nsec minimum even without considering line delays or anything
> > more complicated than OR or NOR.  Even the mini-"cycles" on the 370/135
> > were 55 nsec IIRC.  What are these super-short "cycle times" repeated
> > throughout that document?
> 
> 165 370 microcode finished 370 instruction on avg. of one every 2.1
> machine cycle.

Interesting.  But irrelevant to my query which is about the wrong-looking
nanoseconds per cycle, and NOT about cycles per 370 instruction.

[toc] | [prev] | [next] | [standalone]

#235717

According to David Lesher  <wb8foz@panix.com>:
>Stumbled across:
><https://spectrum.ieee.org/cold-war-codebreaker-nsa-ibm>
>
>Perhaps old news here.

Harvest was declassified after it was retired in 1976. It was a custom
coprocessor for the STRETCH supercomputer that also incuded TRACTOR
cartridge tape drives with an automated tape library.

Apparently the NSA would have kept using it but the company
that made spare parts for TRACTOR was out of business.

There's a nice Wikipedia article.  I see the early versions
of that article were written by the same guy who wrote the
Spectrum article.

https://en.wikipedia.org/wiki/IBM_7950_Harvest

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [standalone]

Back to top | Article view | alt.folklore.computers

csiph-web