Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » The ICL 2900
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: The ICL 2900 [message #339644 is a reply to message #338234] Sat, 18 March 2017 13:29 Go to previous messageGo to next message
Jan van den Broek is currently offline  Jan van den Broek
Messages: 70
Registered: April 2012
Karma: 0
Member
Thu, 23 Feb 2017 23:02:27 +0100
Morten Reistad <first@last.name.invalid> schrieb:
> In article <lc-dnbUbwM8f3jLFnZ2dnUU7-Q-dnZ2d@giganews.com>,
> Jon Elson <jmelson@wustl.edu> wrote:
>> William Pechter wrote:
>>
>>
>>>
>>> As long as the toilets don't back up. I can take the clothes out
>>> to a laundromat if needed.
>> Oh, boy! When they hook the IoT to the toilets, then the hackers will
>> REALLY start to have fun (= create chaos). Oh, I just CAN'T wait for that!
>
> And just how do you think the sewer pumps in flatlands are managed?

AIUI, RS-232 and remote-connections.
--
Jan van den Broek balglaas@xs4all.nl

I have a great .sig, but it won't fit at the end of this post.
-Fermat
Re: The ICL 2900 [message #339646 is a reply to message #339625] Sat, 18 March 2017 13:57 Go to previous messageGo to next message
Anne &amp; Lynn Wheel is currently offline  Anne &amp; Lynn Wheel
Messages: 3156
Registered: January 2012
Karma: 0
Senior Member
jmfbahciv <See.above@aol.com> writes:
> So the answer might be yes via a side effect of reorganization and
> lack of higher management having the habit of biasing business
> decisions towards the comm group.

re:
http://www.garlic.com/~lynn/2017c.html#58 The ICL 2900

or just random change. there were claims when he first came that he
was going to sweep out all the previous top executives ... but it turned
out most of them were kept on.
http://www.garlic.com/~lynn/submisc.html#gerstner

mid-80s, top executives were predicting IBM world-wide business would
double (mostly based on mainframe) and there was massive internal
building program to double mainframe related manufacturing ... there
were also a lot of new "fast-track" MBAs rotating around middle
positions ... apparently also in preparation of doubling the business
.... this was in spite of that business was already starting to head in
the other direction ... assisted by the communication group stangle hold on
datacenters.
http://www.garlic.com/~lynn/subnetwork.html#terminal

former AMEX president and new CEO was long time wallstreet ... which was
still heavily dependent on ibm mainframes, including AMEX spinoff FDC
(despite the general downturn in mainframe business and migration to
"killer micros"). breaking the company into the 13 "baby blues" would
have severely impacted that critical dependency. There was lots of
selling off stuff, restructuring employee pensions & other benefits,
and trying to get into new/different revenue streams.

recent mainframe revenue numbers has been hardware is 4% (or less) of
revenue ... but total mainframe business unit is 25% of revenue and 40%
of profit ... aka milking software cash cow ... in large part from high
value (financial) customers that have critical dependency.

I've posted before about financial/wallstreet late 90s had effort to get
off major remaining mainframe useage ... overnight batch settlement;
justification including increasing business environment (more work) as
well as globalization (more work and shrinking overnight window). The
spent billions of dollars on "straight through processing" (transaction
completed instead of queuing for batch overnight completion). They were
doing ROI parallelized using standard killer micro parallelization
library ... and ignored input that the parallelization library had
something like 100 times the overhead of mainframe cobol batch. Major
deployments then went down in flames when the throughput was
significantly worse than antificapted (totally overwhelmed the increase
in resources with large numbers of killer micros) ... and then
the industry had major retrenching from moving off mainframe.

Last decade I was involved in taking new parallelization approach to
financial industry groups ... which initial was viewed positively. It
used process that took high-level business rules and decomposed into
fine-grain SQL operations. It then relied on enormous RDBMS industry
investment in high throughput cluster operation. Then everything hit a
brick wall ... and were finally told there were still a large number of
executives that bore the scars of the failed late 90 efforts ... and it
would take a new generation before it was attempted again.

Old post about Annals of release no software before its time:
http://www.garlic.com/~lynn/2009p.html#43 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2009p.html#46 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2011m.html#46 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2011m.html#47 From The Annals of Release No Software Before Its Time
http://www.garlic.com/~lynn/2011m.html#59 From The Annals of Release No Software Before Its Time

i.e. IBM RDBMS power cluster troughput scaleup in 2009 ... two decades
after we were working on RDBMS cluster throughput scaleup.
http://www.garlic.com/~lynn/95.html#13
posts
http://www.garlic.com/~lynn/subtopic.html#hacmp
old email
http://www.garlic.com/~lynn/lhwemail.html#medusa

recent post on doing DLM supporting VAX/Cluster semantics to ease port
to HA/CMP ... but eliminating some VAX/cluster operational and
throughput issues
http://www.garlic.com/~lynn/2017b.html#82 The ICL 2900
and upthread reference to "straight-through" processing
http://www.garlic.com/~lynn/2017.html#82 The ICL 2900

--
virtualization experience starting Jan1968, online at home since Mar1970
Re: The ICL 2900 [message #339661 is a reply to message #339624] Sat, 18 March 2017 16:07 Go to previous messageGo to next message
Alfred Falk is currently offline  Alfred Falk
Messages: 195
Registered: June 2012
Karma: 0
Senior Member
jmfbahciv <See.above@aol.com> wrote in
news:PM00054B005700F202@aca202b4.ipt.aol.com:

> Alfred Falk wrote:
>> jmfbahciv <See.above@aol.com> wrote in
>> news:PM00054AD89C50621B@aca42926.ipt.aol.com:
>>
....
>>> IBM seems to have never gotten rid of their determination to not
>>> cooperate with other manufacturers hardware. JMF's first DEC project
>>> was to get DEC computers and IBM computers to communicate. IBM
>>> believe that homogeneous manufactured hardware was the only
>>> possibility; it took DEC hard/software engineers to break that
>>> self-imposed rule. This was in 1970, 1971. DEC was willing to talk
>>> to
>>
>> DEC built a link between a PDP-9 and a 360/65 (initially) a
>> 360/50)with a 1000' cable between in 1967-8. The nuclear physics
>> experiment this was developed for never quite worked out. The PDP-9
>> was to collect data from instrumentation on a cyclotron and the 360
>> was to process it in real time, returning reduced data for display by
>> the 9. By the time the bugs (software and hardware) were worked out
>> they decided they didn't really need the real- time link. For a few
>> years it was used a kind of RJE by people working on the 9, but not
>> much else. IBM was never co-ooperative.
>
> JMF's project, which was successful, used a PDP-12. it was the site
> which later ran a 5-CPU TOPS-10 SMP system.
>
>>
>>> any hardware, including others'. 1.5 decades later it became Digital
>>> and just as snooty as IBM.
>>
>> Yup.
>
> I wept.
>
> /BAH

Actually the snootiness at DEC began as early as the 70's. In 1974 one of
my Comp Sci profs remarked that "a few years ago when you bought a DEC
machine, they practically shoved a soldering iron into hands, but now
they're getting a lot like IBM".
Re: The ICL 2900 [message #339728 is a reply to message #339661] Sun, 19 March 2017 10:32 Go to previous messageGo to next message
jmfbahciv is currently offline  jmfbahciv
Messages: 6173
Registered: March 2012
Karma: 0
Senior Member
Alfred Falk wrote:
> jmfbahciv <See.above@aol.com> wrote in
> news:PM00054B005700F202@aca202b4.ipt.aol.com:
>
>> Alfred Falk wrote:
>>> jmfbahciv <See.above@aol.com> wrote in
>>> news:PM00054AD89C50621B@aca42926.ipt.aol.com:
>>>
> ...
>>>> IBM seems to have never gotten rid of their determination to not
>>>> cooperate with other manufacturers hardware. JMF's first DEC project
>>>> was to get DEC computers and IBM computers to communicate. IBM
>>>> believe that homogeneous manufactured hardware was the only
>>>> possibility; it took DEC hard/software engineers to break that
>>>> self-imposed rule. This was in 1970, 1971. DEC was willing to talk
>>>> to
>>>
>>> DEC built a link between a PDP-9 and a 360/65 (initially) a
>>> 360/50)with a 1000' cable between in 1967-8. The nuclear physics
>>> experiment this was developed for never quite worked out. The PDP-9
>>> was to collect data from instrumentation on a cyclotron and the 360
>>> was to process it in real time, returning reduced data for display by
>>> the 9. By the time the bugs (software and hardware) were worked out
>>> they decided they didn't really need the real- time link. For a few
>>> years it was used a kind of RJE by people working on the 9, but not
>>> much else. IBM was never co-ooperative.
>>
>> JMF's project, which was successful, used a PDP-12. it was the site
>> which later ran a 5-CPU TOPS-10 SMP system.
>>
>>>
>>>> any hardware, including others'. 1.5 decades later it became Digital
>>>> and just as snooty as IBM.
>>>
>>> Yup.
>>
>> I wept.
>>
>> /BAH
>
> Actually the snootiness at DEC began as early as the 70's. In 1974 one of
> my Comp Sci profs remarked that "a few years ago when you bought a DEC
> machine, they practically shoved a soldering iron into hands, but now
> they're getting a lot like IBM".

The beginings were then. When the -10 product line moved to Marlboro
there was noone to say no nor correct certain strong personalities.
I always associate the snootiness with the decisions to withdraw
the practice of shipping sources of the monitors.

/BAH
Re: The ICL 2900 [message #339950 is a reply to message #336358] Tue, 21 March 2017 18:24 Go to previous messageGo to next message
Alan Bowler is currently offline  Alan Bowler
Messages: 185
Registered: July 2012
Karma: 0
Senior Member
On 2017-01-27 4:14 PM, David Wade wrote:
> On 27/01/2017 19:30, Jon Elson wrote:
>> David Wade wrote:
>>
>>
>>> Whilst its not marketed that way System/360 worked that way. The CPU and
>>> Channels were directly attached to the store. The channels execute
>>> channel programs, and access store directly...
>> Well, that would actually be true on larger 360s, only. Anything including
>> up to the 360/50 used the CPU to perform channel functions. I think you
>> could add additional external channels to the 360/50, but not many
>> installations needed to. On the 360/30, the CPU was so slow, and the memory
>> was only one byte wide, so the CPU was locked out for the duration of at
>> least selector channel operation. (Not so sure if that was true for the
>> multiplexer channel.)
>>
>
> Ah I started on a 360/67 which definitely had separate channel boxes.
>
> The Honeywell 6000/L66/DPS8 series machines also predated the 2900
> and had the same sort of configuration, with CPU's and I/O controllers
> attached to the Memory. Like the ICL2900 CPU's could be taken off line
> and the dual CPU system we had could be reconfigured as two single CPU systems.

Possibly 4 single CPU systems if there were 4 System controllers (SCUs).
>
> I have no idea how wide the memory access was but I do know that
> when doing tape I/O the CPUs were locked out.

Memory access was 72 bits (double word) (Some later dps9000s were 144 bits).

A large system could have up to 4 SCUs, each of which could have 2 memory boxes.
Generally, the switches were set so that memory accesses were interleaved
between the 2 boxes, and the CPUs switches set so that CPU and IOM accesses
were interlaced among the SCUs. So effectively the could be 8 way
interleaving among the memory boxes.

Tape I/O would only have locked out CPUs on smaller systems with fewer memory
boxes and then only if they were the faster tape drives. (We only had the 75ips
1600 bpi ones). I suppose that lockout might occur on a large system
if all interleaved access was turned off.
>
> Download
>
> http://bitsavers.trailing-edge.com/pdf/honeywell/series6000/ DA48_series6000_summary_1971.pdf
>
> and take a look at the picture on page 4. Central memory modules with ports
> to which CPU's or IO Multiplexors could be attached.

The picture is a little simplified and does not make clear it obvious that
there could be 4 SCUs

> Dave
Re: The ICL 2900 [message #340001 is a reply to message #339950] Wed, 22 March 2017 12:25 Go to previous message
Anonymous
Karma:
Originally posted by: David Wade

On 21/03/2017 22:24, Alan Bowler wrote:
> On 2017-01-27 4:14 PM, David Wade wrote:
>> On 27/01/2017 19:30, Jon Elson wrote:
>>> David Wade wrote:
>>>
>>>
>>>> Whilst its not marketed that way System/360 worked that way. The CPU
>>>> and
>>>> Channels were directly attached to the store. The channels execute
>>>> channel programs, and access store directly...
>>> Well, that would actually be true on larger 360s, only. Anything
>>> including
>>> up to the 360/50 used the CPU to perform channel functions. I think you
>>> could add additional external channels to the 360/50, but not many
>>> installations needed to. On the 360/30, the CPU was so slow, and the
>>> memory
>>> was only one byte wide, so the CPU was locked out for the duration of at
>>> least selector channel operation. (Not so sure if that was true for the
>>> multiplexer channel.)
>>>
>>
>> Ah I started on a 360/67 which definitely had separate channel boxes.
>>
>> The Honeywell 6000/L66/DPS8 series machines also predated the 2900
>> and had the same sort of configuration, with CPU's and I/O controllers
>> attached to the Memory. Like the ICL2900 CPU's could be taken off line
>> and the dual CPU system we had could be reconfigured as two single CPU
> systems.
>
> Possibly 4 single CPU systems if there were 4 System controllers (SCUs).
>>
>> I have no idea how wide the memory access was but I do know that
>> when doing tape I/O the CPUs were locked out.
>
> Memory access was 72 bits (double word) (Some later dps9000s were 144
> bits).
>
> A large system could have up to 4 SCUs, each of which could have 2
> memory boxes.

When I was involved many folks had smaller configs. So in the Manchester
region , as far as I remember Refuge Assurance, Allied Bakeries and
Simon Engineering has L66/05 or 10. Manchester City Council and the
Natural Environmental Research Council had faster single CPU systems,
although NERC later upgraded theirs to a dual.

The only site I know of with more than a dual was Littlewoods Pools who
I think had 2 x 4-Way which they generally ran non interleaved..

> Generally, the switches were set so that memory accesses were interleaved
> between the 2 boxes, and the CPUs switches set so that CPU and IOM accesses
> were interlaced among the SCUs. So effectively the could be 8 way
> interleaving among the memory boxes.
>

In my experience most sites had it turned off as it prevents dynamic
re-config.


> Tape I/O would only have locked out CPUs on smaller systems with fewer
> memory
> boxes and then only if they were the faster tape drives. (We only had
> the 75ips
> 1600 bpi ones). I suppose that lockout might occur on a large system
> if all interleaved access was turned off.

We had fast 6250BPI drives...

>>
>> Download
>>
>> http://bitsavers.trailing-edge.com/pdf/honeywell/series6000/ DA48_series6000_summary_1971.pdf
>>
>>
>> and take a look at the picture on page 4. Central memory modules with
>> ports
>> to which CPU's or IO Multiplexors could be attached.
>
> The picture is a little simplified and does not make clear it obvious that
> there could be 4 SCUs
>

I seem to remember that 4 x SCU's could be "interesting" because of the
cable lengths, and cache consistancy. I did go on a tuning course run by
a guy call Vince Martin who had worked in Honeywells performance labs in
Phoenix and was running a consultancy out of Scotsville, Arizona.

I know he said the Dual "DPS300" we had at NERC Bidston was
"Interesting" as it had some tweaks to the config to make it faster...

>> Dave
>
>

Dave
Pages (24): [ «    9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: ARMv8 in RPi 3?
Next Topic: NJ teen joins "The Voice"
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 08:02:28 EDT 2024

Total time taken to generate the page: 0.07604 seconds