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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#213541

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

> On 2020-09-01, Quadibloc <jsavard@ecn.ab.ca> wrote:
>
>> On Monday, August 31, 2020 at 10:41:16 PM UTC-6, Charlie Gibbs wrote:
>>
>>> In _The Mythical Man Month_, Fred Brooks discusses the decision to
>>> save 100 bytes by omitting leap year code from the supervisor.
>>
>> Do you mean that they omitted all leap year code, so as to have a problem
>> in 1968, or just the fancier adjustments so as to have a problem in 2100?
>
> The former.  They figured that they could afford to have the operator
> correct the clock once every four years.

I read stories on IBM Main about correcting the clock twice a year
for daylight savings.  This was fairly recently.

-- 
Dan Espen

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

#213649

Dan Espen wrote:

> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
> 
>> On 2020-09-01, Quadibloc <jsavard@ecn.ab.ca> wrote:
>>
>>> On Monday, August 31, 2020 at 10:41:16 PM UTC-6, Charlie Gibbs wrote:
>>>
>>>> In _The Mythical Man Month_, Fred Brooks discusses the decision to
>>>> save 100 bytes by omitting leap year code from the supervisor.
>>>
>>> Do you mean that they omitted all leap year code, so as to have a
>>> problem in 1968, or just the fancier adjustments so as to have a problem
>>> in 2100?
>>
>> The former.  They figured that they could afford to have the operator
>> correct the clock once every four years.
> 
> I read stories on IBM Main about correcting the clock twice a year
> for daylight savings.  This was fairly recently.
> 
Most 360 (as opposed to 370) installations re-IPL'ed several times a day, 
requiring the clock to be set each time.  So, not that much of a big deal.

Jon

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

#213651

Jon Elson <elson@pico-systems.com> writes:

> Dan Espen wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>> 
>>> On 2020-09-01, Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>
>>>> On Monday, August 31, 2020 at 10:41:16 PM UTC-6, Charlie Gibbs wrote:
>>>>
>>>>> In _The Mythical Man Month_, Fred Brooks discusses the decision to
>>>>> save 100 bytes by omitting leap year code from the supervisor.
>>>>
>>>> Do you mean that they omitted all leap year code, so as to have a
>>>> problem in 1968, or just the fancier adjustments so as to have a problem
>>>> in 2100?
>>>
>>> The former.  They figured that they could afford to have the operator
>>> correct the clock once every four years.
>> 
>> I read stories on IBM Main about correcting the clock twice a year
>> for daylight savings.  This was fairly recently.
>> 
> Most 360 (as opposed to 370) installations re-IPL'ed several times a day, 
> requiring the clock to be set each time.  So, not that much of a big deal.

Last place I worked avoided IPL like the plague.
They were special scheduled for the weekend.
This was development support, not production.
Well, a small bit of production on one LPAR.

We had issues with date/time needing to be in ascending order in logs.
During fall back they'd just turn the machine off for an hour.

-- 
Dan Espen

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

#213655

On 2020-09-03, Dan Espen <dan1espen@gmail.com> wrote:
>
> We had issues with date/time needing to be in ascending order in logs.
> During fall back they'd just turn the machine off for an hour.

Some years ago, I supported an application with essentially the same
problem, and the same solution. Whoever was on call had to stay up late
and shut the app down, then bring it up an hour later.

I seem to recall it ended up being me every time, for the duration I
worked there. All this could have been avoided if they had just used UTC
timestamps.

Niklas
-- 
A few minutes ago I attempted to give a flying fsck, but the best I
could do was to watch it skitter across the floor. -- Anthony de Boer

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

#213656

On Thu, 03 Sep 2020 10:44:15 -0500, Jon Elson <elson@pico-systems.com>
wrote:

>Dan Espen wrote:
>
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
>> 
>>> On 2020-09-01, Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>
>>>> On Monday, August 31, 2020 at 10:41:16 PM UTC-6, Charlie Gibbs wrote:
>>>>
>>>>> In _The Mythical Man Month_, Fred Brooks discusses the decision to
>>>>> save 100 bytes by omitting leap year code from the supervisor.
>>>>
>>>> Do you mean that they omitted all leap year code, so as to have a
>>>> problem in 1968, or just the fancier adjustments so as to have a problem
>>>> in 2100?
>>>
>>> The former.  They figured that they could afford to have the operator
>>> correct the clock once every four years.
>> 
>> I read stories on IBM Main about correcting the clock twice a year
>> for daylight savings.  This was fairly recently.
>> 
>Most 360 (as opposed to 370) installations re-IPL'ed several times a day, 
>requiring the clock to be set each time.  So, not that much of a big deal.

Our guys re-IPL every Saturday night for some reason.

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

#213670

 > Our guys re-IPL every Saturday night for some reason.

In mainframe culture, that's often considered a good idea: it makes sure
that changes that broke something don't get to be old un-remembered
changes before the problems are discovered.  Also helps keep ops current
on procedures, etc.

In internet culture where everything has to be up 25 hours a day, 367
days per year, 110% reliable, etc, nobody understands.

De

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

#213672

drb@ihatespam.msu.edu (Dennis Boone) writes:

>  > Our guys re-IPL every Saturday night for some reason.
>
> In mainframe culture, that's often considered a good idea: it makes sure
> that changes that broke something don't get to be old un-remembered
> changes before the problems are discovered.  Also helps keep ops current
> on procedures, etc.
>
> In internet culture where everything has to be up 25 hours a day, 367
> days per year, 110% reliable, etc, nobody understands.

In internet culture they develop a way to replace a kernel without a reboot.
ksplice.

Not to take away from mainframes but some of this open source stuff is
very cool.


-- 
Dan Espen

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

#213691 — Re: staying up, S/360 model 20

In article <rirdil$u6b$1@dont-email.me>,
Dan Espen  <dan1espen@gmail.com> wrote:
>> In internet culture where everything has to be up 25 hours a day, 367
>> days per year, 110% reliable, etc, nobody understands.
>
>In internet culture they develop a way to replace a kernel without a reboot.
>ksplice.

That's more about software than hardware. TPF mainframe systems have
stayed up over a decade without a reboot, through multiple hardware
and software upgrades.

-- 
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] | [next] | [standalone]

#213664

On Tuesday, September 1, 2020 at 3:10:33 PM UTC-4, Charlie Gibbs wrote:

> The former.  They figured that they could afford to have the operator
> correct the clock once every four years.

Our S/360 operator had to enter the date and time every day.
Wasn't a big deal.  Usually got it right.

Somewhere along the line they got direct connections to
time sources.

Many years ago WU supplied a time signal and clocks.

As an aside, my public schooling had IBM clocks.  They 
normally worked ok.  But in the change back and forth
with Daylight Savings Time, the clocks went haywire.
It always took a few days to get them back normal.

https://archive.org/details/Nations-Business-1952-05/page/n103/mode/1up

IBM dumped its clock division in the late 1950s.

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

#213674

<hancock4@bbs.cpcn.com> wrote:
> On Tuesday, September 1, 2020 at 3:10:33 PM UTC-4, Charlie Gibbs wrote:
> 
>> The former.  They figured that they could afford to have the operator
>> correct the clock once every four years.
> 
> Our S/360 operator had to enter the date and time every day.
> Wasn't a big deal.  Usually got it right.
> 
> Somewhere along the line they got direct connections to
> time sources.

I seem to recall that there was some third-party device that (somehow) set
the system clock for the operator at IPL. No idea how it worked of if they
actually sold any.

For a long time we IPLd every week after third shift Sunday night. A lot of
changes needed an IPL to take effect. This is still a problem with some
Linux software. It’s probably a good idea to reboot before you forget what
you did to the system.

