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

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

S/360 model 20

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

Contents

  S/360 model 20 Dan Espen <dan1espen@gmail.com> - 2020-08-30 00:27 -0400
    Re: S/360 model 20 John Levine <johnl@taugh.com> - 2020-08-30 18:34 +0000
      Re: S/360 model 20 Dan Espen <dan1espen@gmail.com> - 2020-08-30 15:51 -0400
        Re: modern computers and S/360 model 20 John Levine <johnl@taugh.com> - 2020-08-30 22:07 +0000
          Re: modern computers and S/360 model 20 Dan Espen <dan1espen@gmail.com> - 2020-08-30 18:32 -0400
            Re: modern computers and S/360 model 20 J. Clarke <jclarke.873638@gmail.com> - 2020-08-30 18:38 -0400
              Re: modern computers and S/360 model 20 Dan Espen <dan1espen@gmail.com> - 2020-08-30 20:37 -0400
          Re: modern computers and S/360 model 20 Bob Eager <news0073@eager.cx> - 2020-08-31 08:54 +0000
            Re: paging, modern computers and S/360 model 20 John Levine <johnl@taugh.com> - 2020-08-31 16:36 +0000
              Re: paging, modern computers and S/360 model 20 scott@slp53.sl.home (Scott Lurndal) - 2020-08-31 16:57 +0000
              Re: paging, modern computers and S/360 model 20 Bob Eager <news0073@eager.cx> - 2020-08-31 17:21 +0000
                Re: paging, modern computers and S/360 model 20 scott@slp53.sl.home (Scott Lurndal) - 2020-08-31 18:10 +0000
                Re: paging, modern computers and S/360 model 20 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-31 16:10 -0700
                  Re: paging, modern computers and S/360 model 20 Bob Eager <news0073@eager.cx> - 2020-09-01 14:14 +0000
                    Re: paging, modern computers and S/360 model 20 Bill Findlay <findlaybill@blueyonder.co.uk> - 2020-09-01 17:41 +0100
                      Re: paging, modern computers and S/360 model 20 Bob Eager <news0073@eager.cx> - 2020-09-02 08:34 +0000
            Re: modern computers and S/360 model 20 usenet@only.tnx (Questor) - 2020-09-02 07:04 +0000
      Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-01 04:40 +0000
        Re: S/360 model 20 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-31 22:10 -0700
          Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-01 19:09 +0000
            Re: S/360 model 20 Dan Espen <dan1espen@gmail.com> - 2020-09-01 15:41 -0400
              Re: S/360 model 20 Jon Elson <elson@pico-systems.com> - 2020-09-03 10:44 -0500
                Re: S/360 model 20 Dan Espen <dan1espen@gmail.com> - 2020-09-03 11:51 -0400
                  Re: S/360 model 20 Niklas Karlsson <anksil@yahoo.se> - 2020-09-03 16:41 +0000
                Re: S/360 model 20 J. Clarke <jclarke.873638@gmail.com> - 2020-09-03 12:46 -0400
                  Re: S/360 model 20 drb@ihatespam.msu.edu (Dennis Boone) - 2020-09-03 13:32 -0500
                    Re: S/360 model 20 Dan Espen <dan1espen@gmail.com> - 2020-09-03 14:44 -0400
                      Re: staying up, S/360 model 20 John Levine <johnl@taugh.com> - 2020-09-03 22:28 +0000
            Re: S/360 model 20 hancock4@bbs.cpcn.com - 2020-09-03 11:09 -0700
              Re: S/360 model 20 Peter Flass <peter_flass@yahoo.com> - 2020-09-03 11:48 -0700
              Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-03 19:49 +0000
                Re: S/360 model 20 Dave Garland <dave.garland@wizinfo.com> - 2020-09-04 10:06 -0500
                  Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-04 16:13 +0000
              Re: S/360 model 20 J. Clarke <jclarke.873638@gmail.com> - 2020-09-03 17:30 -0400
              Re: S/360 model 20 John Levine <johnl@taugh.com> - 2020-09-03 22:55 +0000
              Re: S/360 model 20 Robin Vowels <robin.vowels@gmail.com> - 2020-09-03 19:44 -0700
                Re: S/360 model 20 Quadibloc <jsavard@ecn.ab.ca> - 2020-09-04 23:27 -0700
        Re: S/360 model 20 hancock4@bbs.cpcn.com - 2020-09-01 11:03 -0700
        Re: S/360 model 20 Jon Elson <elson@pico-systems.com> - 2020-09-03 10:42 -0500
          Re: S/360 model 20 hancock4@bbs.cpcn.com - 2020-09-03 11:12 -0700
            Re: S/360 model 20 Peter Flass <peter_flass@yahoo.com> - 2020-09-03 11:48 -0700
            Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-03 19:49 +0000
              Re: S/360 model 20 hancock4@bbs.cpcn.com - 2020-09-10 11:37 -0700
                Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-10 23:34 +0000
                  Re: S/360 model 20 Peter Flass <peter_flass@yahoo.com> - 2020-09-10 18:06 -0700
                    Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-11 20:41 +0000
                      Re: S/360 model 20 Peter Flass <peter_flass@yahoo.com> - 2020-09-11 16:21 -0700
                  Re: S/360 model 20 Terry Kennedy <terry-groups@glaver.org> - 2020-09-11 17:26 -0700
                    Re: S/360 model 20 Bob Eager <news0073@eager.cx> - 2020-09-12 09:30 +0000
                Re: S/360 model 20 Quadibloc <jsavard@ecn.ab.ca> - 2020-09-10 20:39 -0700
                  Re: S/360 model 20 Quadibloc <jsavard@ecn.ab.ca> - 2020-09-10 20:46 -0700
            Re: S/360 model 20 J. Clarke <jclarke.873638@gmail.com> - 2020-09-03 17:41 -0400
      Re: S/360 model 20 hancock4@bbs.cpcn.com - 2020-09-01 11:00 -0700
        Re: S/360 model 20 Quadibloc <jsavard@ecn.ab.ca> - 2020-09-01 17:05 -0700
          Re: S/360 model 20 J. Clarke <jclarke.873638@gmail.com> - 2020-09-01 20:25 -0400
            Re: S/360 model 20 Quadibloc <jsavard@ecn.ab.ca> - 2020-09-10 20:44 -0700
              Re: S/360 model 20 J. Clarke <jclarke.873638@gmail.com> - 2020-09-11 00:30 -0400
                Re: S/360 model 20 Peter Flass <peter_flass@yahoo.com> - 2020-09-11 06:48 -0700
                Re: S/360 model 20 drb@ihatespam.msu.edu (Dennis Boone) - 2020-09-11 11:02 -0500
                  Re: S/360 model 20 Peter Flass <peter_flass@yahoo.com> - 2020-09-11 11:18 -0700
                Re: S/360 model 20 "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2020-10-03 10:29 +0000
                  Re: S/360 model 20 Peter Flass <peter_flass@yahoo.com> - 2020-10-03 07:38 -0700
                  Re: S/360 model 20 scott@slp53.sl.home (Scott Lurndal) - 2020-10-03 16:17 +0000
                    Re: S/360 model 20 drb@ihatespam.msu.edu (Dennis Boone) - 2020-10-04 11:24 -0500
          Re: S/360 model 20 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-09-02 00:50 +0000
        Re: S/360 model 20 Jon Elson <elson@pico-systems.com> - 2020-09-03 10:51 -0500

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#213673

