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

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

IBM system/360 ad

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

Contents

  IBM system/360 ad hancock4@bbs.cpcn.com - 2019-11-25 13:20 -0800
    Re: IBM system/360 ad Quadibloc <jsavard@ecn.ab.ca> - 2019-11-25 15:07 -0800
      Re: IBM system/360 ad Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2019-11-26 01:22 +0000
        Re: IBM system/360 ad hancock4@bbs.cpcn.com - 2019-11-27 12:54 -0800
          Re: IBM system/360 ad Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2019-11-28 18:08 +0000
        Re: IBM system/360 ad Ahem A Rivet's Shot <steveo@eircom.net> - 2019-11-28 09:44 +0000
          Re: IBM system/360 ad Peter Flass <peter_flass@yahoo.com> - 2019-11-28 11:04 -0700
    Re: IBM system/360 ad Anne & Lynn Wheeler <lynn@garlic.com> - 2019-11-25 14:41 -1000
      Re: IBM system/360 ad scott@slp53.sl.home (Scott Lurndal) - 2019-11-26 01:31 +0000
      Re: IBM system/360 ad hancock4@bbs.cpcn.com - 2019-11-27 12:49 -0800
        Re: IBM system/360 ad Andy Burns <usenet@andyburns.uk> - 2019-11-27 21:23 +0000
          Re: IBM system/360 ad hancock4@bbs.cpcn.com - 2019-11-27 13:39 -0800
            Re: IBM system/360 ad J. Clarke <jclarke.873638@gmail.com> - 2019-11-27 18:18 -0500
              Re: IBM system/360 ad Alexander Schreiber <als@usenet.thangorodrim.de> - 2019-12-02 00:23 +0100
                Re: IBM system/360 ad scott@slp53.sl.home (Scott Lurndal) - 2019-12-02 15:37 +0000
        Re: IBM system/360 ad David LaRue <huey.dll@tampabay.rr.com> - 2019-11-28 03:16 +0000
    Re: IBM system/360 ad David Wade <g4ugm@dave.invalid> - 2019-11-26 21:35 +0000
      Re: IBM system/360 ad Bob Eager <news0073@eager.cx> - 2019-11-26 22:21 +0000
      Re: IBM system/360 ad Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2019-11-26 22:50 +0000
        Re: IBM system/360 ad David Wade <g4ugm@dave.invalid> - 2019-11-27 00:41 +0000
          Re: IBM system/360 ad Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2019-11-27 05:49 +0000
            Re: IBM system/360 ad David Wade <g4ugm@dave.invalid> - 2019-11-27 11:22 +0000
              Re: IBM system/360 ad Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2019-11-27 19:54 +0000
                Re: IBM system/360 ad hancock4@bbs.cpcn.com - 2019-11-27 13:05 -0800
            Re: IBM system/360 ad hancock4@bbs.cpcn.com - 2019-11-27 13:04 -0800
              Re: IBM system/360 ad Anne & Lynn Wheeler <lynn@garlic.com> - 2019-11-27 13:11 -1000
              Re: IBM system/360 ad Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2019-11-28 18:08 +0000
                Re: IBM system/360 ad J. Clarke <jclarke.873638@gmail.com> - 2019-11-28 13:28 -0500
                  Re: IBM system/360 ad Quadibloc <jsavard@ecn.ab.ca> - 2019-12-01 13:16 -0800
                    Re: IBM system/360 ad Niklas Karlsson <anksil@yahoo.se> - 2019-12-03 15:14 +0000
                    Re: IBM system/360 ad hancock4@bbs.cpcn.com - 2019-12-04 13:01 -0800
                Re: IBM system/360 ad Dan Espen <dan1espen@gmail.com> - 2019-11-28 19:41 -0500

Page 1 of 2  [1] 2  Next page →

#208265 — IBM system/360 ad

https://archive.org/details/Nations-Business-1964-12/page/n51

Available with up to 8 meg of memory!

(I thought S/360 could handle up to 16 meg?  But maybe in those
days no one could see needing more than 8 meg.  Indeed, I think
if you wanted that much you had to get the "LCS" which was
core but slow core.)

[toc] | [next] | [standalone]