> 
> Many years ago WU supplied a time signal and clocks.
> 
> As an aside, my public schooling had IBM clocks.  They 
> normally worked ok.  But in the change back and forth
> with Daylight Savings Time, the clocks went haywire.
> It always took a few days to get them back normal.
> 
> https://archive.org/details/Nations-Business-1952-05/page/n103/mode/1up
> 
> IBM dumped its clock division in the late 1950s.
> 



-- 
Pete

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

#213678

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

> On Tuesday, September 1, 2020 at 3:10:33 PM UTC-4, Charlie Gibbs wrote:
>
>> The former.  They figured that they could afford to have the operator
>> correct the clock once every four years.
>
> Our S/360 operator had to enter the date and time every day.
> Wasn't a big deal.  Usually got it right.

Slightly off topic (this is a.f.c after all), I remember a site
where the receptionist didn't like 24-hour time.  Every day at
1 p.m., when the time display changed to 13:00, she'd change it
to 1:00.  When she came in the next morning, the display would
be reading 21:00, so she'd change it back to 9:00.  As a result,
the only time that the switch would see a midnight crossing was
on weekends, when the switch was unmanned.  Therefore, the date
in the switch (and in the call records it generated) would only
advance by two days a week.

> Somewhere along the line they got direct connections to
> time sources.
>
> Many years ago WU supplied a time signal and clocks.

I remember reading about a radio that would tune in WWV or
one of its brethren, and decode the time signal to provide
a digital output.

> As an aside, my public schooling had IBM clocks.  They 
> normally worked ok.  But in the change back and forth
> with Daylight Savings Time, the clocks went haywire.
> It always took a few days to get them back normal.

I remember that from my school days.  I think "spring ahead"
was easier because the clocks would step ahead by one minute
every second, so in a minute the adjustment was complete.
Going the other way was trickier - maybe they lost count.

-- 
/~\  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]

#213707

On 9/3/2020 2:49 PM, Charlie Gibbs wrote:

> I remember reading about a radio that would tune in WWV or
> one of its brethren, and decode the time signal to provide
> a digital output.

When I had a BBS, I had a program that would dial WWV or maybe NIST 
once a week (the time signal was available by phone as well as radio), 
estimate the latency (half of round-trip time), and get the time. It 
tracked the computer clock drift, and the rest of the week would make 
little adjustments to compensate.

Never did understand why computer clocks couldn't be at least as 
accurate as a $5 Chinese watch.

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

#213710

On 2020-09-04, Dave Garland <dave.garland@wizinfo.com> wrote:

> Never did understand why computer clocks couldn't be at least as 
> accurate as a $5 Chinese watch.

Nobody cared.  And now, with ntp, nobody has to.

-- 
/~\  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]

#213684

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

>On Tuesday, September 1, 2020 at 3:10:33 PM UTC-4, Charlie Gibbs wrote:
>
>> The former.  They figured that they could afford to have the operator
>> correct the clock once every four years.
>
>Our S/360 operator had to enter the date and time every day.
>Wasn't a big deal.  Usually got it right.
>
>Somewhere along the line they got direct connections to
>time sources.
>
>Many years ago WU supplied a time signal and clocks.
>
>As an aside, my public schooling had IBM clocks.  They 
>normally worked ok.  But in the change back and forth
>with Daylight Savings Time, the clocks went haywire.
>It always took a few days to get them back normal.
>
>https://archive.org/details/Nations-Business-1952-05/page/n103/mode/1up
>
>IBM dumped its clock division in the late 1950s.

Funny thing--where I work now they have manually adjusted clocks--I've
seen the clock guy walk up with his ladder, open the clock, and make
an adjustment, then go down the hall to the next clock . . .

It's not that the place isn't progressive about such things--they had
a robot delivering mail in the '70s (the robot finally died of old age
and lack of spares--it is missed).  

On the other hand, another place I was working, in the '70s, I
remember it was 4:25 on a Friday afternoon and I was beat.  I was
walking back to my desk to drop off the paperwork I was carrying, and
watching the clocks as I went down the hall, enjoying seeing the time
creep up on 4:30.  So it's 4:29:30, and the damned clock BACKS UP half
an hour.