<hancock4@bbs.cpcn.com> wrote:
> On Thursday, September 3, 2020 at 11:42:54 AM UTC-4, Jon Elson wrote:
> 
>> I don't think the designers of the 360 had any idea how central to system 
>> operation disks would quickly become.  They were still in the 709x 
>> generation when they planned this all out.
> 
> Yes.  The S/360 history explains how they sold more disk
> drives and especially many more disk packs than anticipated.
> 
> Several key IBM engineers quit the company and went into
> business for themselves or for other computer makers.
> Given the high demand for disk space, there was a market
> for disk clones.
> 
> I don't think IBM makes disks anymore, mainframe users
> have to get them from somewhere else.  Don't know why.
> 

I don’t think IBM makes much of anything any more, They seem to be trying
to turn themselves into a service company. This is like Unisys, who don’t
seem to want to admit they ever made hardware. It takes a search by a
bloodhound to find any manuals on their site.

-- 
Pete

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

#213679

On 2020-09-03, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:

> On Thursday, September 3, 2020 at 11:42:54 AM UTC-4, Jon Elson wrote:
>
>> I don't think the designers of the 360 had any idea how central to system 
>> operation disks would quickly become.  They were still in the 709x 
>> generation when they planned this all out.
>
> Yes.  The S/360 history explains how they sold more disk
> drives and especially many more disk packs than anticipated.
>
> Several key IBM engineers quit the company and went into
> business for themselves or for other computer makers.
> Given the high demand for disk space, there was a market
> for disk clones.