#208273

On Monday, November 25, 2019 at 2:20:53 PM UTC-7, hanc...@bbs.cpcn.com wrote:
> https://archive.org/details/Nations-Business-1964-12/page/n51

> Available with up to 8 meg of memory!

> (I thought S/360 could handle up to 16 meg?  But maybe in those
> days no one could see needing more than 8 meg.  Indeed, I think
> if you wanted that much you had to get the "LCS" which was
> core but slow core.)

Yes, that's right. And 16 megabytes of slow core could be attached to the 
largest models in the System/360 line... which weren't available yet at the time 
of that advertisement.

John Savard

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

#208285

On 2019-11-25, Quadibloc <jsavard@ecn.ab.ca> wrote:

> On Monday, November 25, 2019 at 2:20:53 PM UTC-7, hanc...@bbs.cpcn.com wrote:
>
>> https://archive.org/details/Nations-Business-1964-12/page/n51
>>
>> Available with up to 8 meg of memory!
>>
>> (I thought S/360 could handle up to 16 meg?  But maybe in those
>> days no one could see needing more than 8 meg.  Indeed, I think
>> if you wanted that much you had to get the "LCS" which was
>> core but slow core.)
>
> Yes, that's right. And 16 megabytes of slow core could be attached to the 
> largest models in the System/360 line... which weren't available yet at
> the time of that advertisement.

Besides, hardly anyone would have been able to afford that much core.
I remember seeing an article in a trade rag around 1971 or so about
how IBM rocked the industry by slashing the price of a megabyte of
memory from $75,000 to a mere $15,000.

(Meanwhile, I'm slipping into my pocket a thumb drive that cost me
50 cents per gigabyte...)

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  "Alexa, define 'bugging'."

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

#208302

On Monday, November 25, 2019 at 8:22:41 PM UTC-5, Charlie Gibbs wrote:
> On 2019-11-25, Quadibloc <jsavard@ecn.ab.ca> wrote:
> 
> > On Monday, November 25, 2019 at 2:20:53 PM UTC-7, hanc...@bbs.cpcn.com wrote:
> >
> >> https://archive.org/details/Nations-Business-1964-12/page/n51
> >>
> >> Available with up to 8 meg of memory!
> >>
> >> (I thought S/360 could handle up to 16 meg?  But maybe in those
> >> days no one could see needing more than 8 meg.  Indeed, I think
> >> if you wanted that much you had to get the "LCS" which was
> >> core but slow core.)
> >
> > Yes, that's right. And 16 megabytes of slow core could be attached to the 
> > largest models in the System/360 line... which weren't available yet at
> > the time of that advertisement.
> 
> Besides, hardly anyone would have been able to afford that much core.
> I remember seeing an article in a trade rag around 1971 or so about
> how IBM rocked the industry by slashing the price of a megabyte of
> memory from $75,000 to a mere $15,000.

In those days we talked in terms of K, not meg.  We were happy
to have 192K on our S/360.  I think the Univac 90/30 I worked
on had 256k, which we thought was very large.

But as the 1970s wore on, technology improved and memory
got cheaper.  Of course, at the same time, software got
bloated.
 
> (Meanwhile, I'm slipping into my pocket a thumb drive that cost me
> 50 cents per gigabyte...)


Yes, I got a Sandisk flash drive with 32GB for $6.
Amazing. (Though this one doesn't have the little red light
that glows when in use.  I wish it did.  Also, I don't know
if that is 'real' memory or compressed memory.)

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

#208316

On 2019-11-27, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:

> On Monday, November 25, 2019 at 8:22:41 PM UTC-5, Charlie Gibbs wrote:
>
>> On 2019-11-25, Quadibloc <jsavard@ecn.ab.ca> wrote:
>> 
>>> On Monday, November 25, 2019 at 2:20:53 PM UTC-7,
>>> hancock4@bbs.cpcn.com wrote:
>>>
>>>> https://archive.org/details/Nations-Business-1964-12/page/n51
>>>>
>>>> Available with up to 8 meg of memory!
>>>>
>>>> (I thought S/360 could handle up to 16 meg?  But maybe in those
>>>> days no one could see needing more than 8 meg.  Indeed, I think
>>>> if you wanted that much you had to get the "LCS" which was
>>>> core but slow core.)
>>>
>>> Yes, that's right. And 16 megabytes of slow core could be attached
>>> to the largest models in the System/360 line... which weren't
>>> available yet at the time of that advertisement.
>> 
>> Besides, hardly anyone would have been able to afford that much core.
>> I remember seeing an article in a trade rag around 1971 or so about
>> how IBM rocked the industry by slashing the price of a megabyte of
>> memory from $75,000 to a mere $15,000.
>
> In those days we talked in terms of K, not meg.  We were happy
> to have 192K on our S/360.  I think the Univac 90/30 I worked
> on had 256k, which we thought was very large.

It was.  I don't know whether I ever used a 256K 90/30 - most
of them around here had 192K.  Some had only 128K, which was
uncomfortably tight.

Univac finally broke down and said you needed at least 64K (rather
than 32K) to run a minimum IMS/90 installation (their equivalent
of CICS).  Mind you, that was three terminals making inquiries
into a single ISAM file, i.e. pretty useless.

(Actually, they said 65K, not 64K, since these statements came
from the marketroids, who live in that magical world where
32 + 32 = 65.  The customers would only find out that the
configuration they purchased on a low-balled bid was inadequate
once they tried to get it running, at which point it was cheaper
to just buy an upgrade than go somewhere else.)

> But as the 1970s wore on, technology improved and memory
> got cheaper.  Of course, at the same time, software got
> bloated.

Yup.  Consider that 10,000 times as much memory is now considered
barely adequate in a garden-variety home computer.

>> (Meanwhile, I'm slipping into my pocket a thumb drive that cost me
>> 50 cents per gigabyte...)
>
> Yes, I got a Sandisk flash drive with 32GB for $6.
> Amazing. (Though this one doesn't have the little red light
> that glows when in use.  I wish it did.  Also, I don't know
> if that is 'real' memory or compressed memory.)

I really want that red light.  I never pull a thumb drive out
of the socket until the light stops flashing, no matter what
the software says.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  "Alexa, define 'bugging'."

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

#208313

On 26 Nov 2019 01:22:02 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> (Meanwhile, I'm slipping into my pocket a thumb drive that cost me
> 50 cents per gigabyte...)

	Long range data bandwidth has done similar things. Early 1980s you
could struggle to get a reliable 1200bps long distance connection and pay
through the nose for it, or get a reliable 56/64k connection and pay by the
limb for it. Mid 1990s here a typical dial up ISP offered cheap 14.4k
connections (plus not so cheap phone charges) out of an expensive 64K pipe
and there were only a handful in the (admittedly small) country.

	Today there's an uncapped, flat-rate, gigabit pipe to my house
running 24/7 that often provides tens of megabytes per second on a
transatlantic connection, what's more all the connection hardware was
installed free of charge.

	I do miss Morten posting on the stunts being pulled to make that
happen.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

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

#208314

Ahem A Rivet's Shot <steveo@eircom.net> wrote:
> On 26 Nov 2019 01:22:02 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> 
>> (Meanwhile, I'm slipping into my pocket a thumb drive that cost me
>> 50 cents per gigabyte...)
> 
> 	Long range data bandwidth has done similar things. Early 1980s you
> could struggle to get a reliable 1200bps long distance connection and pay
> through the nose for it, or get a reliable 56/64k connection and pay by the
> limb for it. Mid 1990s here a typical dial up ISP offered cheap 14.4k
> connections (plus not so cheap phone charges) out of an expensive 64K pipe
> and there were only a handful in the (admittedly small) country.
> 
> 	Today there's an uncapped, flat-rate, gigabit pipe to my house
> running 24/7 that often provides tens of megabytes per second on a
> transatlantic connection, what's more all the connection hardware was
> installed free of charge.
> 
> 	I do miss Morten posting on the stunts being pulled to make that
> happen.
> 