None of those were IBM though.

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

#213693

In article <9db92107-76c2-4e3d-b43e-39ee15a89ac9o@googlegroups.com>,
 <hancock4@bbs.cpcn.com> wrote:
>On Tuesday, September 1, 2020 at 3:10:33 PM UTC-4, Charlie Gibbs wrote:
>
>> The former.  They figured that they could afford to have the operator
>> correct the clock once every four years.
>
>Our S/360 operator had to enter the date and time every day.
>Wasn't a big deal.  Usually got it right.

Around 1970, Princeton University had a 360/91 running OS, which
crashed rebooted all the times, often several times a day. A clever
engineering student built a gizmo he called a TOAD for Time Of Any
Day, which looked to the /91 like a terminal that typed in the clock
setting command as it was starting up. It was a box with a picture of
a toad with lightbulbs for its eyes that lit up on the guy's birthday.

-- 
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] | [next] | [standalone]

#213700

On Friday, September 4, 2020 at 4:09:43 AM UTC+10, h......@bbs.cpcn.com wrote:
> On Tuesday, September 1, 2020 at 3:10:33 PM UTC-4, Charlie Gibbs wrote: 
> 
> > The former. They figured that they could afford to have the operator 
> > correct the clock once every four years.
> Our S/360 operator had to enter the date and time every day. 
> Wasn't a big deal. Usually got it right. 
> 
> Somewhere along the line they got direct connections to 
> time sources. 
> 
> Many years ago WU supplied a time signal and clocks. 
> 
> As an aside, my public schooling had IBM clocks. They 
> normally worked ok. But in the change back and forth 
> with Daylight Savings Time, the clocks went haywire. 
> It always took a few days to get them back normal. 
> 
> IBM dumped its clock division in the late 1950s.

It did?  Our building, new in 1969, had IBM clocks.
If they had been switched off, they would have told the time
correctly twice a day -- which would have been more
times a day that the clocks were correct when running.

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

#213739

On Thursday, September 3, 2020 at 8:44:44 PM UTC-6, Robin Vowels wrote:

> It did?  Our building, new in 1969, had IBM clocks.
> If they had been switched off, they would have told the time
> correctly twice a day -- which would have been more
> times a day that the clocks were correct when running.

They might have been correct more often, but they would still have provided less 
useful information about what time it was.

John Savard

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

#213530

On Tuesday, September 1, 2020 at 12:41:16 AM UTC-4, Charlie Gibbs wrote:

> In _The Mythical Man Month_, Fred Brooks discusses the decision to
> save 100 bytes by omitting leap year code from the supervisor.

People forget how much effort was made to save a byte
here, a byte there since core and disk space were so
limited.  Likewise with CPU cycles.  In the early
years of S/360, I believe most programming was done
in assembler for that reason.  Assembler had tricks
with binary that would save space and time.

 
> > 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.
> 
> It wasn't just memory that was scarce.  CPU cycles were almost as
> precious, and the CKD architecture and its search commands allowed
> processing to be offloaded onto the channel.  It made sense at the
> time, even though it doesn't now.

Oh yes.

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

#213648

Charlie Gibbs wrote:


> 
> It wasn't just memory that was scarce.  CPU cycles were almost as
> precious, and the CKD architecture and its search commands allowed
> processing to be offloaded onto the channel.  It made sense at the
> time, even though it doesn't now.
> 
Well, it really stopped making sense as soon as you had a disk-resident 
multiprogamming OS.  On the 360/30, the 360 was stopped when a channel 
program (I assume that means selector channel) was running.  So, the whole 
idea of saving the CPU from disk search processing was a fallacy on that 
model.

And, on the 360/50 and above, having the whole selector channel/control 
unit/string of disk drives be totally locked out when doing a record key 
search of a few cylinders was obviously not a great idea, the entire system 
would grind to a halt very quickly.

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.

Jon

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

#213667

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.

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

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

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

csiph-web