The same was true with Univac in the late '70s.  A lot of sites
went to Control Data, who saw a market opening.  Univac made all
sorts of threats about using CDC packs, which nonetheless worked
just fine.  Since Univac couldn't meet the demand, they had only
themselves to blame (although it was fun to watch the finger-pointing
if there was a head crash).

> I don't think IBM makes disks anymore, mainframe users
> have to get them from somewhere else.  Don't know why.

Not enough money in it, perhaps?

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

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

#214104

On Thursday, September 3, 2020 at 3:50:18 PM UTC-4, Charlie Gibbs wrote:

> > Several key IBM engineers quit the company and went into
> > business for themselves or for other computer makers.
> > Given the high demand for disk space, there was a market
> > for disk clones.
> 
> The same was true with Univac in the late '70s.  A lot of sites
> went to Control Data, who saw a market opening.  Univac made all
> sorts of threats about using CDC packs, which nonetheless worked
> just fine.  Since Univac couldn't meet the demand, they had only
> themselves to blame (although it was fun to watch the finger-pointing
> if there was a head crash).

Was that mostly in Minneapolis from the former E.R.A.
group?  I think they split off to form CDC, and then
split off again to form Cray.

Watson Jr talked about his response to competition
in his memoir.  He admits that he believed it
was IBM's birthright to rule the computer business
and resented the upstarts.  Obviously they didn't
agree.  IBM had to settle a big lawsuit against CDC.
Watson later realized that big computers were a 
specialty item, not really suited for mass marketing
like IBM's product line.
 

While I think Univac was a 'nicer' company than IBM
in terms of corporate culture, I believe their management
made many strategic errors over the years that kept
them well behind IBM.

I'm not sure what happened to Burroughs.  They were 
respected for good engineering.

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

#214125

On 2020-09-10, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:

> On Thursday, September 3, 2020 at 3:50:18 PM UTC-4, Charlie Gibbs wrote:
>
>>> Several key IBM engineers quit the company and went into
>>> business for themselves or for other computer makers.
>>> Given the high demand for disk space, there was a market
>>> for disk clones.
>> 
>> The same was true with Univac in the late '70s.  A lot of sites
>> went to Control Data, who saw a market opening.  Univac made all
>> sorts of threats about using CDC packs, which nonetheless worked
>> just fine.  Since Univac couldn't meet the demand, they had only
>> themselves to blame (although it was fun to watch the finger-pointing
>> if there was a head crash).
>
> Was that mostly in Minneapolis from the former E.R.A.
> group?  I think they split off to form CDC, and then
> split off again to form Cray.

Dunno.  I remember noting that the name matched that of
the supercomputer manufacturer, but never figured out
whether it really was the (remnants of?) the same company.
(Consider HP.  Now wipe your eyes and blow your nose.)