Yes :-(

-- 
Pete

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

#208282

hancock4@bbs.cpcn.com writes:
> https://archive.org/details/Nations-Business-1964-12/page/n51
>
> Available with up to 8 meg of memory!
>
> (I thought S/360 could handle up to 16 meg?  But maybe in those
> days no one could see needing more than 8 meg.  Indeed, I think
> if you wanted that much you had to get the "LCS" which was
> core but slow core.)

s/360 & s/370 architecture only having 24bit (16mbyte) addressing (real
& virtual) ... except for 360/67 which still had "real" 24bit addressing
but support 32bit virtual. Note that was the architecture ... specific
models might have much smaller number of hardware address lines
... limiting the actual amount of memory that could be attached.

by the time 3033 came around ... 16mbyte was huge constraint because of
the excessively bloated MVS kernel size as well concurrent
multiprogramming needed to try and keep system busy ... lots of page
thrashing. They did a kludge for 64mbyte support. There were two
undefined/unused bits in each page table entry (mapping virtual address
to a hardware address). The used the two unused bits to prepend to the
12bit page number (allowing 64mbytes worth of 4kbyte pages ... rather
than just 16mbytes)

Instructions (virtual and real) could only form a 24bit address ... but
a virtual address (using the page table entry hack) could map to a
64mbyte hardware address ... aka hacked 3033 that had internal 26bit
hardware address lines.

complimenting the 64mbyte page table hack ... in the original 370
architecture was fullword (31bit architecture) channel program IDALs
... which could be used to generate 64mbyte I/O transfer addresses.

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

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

#208286

Anne & Lynn Wheeler <lynn@garlic.com> writes:
>hancock4@bbs.cpcn.com writes:

>by the time 3033 came around ... 16mbyte was huge constraint because of
>the excessively bloated MVS kernel size as well concurrent
>multiprogramming needed to try and keep system busy ... lots of page
>thrashing. They did a kludge for 64mbyte support. There were two
>undefined/unused bits in each page table entry (mapping virtual address
>to a hardware address). The used the two unused bits to prepend to the
>12bit page number (allowing 64mbytes worth of 4kbyte pages ... rather
>than just 16mbytes)
>
>Instructions (virtual and real) could only form a 24bit address ... but
>a virtual address (using the page table entry hack) could map to a
>64mbyte hardware address ... aka hacked 3033 that had internal 26bit
>hardware address lines.

Intel did something similar later in the P6 days to support 36-bit physical
addresses with 32-bit virtual addresses.

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

#208301

On Monday, November 25, 2019 at 7:41:35 PM UTC-5, Anne & Lynn Wheeler wrote:

> s/360 & s/370 architecture only having 24bit (16mbyte) addressing (real
> & virtual) ... except for 360/67 which still had "real" 24bit addressing
> but support 32bit virtual. Note that was the architecture ... specific
> models might have much smaller number of hardware address lines
> ... limiting the actual amount of memory that could be attached.

Anyone know how much real memory does the Z series support today?

Unlike the past, it's hard to get firm information from IBM
on various models, even if they even have specific models.

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

#208307

hancock4@bbs.cpcn.com wrote:

> Anyone know how much real memory does the Z series support today?
> Unlike the past, it's hard to get firm information from IBM
> on various models, even if they even have specific models.

40TB

<https://www.mainline.com/ibm-z15-september-12-2019-announcement>

since that's in RAIM config, I assume less useable memory if you 
actually mirror/stripe/whatever it?

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

#208308

On Wednesday, November 27, 2019 at 4:23:02 PM UTC-5, Andy Burns wrote:
> hancock4@bbs.cpcn.com wrote:
> 
> > Anyone know how much real memory does the Z series support today?
> > Unlike the past, it's hard to get firm information from IBM
> > on various models, even if they even have specific models.
> 
> 40TB
> 
> <https://www.mainline.com/ibm-z15-september-12-2019-announcement>
> 
> since that's in RAIM config, I assume less useable memory if you 
> actually mirror/stripe/whatever it?

OMG.

But I must admit caching is nice.  First time I read a file
it takes a minute or two.  But each successive access
runs very fast.  I assumed the file is stored in memory
in its entirety.

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

#208311

On Wed, 27 Nov 2019 13:39:25 -0800 (PST), hancock4@bbs.cpcn.com wrote:

>On Wednesday, November 27, 2019 at 4:23:02 PM UTC-5, Andy Burns wrote:
>> hancock4@bbs.cpcn.com wrote:
>> 
>> > Anyone know how much real memory does the Z series support today?
>> > Unlike the past, it's hard to get firm information from IBM
>> > on various models, even if they even have specific models.
>> 
>> 40TB
>> 
>> <https://www.mainline.com/ibm-z15-september-12-2019-announcement>
>> 
>> since that's in RAIM config, I assume less useable memory if you 
>> actually mirror/stripe/whatever it?
>
>OMG.
>
>But I must admit caching is nice.  First time I read a file
>it takes a minute or two.  But each successive access
>runs very fast.  I assumed the file is stored in memory
>in its entirety.

I did an experiment many years ago.  I had two machines.  One was a 1
GHz Pentium and the other was a 450 MHz Xeon.  There was a particular
dataset and program that I was working with.  I noticed that the
dataset was larger than the cache on the Pentium but smaller than the
cache on the Xeon.  Same code, same OS, same as much else as possible,
the Xeon ran that particular program on that particular dataset twice
as fast.

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

#208345

J  Clarke <jclarke.873638@gmail.com> wrote:
> On Wed, 27 Nov 2019 13:39:25 -0800 (PST), hancock4@bbs.cpcn.com wrote:
>
>>On Wednesday, November 27, 2019 at 4:23:02 PM UTC-5, Andy Burns wrote:
>>> hancock4@bbs.cpcn.com wrote:
>>> 
>>> > Anyone know how much real memory does the Z series support today?
>>> > Unlike the past, it's hard to get firm information from IBM
>>> > on various models, even if they even have specific models.
>>> 
>>> 40TB
>>> 
>>> <https://www.mainline.com/ibm-z15-september-12-2019-announcement>
>>> 
>>> since that's in RAIM config, I assume less useable memory if you 
>>> actually mirror/stripe/whatever it?
>>
>>OMG.
>>
>>But I must admit caching is nice.  First time I read a file
>>it takes a minute or two.  But each successive access
>>runs very fast.  I assumed the file is stored in memory
>>in its entirety.
>
> I did an experiment many years ago.  I had two machines.  One was a 1
> GHz Pentium and the other was a 450 MHz Xeon.  There was a particular
> dataset and program that I was working with.  I noticed that the
> dataset was larger than the cache on the Pentium but smaller than the
> cache on the Xeon.  Same code, same OS, same as much else as possible,
> the Xeon ran that particular program on that particular dataset twice
> as fast.

Yes, running pretty much entirely in cache is _great_ for performance.
I've been told that during the days of the i486, the Linux scheduler
was carefully optimized to fit entirely into < 8 KB of memory - because
the i486 had 8 KB of cache.

Kind regards,
           Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

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

#208347

Alexander Schreiber <als@usenet.thangorodrim.de> writes:
>J  Clarke <jclarke.873638@gmail.com> wrote:
>> On Wed, 27 Nov 2019 13:39:25 -0800 (PST), hancock4@bbs.cpcn.com wrote:
>>
>>>On Wednesday, November 27, 2019 at 4:23:02 PM UTC-5, Andy Burns wrote:
>>>> hancock4@bbs.cpcn.com wrote:
>>>> 
>>>> > Anyone know how much real memory does the Z series support today?
>>>> > Unlike the past, it's hard to get firm information from IBM
>>>> > on various models, even if they even have specific models.
>>>> 
>>>> 40TB
>>>> 
>>>> <https://www.mainline.com/ibm-z15-september-12-2019-announcement>
>>>> 
>>>> since that's in RAIM config, I assume less useable memory if you 
>>>> actually mirror/stripe/whatever it?
>>>
>>>OMG.
>>>
>>>But I must admit caching is nice.  First time I read a file
>>>it takes a minute or two.  But each successive access
>>>runs very fast.  I assumed the file is stored in memory
>>>in its entirety.
>>
>> I did an experiment many years ago.  I had two machines.  One was a 1
>> GHz Pentium and the other was a 450 MHz Xeon.  There was a particular
>> dataset and program that I was working with.  I noticed that the
>> dataset was larger than the cache on the Pentium but smaller than the
>> cache on the Xeon.  Same code, same OS, same as much else as possible,
>> the Xeon ran that particular program on that particular dataset twice
>> as fast.
>
>Yes, running pretty much entirely in cache is _great_ for performance.
>I've been told that during the days of the i486, the Linux scheduler
>was carefully optimized to fit entirely into < 8 KB of memory - because
>the i486 had 8 KB of cache.

I suspect that is an urban legend.  The scheduler is only needed infrequently,
and most of it doesn't run on context switches.

What your correspondent probably meant was the the frequently used parts
of the scheduler were crafted to consume only a couple of cache lines by
collecting the most commonly used code together; which would leave the
remaining cache lines (some occupied by shared kernel or libc code, others
by user code) in the cache even when scheduling a new thread on the core.

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

#208312

hancock4@bbs.cpcn.com wrote in
news:e64707e5-78ef-42c1-9582-fb7fb0eabbb8@googlegroups.com: 

> On Monday, November 25, 2019 at 7:41:35 PM UTC-5, Anne & Lynn Wheeler
> wrote: 
> 
>> s/360 & s/370 architecture only having 24bit (16mbyte) addressing
>> (real & virtual) ... except for 360/67 which still had "real" 24bit
>> addressing but support 32bit virtual. Note that was the architecture
>> ... specific models might have much smaller number of hardware
>> address lines ... limiting the actual amount of memory that could be
>> attached. 
> 
> Anyone know how much real memory does the Z series support today?
> 
> Unlike the past, it's hard to get firm information from IBM
> on various models, even if they even have specific models.

Such information would be useless.  Even a total system description
could be useless.  Compare what you like, but the actual system might be
emulated by a totally different platform.  You'd have to tear it apart
to get the specifics and you might be surprised by what you find. 

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

#208293

On 25/11/2019 21:20, hancock4@bbs.cpcn.com wrote:
> https://archive.org/details/Nations-Business-1964-12/page/n51
> 
> Available with up to 8 meg of memory!
> 
> (I thought S/360 could handle up to 16 meg?  But maybe in those
> days no one could see needing more than 8 meg.  Indeed, I think
> if you wanted that much you had to get the "LCS" which was
> core but slow core.)
> 
> 
> 
The ARCHITECTURE could support up to 16Mb and indeed the 360/67 could 
support more, but physically, most 360's could only interface to smaller 
amounts of RAM and only implemented a subset of the address lines.
In addition if it spread out too far the propogation delays will slow 
the machine down.

For example a 360/40 could have up to 256k and I think a 360/67 could go 
up to 2048k. There is a picture of a 360/67 with 512k here:-

http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.html

The core is in the four cabinet right at the back. When I used that 
machine it had been upgraded to 1024K so had 8 of the big double cabinets.

The functional characteristics manuals which cover the specs are here:-

http://www.bitsavers.org/pdf/ibm/360/funcChar/

other machines have similar restrictions,so the early VAXs could only 
handle 1 or 2Mb of memory, my VLC has 24Mb.

Dave

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

#208295

On Tue, 26 Nov 2019 21:35:29 +0000, David Wade wrote:

> The ARCHITECTURE could support up to 16Mb and indeed the 360/67 could
> support more, but physically, most 360's could only interface to smaller
> amounts of RAM and only implemented a subset of the address lines.
> In addition if it spread out too far the propogation delays will slow
> the machine down.

> other machines have similar restrictions,so the early VAXs could only
> handle 1 or 2Mb of memory, my VLC has 24Mb.

Also see the 80386SX; only 24 address lines but full 32 bit architecture.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

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

#208296

On 2019-11-26, David Wade <g4ugm@dave.invalid> wrote:

> On 25/11/2019 21:20, hancock4@bbs.cpcn.com wrote:
>
>> https://archive.org/details/Nations-Business-1964-12/page/n51
>> 
>> Available with up to 8 meg of memory!
>> 
>> (I thought S/360 could handle up to 16 meg?  But maybe in those
>> days no one could see needing more than 8 meg.  Indeed, I think
>> if you wanted that much you had to get the "LCS" which was
>> core but slow core.)
> 
> The ARCHITECTURE could support up to 16Mb and indeed the 360/67 could 
> support more, but physically, most 360's could only interface to smaller 
> amounts of RAM and only implemented a subset of the address lines.
> In addition if it spread out too far the propogation delays will slow 
> the machine down.
>
> For example a 360/40 could have up to 256k and I think a 360/67 could go 
> up to 2048k. There is a picture of a 360/67 with 512k here:-
>
> http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.html
>
> The core is in the four cabinet right at the back. When I used that 
> machine it had been upgraded to 1024K so had 8 of the big double cabinets.
>
> The functional characteristics manuals which cover the specs are here:-
>
> http://www.bitsavers.org/pdf/ibm/360/funcChar/

Yours must have been an older machine.  The 360/67 we had at UBC
had 256K in each cabinet.  The above manual describes this as two
128K units per cabinet.

Although propagation delays were a factor, I suspect that marketing
was as well.  Some shops had to go to a larger CPU than they needed
in order to get enough memory.  Third-party suppliers were quick to
jump in.  I once used a 360/30 that had 128K of memory, even though
you could only go to 64K on a stock machine.  A switch and indicator
light for the extra address bit was placed in an unused portion of
the panel.

I once read about how Greyhound Computer Corporation would buy
360/30s that came off lease and add memory to them.  Apparently
you could get up to 512K if you wanted.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  "Alexa, define 'bugging'."

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

#208297

On 26/11/2019 22:50, Charlie Gibbs wrote:
> On 2019-11-26, David Wade <g4ugm@dave.invalid> wrote:
> 
>> On 25/11/2019 21:20, hancock4@bbs.cpcn.com wrote:
>>
>>> https://archive.org/details/Nations-Business-1964-12/page/n51
>>>
>>> Available with up to 8 meg of memory!
>>>
>>> (I thought S/360 could handle up to 16 meg?  But maybe in those
>>> days no one could see needing more than 8 meg.  Indeed, I think
>>> if you wanted that much you had to get the "LCS" which was
>>> core but slow core.)
>>
>> The ARCHITECTURE could support up to 16Mb and indeed the 360/67 could
>> support more, but physically, most 360's could only interface to smaller
>> amounts of RAM and only implemented a subset of the address lines.
>> In addition if it spread out too far the propogation delays will slow
>> the machine down.
>>
>> For example a 360/40 could have up to 256k and I think a 360/67 could go
>> up to 2048k. There is a picture of a 360/67 with 512k here:-
>>
>> http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.html
>>
>> The core is in the four cabinet right at the back. When I used that
>> machine it had been upgraded to 1024K so had 8 of the big double cabinets.
>>
>> The functional characteristics manuals which cover the specs are here:-
>>
>> http://www.bitsavers.org/pdf/ibm/360/funcChar/
> 
> Yours must have been an older machine.  The 360/67 we had at UBC
> had 256K in each cabinet.  The above manual describes this as two
> 128K units per cabinet.
> 

Not sure we are talking about the same cabinet. The store came in 256k 
chunks, but when you actually checked there were 2 x 128k cabinets.
I assume it was interleaved...

> Although propagation delays were a factor, I suspect that marketing
> was as well.  Some shops had to go to a larger CPU than they needed
> in order to get enough memory.  Third-party suppliers were quick to
> jump in.  I once used a 360/30 that had 128K of memory, even though
> you could only go to 64K on a stock machine.  A switch and indicator
> light for the extra address bit was placed in an unused portion of
> the panel.
> 

I seem to remember hearing that some of those upgrades needed a lot of 
re-working of the hardware, on the other hand that was the time of the 
expensive "no change" upgrade. Printers where the speed was set by a 
link, but getting it changed was expensive.

Disk drives that were 100mb until a wire was cut when they became 200Mb...

etc. etc. etc.

> I once read about how Greyhound Computer Corporation would buy
> 360/30s that came off lease and add memory to them.  Apparently
> you could get up to 512K if you wanted.
> 

That was a lot of memory for a 30....

Dave

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web