> Watson Jr talked about his response to competition
> in his memoir.  He admits that he believed it
> was IBM's birthright to rule the computer business
> and resented the upstarts.  Obviously they didn't
> agree.  IBM had to settle a big lawsuit against CDC.
> Watson later realized that big computers were a 
> specialty item, not really suited for mass marketing
> like IBM's product line.

Too bad Watson's attitude is what rules most large
corporations today.  :-(

> While I think Univac was a 'nicer' company than IBM
> in terms of corporate culture, I believe their management
> made many strategic errors over the years that kept
> them well behind IBM.

I agree with the culture part.  If something bad happened
Univac could escalate to get it fixed, but I suspect that
this happened less often at IBM.

> I'm not sure what happened to Burroughs.  They were 
> respected for good engineering.

I had a friend who worked in a Burroughs shop.  Their
MCP looked quite nice, if a bit high-level for my tastes.
They seemed to have a harder time keeping the hardware
running than Univac did, though.

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

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

#214131

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-09-10, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
> 
>> On Thursday, September 3, 2020 at 3:50:18 PM UTC-4, Charlie Gibbs wrote:
>> 
>>>> Several key IBM engineers quit the company and went into
>>>> business for themselves or for other computer makers.
>>>> Given the high demand for disk space, there was a market
>>>> for disk clones.
>>> 
>>> The same was true with Univac in the late '70s.  A lot of sites
>>> went to Control Data, who saw a market opening.  Univac made all
>>> sorts of threats about using CDC packs, which nonetheless worked
>>> just fine.  Since Univac couldn't meet the demand, they had only
>>> themselves to blame (although it was fun to watch the finger-pointing
>>> if there was a head crash).
>> 
>> Was that mostly in Minneapolis from the former E.R.A.
>> group?  I think they split off to form CDC, and then
>> split off again to form Cray.
> 
> Dunno.  I remember noting that the name matched that of
> the supercomputer manufacturer, but never figured out
> whether it really was the (remnants of?) the same company.
> (Consider HP.  Now wipe your eyes and blow your nose.)
> 
>> Watson Jr talked about his response to competition
>> in his memoir.  He admits that he believed it
>> was IBM's birthright to rule the computer business
>> and resented the upstarts.  Obviously they didn't
>> agree.  IBM had to settle a big lawsuit against CDC.
>> Watson later realized that big computers were a 
>> specialty item, not really suited for mass marketing
>> like IBM's product line.
> 
> Too bad Watson's attitude is what rules most large
> corporations today.  :-(
> 
>> While I think Univac was a 'nicer' company than IBM
>> in terms of corporate culture, I believe their management
>> made many strategic errors over the years that kept
>> them well behind IBM.
> 
> I agree with the culture part.  If something bad happened
> Univac could escalate to get it fixed, but I suspect that
> this happened less often at IBM.
> 
>> I'm not sure what happened to Burroughs.  They were 
>> respected for good engineering.
> 
> I had a friend who worked in a Burroughs shop.  Their
> MCP looked quite nice, if a bit high-level for my tastes.
> They seemed to have a harder time keeping the hardware
> running than Univac did, though.
> 

When was this. I worked on  5500 in the late ‘60 or early ‘70s and they
seemed to have continuous crashes. They finally traced it to one of the
hard-per-track discs. FEs tried to fix it several times without success,
but Burroughs didn’t want to replace it. I think the FEs gave it a couple
of raps with a hammer. “There, it’s totally broken now, how about a
replacement.” They did, and the system was solid afterwards.

-- 
Pete

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

#214167

On 2020-09-11, Peter Flass <peter_flass@yahoo.com> wrote:

> When was this.

Mid '70s, on a 17xx.

> I worked on  5500 in the late ‘60 or early ‘70s and they
> seemed to have continuous crashes. They finally traced it to one of the
> hard-per-track discs. FEs tried to fix it several times without success,
> but Burroughs didn’t want to replace it. I think the FEs gave it a couple
> of raps with a hammer. “There, it’s totally broken now, how about a
> replacement.” They did, and the system was solid afterwards.

"If it jams, force it.  If it breaks, it needed replacing anyway."

I recall BAH talking about a bad circuit board that kept coming back
until someone tossed it into the pond.  Sometimes that's the only
way out.

-- 
/~\  Charlie Gibbs                  |  Microsoft is a dictatorship.
\ /  <cgibbs@kltpzyxm.invalid>      |  Apple is a cult.
 X   I'm really at ac.dekanfrus     |  Linux is anarchy.
/ \  if you read it the right way.  |  Pick your poison.

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

#214172

Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-09-11, Peter Flass <peter_flass@yahoo.com> wrote:
> 
>> When was this.
> 
> Mid '70s, on a 17xx.
> 
>> I worked on  5500 in the late ‘60 or early ‘70s and they
>> seemed to have continuous crashes. They finally traced it to one of the
>> hard-per-track discs. FEs tried to fix it several times without success,
>> but Burroughs didn’t want to replace it. I think the FEs gave it a couple
>> of raps with a hammer. “There, it’s totally broken now, how about a
>> replacement.” They did, and the system was solid afterwards.
> 
> "If it jams, force it.  If it breaks, it needed replacing anyway."
> 
> I recall BAH talking about a bad circuit board that kept coming back
> until someone tossed it into the pond.  Sometimes that's the only
> way out.
> 

It is if you let the bean counters run the show. If the FEs say it’s bad,
maybe try to fix it once, but the  toss it. Actually, the cost to deal with
a flakey part is probably greater than the cost of the part, not even
counting the cost in customer respect.


-- 
Pete

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

#214176

On Thursday, September 10, 2020 at 7:35:46 PM UTC-4, Charlie Gibbs wrote:
> I agree with the culture part.  If something bad happened
> Univac could escalate to get it fixed, but I suspect that
> this happened less often at IBM.

FWIW, I found a reproducible microcode bug in the DEC PDP-11/44. After months
of escalation, the official answer was "too bad, so sad".

On the other hand, I had an IBM 3138 (370/138 CPU) that had developed an "im-
possible" error condition (irrecoverable channel I/O error but with sense bits
that said "nope, everything is fine here"). Within 5 days of the initial service
call, the ever-growing crowd of IBM CEs brought in a really, really odd person
who fiddled with the front panel switches, swung open one of the logic gates
and yanked a tri-lead (IBM's version of wire-wrap coax) out and said "change 
this and it will be fine" and then demanded to be taken to the airport because
he had to fly to Saudi Arabia next. I basically said "Who was that masked man?"
and they told me he was one of the original designers of the 138.

But eventually IBM lost their way in customer support - we had a 9370 with all
sorts of issues from new delivery, and I refused to sign the customer acceptance
letter. For example, their answer to a user rapidly flipping the "test" switch
prominently featured on the front panel of every 3278 terminal would crash the
9370. Their official answer was to have us put up signs telling users not to do
that or the system would crash. And they wanted us to do this in student labs.
Right... Eventually IBM took the system back under an agreement where neither of
us would talk about the experience for 5 years (long passed by now).

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

#214182

On Fri, 11 Sep 2020 17:26:09 -0700, Terry Kennedy wrote:

> On Thursday, September 10, 2020 at 7:35:46 PM UTC-4, Charlie Gibbs
> wrote:
>> I agree with the culture part.  If something bad happened Univac could
>> escalate to get it fixed, but I suspect that this happened less often
>> at IBM.
> 
> FWIW, I found a reproducible microcode bug in the DEC PDP-11/44. After
> months of escalation, the official answer was "too bad, so sad".

I had much the same with the ICL 2960. It would do a microcode halt under 
certain reproducible conditions - which could occur with a badly behaved 
FORTRAN program (or a few lines of assembler, my test program).

ICL didn't want to know. I don't know if (a) they didn't believe me (b) 
didn't care or (c) were incompetent in recognising the problem. I suspect 
(c), and my report never got near anyone technical.

I fixed the microcode, and then modified the operating system to deal 
with the additional exception I generated.

See:   https://www.bobeager.uk/anecdotes.html#hwhack


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

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

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

#214132

On Thursday, September 10, 2020 at 12:37:17 PM UTC-6, hanc...@bbs.cpcn.com wrote:
 
> I'm not sure what happened to Burroughs.  They were 
> respected for good engineering.

Supposedly, despite the name, Unisys was the result of Burroughs eating Univac 
instead of Univac eating Burroughs, or at least so I've been told somewhere.

John Savard

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

#214134

On Thursday, September 10, 2020 at 9:39:42 PM UTC-6, Quadibloc wrote:
> On Thursday, September 10, 2020 at 12:37:17 PM UTC-6, hanc...@bbs.cpcn.com wrote:

> > I'm not sure what happened to Burroughs.  They were 
> > respected for good engineering.

> Supposedly, despite the name, Unisys was the result of Burroughs eating Univac 
> instead of Univac eating Burroughs, or at least so I've been told somewhere.

Yes: according to Wikipedia, Unisys came into being in 1986, due to a merger in 
which Burroughs paid $4.8 billion and bought Sperry.

So Sperry got bought out - something "happened to" it - but Burroughs lives on, 
just with an additional legacy system portfolio to lean on.

John Savard

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

#213685

On Thu, 3 Sep 2020 11:12:37 -0700 (PDT), hancock4@bbs.cpcn.com wrote:

>On Thursday, September 3, 2020 at 11:42:54 AM UTC-4, Jon Elson wrote:
>
>> I don't think the designers of the 360 had any idea how central to system 
>> operation disks would quickly become.  They were still in the 709x 
>> generation when they planned this all out.
>
>Yes.  The S/360 history explains how they sold more disk
>drives and especially many more disk packs than anticipated.
>
>Several key IBM engineers quit the company and went into
>business for themselves or for other computer makers.
>Given the high demand for disk space, there was a market
>for disk clones.
>
>I don't think IBM makes disks anymore, mainframe users
>have to get them from somewhere else.  Don't know why.

For certain values.  They don't make the rotating devices in sealed
capsules.  They do make storage systems though, using drives purchased
from drive manufacturers.

I suspect that they just couldn't compete in the storage market
anymore, especially after the Deathstar flushed their reputation for
reliability down the toilet.  Disks are commodity items these days.
They start in the market at around 500 bucks and drop out of it around
80.  

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

#213529

On Sunday, August 30, 2020 at 2:34:22 PM UTC-4, John Levine wrote:
> In article <rif9s1$s59$1@dont-email.me>,
> Dan Espen  <dan1espen@gmail.com> wrote:
> >  Main Storage consists of 4,096; 8,192; 12,288; and
> >  16,384 positions of magnetic core storage.
> >
> >I'm guessing the 32K is accurate and was implemented in later models.
> 
> Models 1,2,3,4 were limited to 16K, model 5 which was different
> internally and somewhat faster could go to 32.  I never saw a model 5.
> 
> >It's interesting that the 2311 disk which was also sold for other S/360
> >models has fixed sector sizes on the Model 20.
> >
> >I always thought the variable block sizes on S/360 was a mistake.
> >It put too much complexity into user space.  A pity IBM didn't sectorize
> >all of it's disk on all of it's models from the beginning.
> 
> I think it was all part of the expensive memory mindset when the 360
> was designed. With CKD disks, the ISAM in-memory index only needed one
> entry per track, or even one per cylinder and the channel program took
> care of finding the right individual record. With the 20's disks, the
> track index told it which track a record was on, but it had to read
> each sector to find the right one, taking a 25ms disk revolution each
> time.

Veterans of the 1401 told me they felt the CKD arrangement
was superior to that of the fixed sectors of the 1401.  
More efficient use of scarce space.

Well into the 390 era disk space was expensive and 
allocations had to be carefully considered.  Today,
of course, disk is cheap and we can be sloppy.

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

#213551

On Tuesday, September 1, 2020 at 12:00:35 PM UTC-6, hanc...@bbs.cpcn.com wrote:

> Well into the 390 era disk space was expensive and 
> allocations had to be carefully considered.  Today,
> of course, disk is cheap and we can be sloppy.

I worked with a Honeywell 316 which had a 1311-like disk drive, so I well 
remember that if you had three sectors on a track, they were each 443 bytes 
long. The idea being not to waste any space - so the sector size varied 
depending on how you formatted the disk, and the fewer sectors you had, the less 
overhead there was in multiple headers and gaps.

It seems amazing to me that even today it's too much trouble for the disk 
drivers and operating systems to support sectors with odd numbers of bytes.

John Savard

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

#213553

On Tue, 1 Sep 2020 17:05:58 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
wrote:

>On Tuesday, September 1, 2020 at 12:00:35 PM UTC-6, hanc...@bbs.cpcn.com wrote:
>
>> Well into the 390 era disk space was expensive and 
>> allocations had to be carefully considered.  Today,
>> of course, disk is cheap and we can be sloppy.
>
>I worked with a Honeywell 316 which had a 1311-like disk drive, so I well 
>remember that if you had three sectors on a track, they were each 443 bytes 
>long. The idea being not to waste any space - so the sector size varied 
>depending on how you formatted the disk, and the fewer sectors you had, the less 
>overhead there was in multiple headers and gaps.
>
>It seems amazing to me that even today it's too much trouble for the disk 
>drivers and operating systems to support sectors with odd numbers of bytes.

You can't buy disk drives with odd numbers of bytes so what's the
point?

A disk at this point is a black box that you plug a cable into and
give commands and receive responses.  The operating system neither
knows nor cares what the internal organization of that disk might be.

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

#214133

On Tuesday, September 1, 2020 at 6:25:03 PM UTC-6, J. Clarke wrote:
> On Tue, 1 Sep 2020 17:05:58 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
> wrote:

> >It seems amazing to me that even today it's too much trouble for the disk 
> >drivers and operating systems to support sectors with odd numbers of bytes.

> You can't buy disk drives with odd numbers of bytes so what's the
> point?

I had sort of presumed they were being made that way because that's what the 
computers wanted rather than the other way around.

John Savard

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

#214136

On Thu, 10 Sep 2020 20:44:03 -0700 (PDT), Quadibloc
<jsavard@ecn.ab.ca> wrote:

>On Tuesday, September 1, 2020 at 6:25:03 PM UTC-6, J. Clarke wrote:
>> On Tue, 1 Sep 2020 17:05:58 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
>> wrote:
>
>> >It seems amazing to me that even today it's too much trouble for the disk 
>> >drivers and operating systems to support sectors with odd numbers of bytes.
>
>> You can't buy disk drives with odd numbers of bytes so what's the
>> point?
>
>I had sort of presumed they were being made that way because that's what the 
>computers wanted rather than the other way around.

The computers were fine with 512 byte sectors.  The 4K sectors were
something the drive manufacturers wanted IIUC.  There was a transition
period where the drives had 4K sectors but reported 512 byte.  And
now, well, what happens inside the capsule comes under the heading of
arcane knowledge accessible only to the high priests and acolytes (or
anybody who cares enough to reverse engineer the code in the
controller on the drive).
>
>John Savard

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

#214144

J. Clarke <jclarke.873638@gmail.com> wrote:
> On Thu, 10 Sep 2020 20:44:03 -0700 (PDT), Quadibloc
> <jsavard@ecn.ab.ca> wrote:
> 
>> On Tuesday, September 1, 2020 at 6:25:03 PM UTC-6, J. Clarke wrote:
>>> On Tue, 1 Sep 2020 17:05:58 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
>>> wrote:
>> 
>>>> It seems amazing to me that even today it's too much trouble for the disk 
>>>> drivers and operating systems to support sectors with odd numbers of bytes.
>> 
>>> You can't buy disk drives with odd numbers of bytes so what's the
>>> point?
>> 
>> I had sort of presumed they were being made that way because that's what the 
>> computers wanted rather than the other way around.
> 
> The computers were fine with 512 byte sectors.  The 4K sectors were
> something the drive manufacturers wanted IIUC.  There was a transition
> period where the drives had 4K sectors but reported 512 byte.  And
> now, well, what happens inside the capsule comes under the heading of
> arcane knowledge accessible only to the high priests and acolytes (or
> anybody who cares enough to reverse engineer the code in the
> controller on the drive).
>> 
>> John Savard
> 

However you’re keeping track of free space  might have a problem with small
sectors on large disks, unless you use extent allocation. You would need a
bitmap or sone kind of list/tree to keep track of free space (I am not a
lawyer, so I can’t speak definitively), and I think the overhead would kill
you.

-- 
Pete

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

#214150

 > The computers were fine with 512 byte sectors.  The 4K sectors were
 > something the drive manufacturers wanted IIUC.  There was a transition
 > period where the drives had 4K sectors but reported 512 byte.

Larger sectors and larger memory pages are related.  The accounting for
multiple transfers to disk is more expensive than larger single
transfers.  Page tables are smaller if pages are larger.  It's more
efficient at the host level to use larger pages, and for the disk sector
size to match the host page size.  370 family has done larger pages for
years.  There was research at Berkeley on the VAX in the early 80s I
think that indicated a 2k page size was more efficient even on hardware
of that era.  Prime used ~2k pages for over half of its life.  (Yes,
there are huge pages on some systems now which don't match disk sector
size.) Presumably the optimal page size depends on the ever(?)
increasing hardware performance.

Of course, some systems weren't ready for 4kn drives when modern SATA /
SAS drives started shipping with 4k sectors, so they had to offer the
option of logical 512 sectors.  The various possible default/available
configurations are reasonably obvious.

I'm sure it also helps the internal accounting on the drive to have a
smaller number of larger sectors.  But I don't think this was something
just the drive mfgs instigated.

De

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

#214152

Dennis Boone <drb@ihatespam.msu.edu> wrote:
>  > The computers were fine with 512 byte sectors.  The 4K sectors were
>  > something the drive manufacturers wanted IIUC.  There was a transition
>  > period where the drives had 4K sectors but reported 512 byte.
> 
> Larger sectors and larger memory pages are related.  The accounting for
> multiple transfers to disk is more expensive than larger single
> transfers.  Page tables are smaller if pages are larger.  It's more
> efficient at the host level to use larger pages, and for the disk sector
> size to match the host page size.  370 family has done larger pages for
> years.  There was research at Berkeley on the VAX in the early 80s I
> think that indicated a 2k page size was more efficient even on hardware
> of that era.  Prime used ~2k pages for over half of its life.  (Yes,
> there are huge pages on some systems now which don't match disk sector
> size.) Presumably the optimal page size depends on the ever(?)
> increasing hardware performance.
> 
> Of course, some systems weren't ready for 4kn drives when modern SATA /
> SAS drives started shipping with 4k sectors, so they had to offer the
> option of logical 512 sectors.  The various possible default/available
> configurations are reasonably obvious.
> 
> I'm sure it also helps the internal accounting on the drive to have a
> smaller number of larger sectors.  But I don't think this was something
> just the drive mfgs instigated.
> 

Thinking about it, though, there’s no reason the system can’t allocate disk
in chunks larger than a sector size. It might make sense to allocate in 4k
chunks. Then it only has to keep track of allocated/free chunks, rather
than sectors. It’s a simple multiply to convert the chunk number to the
starting sector number.

-- 
Pete

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web