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

#213444 — S/360 model 20

So, I hesitate to say anything, there's no reason for animosity.

Someone said a Model 20 could be 32K another said 16K.
I checked Wikipedia, they say 32K.
I accessed Functional Characteristics using the Wikipedia link.
That gets the -01 version of the manual.

On page 1, it lists the storage sizes:

  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.

(See how confrontation is uncalled for.)

As to whether disk was common, I'm going to take a wild guess and
say that disk was initially uncommon but later might have been more
common.  The system I worked on was card only.

Disk would make more sense on the 32K model since the owner could afford
to be using the OS with 32K.

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.

Oh boy, I expressed another opinion, now someone is going to call me an
idiot.  Oh well.

-- 
Dan Espen

[toc] | [next] | [standalone]

#213467

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.

Less than a decade later VSAM KSDS used B-trees which use fixed block
sizes and put the index in the blocks themselves, on the assumption
that the computer will cache recently used blocks.

-- 
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]

#213469

John Levine <johnl@taugh.com> writes:

> 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.

...

I started to write about how you could do something similar with sectors,
but you're absolutely right.  For the channel to search for the data in
the sector it would have to understand a lot about the file to know what
to match.

> 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.
>
> Less than a decade later VSAM KSDS used B-trees which use fixed block
> sizes and put the index in the blocks themselves, on the assumption
> that the computer will cache recently used blocks.

I found the variable block sizes a real problem.
If you pick a really large block size for the benefit of one
program, all the other programs reading that file must use the
same block size.  Which could be a problem if a program is storage
constrained.  Back in the 14xx days one program might read one sector
at a time, another might attempt to read the whole cylinder.

It looks like IBM has tried to adapt using 4K blocks with VSAM and
PDS/E.

-- 
Dan Espen

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

#213471 — Re: modern computers and S/360 model 20

In article <rih00v$455$1@dont-email.me>,
Dan Espen  <dan1espen@gmail.com> wrote:
>I found the variable block sizes a real problem.
>If you pick a really large block size for the benefit of one
>program, all the other programs reading that file must use the
>same block size.  Which could be a problem if a program is storage
>constrained.  Back in the 14xx days one program might read one sector
>at a time, another might attempt to read the whole cylinder.
>
>It looks like IBM has tried to adapt using 4K blocks with VSAM and PDS/E.

Not at all by coincidence, 4K is also the virtual memory page size.
Modern operating systems treat file I/O and paging together, moving
data back and forth between disk and main memory as needed.



-- 
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]

#213474 — Re: modern computers and S/360 model 20

John Levine <johnl@taugh.com> writes:

> In article <rih00v$455$1@dont-email.me>,
> Dan Espen  <dan1espen@gmail.com> wrote:
>>I found the variable block sizes a real problem.
>>If you pick a really large block size for the benefit of one
>>program, all the other programs reading that file must use the
>>same block size.  Which could be a problem if a program is storage
>>constrained.  Back in the 14xx days one program might read one sector
>>at a time, another might attempt to read the whole cylinder.
>>
>>It looks like IBM has tried to adapt using 4K blocks with VSAM and PDS/E.
>
> Not at all by coincidence, 4K is also the virtual memory page size.
> Modern operating systems treat file I/O and paging together, moving
> data back and forth between disk and main memory as needed.

Yes, I was going to try to get into that.
As I understand it, IBM has an array of buffering techniques in play,
DB2 has something, IMS has something, they're all over the place.

Unix deals with it at a single level, the entire filesystem gets cached
as best it can.

I don't know if IBM is trying to consciously move toward that or not.

-- 
Dan Espen

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

#213475 — Re: modern computers and S/360 model 20

On Sun, 30 Aug 2020 18:32:02 -0400, Dan Espen <dan1espen@gmail.com>
wrote:

>John Levine <johnl@taugh.com> writes:
>
>> In article <rih00v$455$1@dont-email.me>,
>> Dan Espen  <dan1espen@gmail.com> wrote:
>>>I found the variable block sizes a real problem.
>>>If you pick a really large block size for the benefit of one
>>>program, all the other programs reading that file must use the
>>>same block size.  Which could be a problem if a program is storage
>>>constrained.  Back in the 14xx days one program might read one sector
>>>at a time, another might attempt to read the whole cylinder.
>>>
>>>It looks like IBM has tried to adapt using 4K blocks with VSAM and PDS/E.
>>
>> Not at all by coincidence, 4K is also the virtual memory page size.
>> Modern operating systems treat file I/O and paging together, moving
>> data back and forth between disk and main memory as needed.
>
>Yes, I was going to try to get into that.
>As I understand it, IBM has an array of buffering techniques in play,
>DB2 has something, IMS has something, they're all over the place.
>
>Unix deals with it at a single level, the entire filesystem gets cached
>as best it can.
>
>I don't know if IBM is trying to consciously move toward that or not.

There's also the matter that 4K is the physical sector size on
virtually all disks currently in production.

Seagate provides a discussion of that transition here:
<https://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/>

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

#213479 — Re: modern computers and S/360 model 20

J. Clarke <jclarke.873638@gmail.com> writes:

> On Sun, 30 Aug 2020 18:32:02 -0400, Dan Espen <dan1espen@gmail.com>
> wrote:
>
>>John Levine <johnl@taugh.com> writes:
>>
>>> In article <rih00v$455$1@dont-email.me>,
>>> Dan Espen  <dan1espen@gmail.com> wrote:
>>>>I found the variable block sizes a real problem.
>>>>If you pick a really large block size for the benefit of one
>>>>program, all the other programs reading that file must use the
>>>>same block size.  Which could be a problem if a program is storage
>>>>constrained.  Back in the 14xx days one program might read one sector
>>>>at a time, another might attempt to read the whole cylinder.
>>>>
>>>>It looks like IBM has tried to adapt using 4K blocks with VSAM and PDS/E.
>>>
>>> Not at all by coincidence, 4K is also the virtual memory page size.
>>> Modern operating systems treat file I/O and paging together, moving
>>> data back and forth between disk and main memory as needed.
>>
>>Yes, I was going to try to get into that.
>>As I understand it, IBM has an array of buffering techniques in play,
>>DB2 has something, IMS has something, they're all over the place.
>>
>>Unix deals with it at a single level, the entire filesystem gets cached
>>as best it can.
>>
>>I don't know if IBM is trying to consciously move toward that or not.
>
> There's also the matter that 4K is the physical sector size on
> virtually all disks currently in production.
>
> Seagate provides a discussion of that transition here:
> <https://www.seagate.com/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/>

I'm reading this and thinking, hey this is pretty interesting.

Then I realize my last hard drive went out of service 2 or 3 years ago.

Hard drive, meet punched card.

-- 
Dan Espen

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

#213485 — Re: modern computers and S/360 model 20

On Sun, 30 Aug 2020 22:07:58 +0000, John Levine wrote:

> Not at all by coincidence, 4K is also the virtual memory page size.
> Modern operating systems treat file I/O and paging together, moving data
> back and forth between disk and main memory as needed.

I was working on a system that did that in the 1970s. It used a 4kB page 
size.

Not widely used, though. (and not MULTICS)

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

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

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

#213491 — Re: paging, modern computers and S/360 model 20

In article <hr3s69F76i4U1@mid.individual.net>,
Bob Eager  <news0073@eager.cx> wrote:
>On Sun, 30 Aug 2020 22:07:58 +0000, John Levine wrote:
>
>> Not at all by coincidence, 4K is also the virtual memory page size.
>> Modern operating systems treat file I/O and paging together, moving data
>> back and forth between disk and main memory as needed.
>
>I was working on a system that did that in the 1970s. It used a 4kB page size.
>
>Not widely used, though. (and not MULTICS)

Yeah, I used TSS/360 too.  A lovable dog.

-- 
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]

#213492 — Re: paging, modern computers and S/360 model 20

John Levine <johnl@taugh.com> writes:
>In article <hr3s69F76i4U1@mid.individual.net>,
>Bob Eager  <news0073@eager.cx> wrote:
>>On Sun, 30 Aug 2020 22:07:58 +0000, John Levine wrote:
>>
>>> Not at all by coincidence, 4K is also the virtual memory page size.
>>> Modern operating systems treat file I/O and paging together, moving data
>>> back and forth between disk and main memory as needed.
>>
>>I was working on a system that did that in the 1970s. It used a 4kB page size.
>>
>>Not widely used, though. (and not MULTICS)
>
>Yeah, I used TSS/360 too.  A lovable dog.

At Burroughs we called CANDE (time sharing subsystem) "Batch with a Patch".

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

#213494 — Re: paging, modern computers and S/360 model 20

On Mon, 31 Aug 2020 16:36:13 +0000, John Levine wrote:

> In article <hr3s69F76i4U1@mid.individual.net>,
> Bob Eager  <news0073@eager.cx> wrote:
>>On Sun, 30 Aug 2020 22:07:58 +0000, John Levine wrote:
>>
>>> Not at all by coincidence, 4K is also the virtual memory page size.
>>> Modern operating systems treat file I/O and paging together, moving
>>> data back and forth between disk and main memory as needed.
>>
>>I was working on a system that did that in the 1970s. It used a 4kB page
>>size.
>>
>>Not widely used, though. (and not MULTICS)
> 
> Yeah, I used TSS/360 too.  A lovable dog.

No, not TSS/360. Not even IBM.

(TSS/8 is fun though)
-- 
Using UNIX since v6 (1975)...

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

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

#213496 — Re: paging, modern computers and S/360 model 20

Bob Eager <news0073@eager.cx> writes:
>On Mon, 31 Aug 2020 16:36:13 +0000, John Levine wrote:
>
>> In article <hr3s69F76i4U1@mid.individual.net>,
>> Bob Eager  <news0073@eager.cx> wrote:
>>>On Sun, 30 Aug 2020 22:07:58 +0000, John Levine wrote:
>>>
>>>> Not at all by coincidence, 4K is also the virtual memory page size.
>>>> Modern operating systems treat file I/O and paging together, moving
>>>> data back and forth between disk and main memory as needed.
>>>
>>>I was working on a system that did that in the 1970s. It used a 4kB page
>>>size.
>>>
>>>Not widely used, though. (and not MULTICS)
>> 
>> Yeah, I used TSS/360 too.  A lovable dog.
>
>No, not TSS/360. Not even IBM.

TSS 8.24 (4kw pages and all) was much more pleasant to use when compared with TSS/360.   Heck,
Wylbur was much more pleasant to use than TSS/360.

PAL-D on TSS 8.24 was my introduction to assembler programming.

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

#213499 — Re: paging, modern computers and S/360 model 20

On Monday, August 31, 2020 at 11:21:52 AM UTC-6, Bob Eager wrote:

> (TSS/8 is fun though)

And then there's OS/8, with 6.2 file names.

And a PIP command, just like CP/M.

Of course, there's no money in suing Digital Research. But if Hewlett-Packard 
could wind up owning a chunk of Microsoft...

John Savard

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

#213526 — Re: paging, modern computers and S/360 model 20

On Mon, 31 Aug 2020 16:10:57 -0700, Quadibloc wrote:

> On Monday, August 31, 2020 at 11:21:52 AM UTC-6, Bob Eager wrote:
> 
>> (TSS/8 is fun though)
> 
> And then there's OS/8, with 6.2 file names.
> 
> And a PIP command, just like CP/M.
> 
> Of course, there's no money in suing Digital Research. But if
> Hewlett-Packard could wind up owning a chunk of Microsoft...

Indeed. I mentioned that stuff in a recent talk on the PDP-8.

But the original system I was referring to (with 4kB pages) was none of 
these.

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

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

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

#213528 — Re: paging, modern computers and S/360 model 20

On 1 Sep 2020, Bob Eager wrote
(in article <hr73aiFo7g1U1@mid.individual.net>):

> On Mon, 31 Aug 2020 16:10:57 -0700, Quadibloc wrote:
>
> > On Monday, August 31, 2020 at 11:21:52 AM UTC-6, Bob Eager wrote:
> >
> > > (TSS/8 is fun though)
> >
> > And then there's OS/8, with 6.2 file names.
> >
> > And a PIP command, just like CP/M.
> >
> > Of course, there's no money in suing Digital Research. But if
> > Hewlett-Packard could wind up owning a chunk of Microsoft...
>
> Indeed. I mentioned that stuff in a recent talk on the PDP-8.
>
> But the original system I was referring to (with 4kB pages) was none of
> these.

Ee, MAn, Such a tease!

-- 
Bill Findlay

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

#213582 — Re: paging, modern computers and S/360 model 20

On Tue, 01 Sep 2020 17:41:22 +0100, Bill Findlay wrote:

> On 1 Sep 2020, Bob Eager wrote (in article
> <hr73aiFo7g1U1@mid.individual.net>):
> 
>> On Mon, 31 Aug 2020 16:10:57 -0700, Quadibloc wrote:
>>
>> > On Monday, August 31, 2020 at 11:21:52 AM UTC-6, Bob Eager wrote:
>> >
>> > > (TSS/8 is fun though)
>> >
>> > And then there's OS/8, with 6.2 file names.
>> >
>> > And a PIP command, just like CP/M.
>> >
>> > Of course, there's no money in suing Digital Research. But if
>> > Hewlett-Packard could wind up owning a chunk of Microsoft...
>>
>> Indeed. I mentioned that stuff in a recent talk on the PDP-8.
>>
>> But the original system I was referring to (with 4kB pages) was none of
>> these.
> 
> Ee, MAn, Such a tease!

OK...it was NOT like TOPS-20, but it was like MULTICS.

I worked on it for about eight years, including a large amount of work 
porting it to XA architecture.

But there were not many instances.

All disk I/O was unified with paging, and files were mapped into memory 
(the only way to access them). Other I/O used a related model where the 
buffers worked like that. 4kB pages because that was determined to be 
optimal (the hardware pages were grouped to get 4kB ones).

Start here (more in the same place):
 http://www.ancientgeek.org.uk/EMAS/EMAS_Papers/
The_EMAS_2900_Operating_System.pdf

or:

 https://tinyurl.com/yyms23z6



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

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

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

#213577 — Re: modern computers and S/360 model 20

On 31 Aug 2020 08:54:33 GMT, Bob Eager <news0073@eager.cx> wrote:
>On Sun, 30 Aug 2020 22:07:58 +0000, John Levine wrote:
>> Not at all by coincidence, 4K is also the virtual memory page size.
>> Modern operating systems treat file I/O and paging together, moving data
>> back and forth between disk and main memory as needed.
>
>I was working on a system that did that in the 1970s. It used a 4kB page 
>size.
>
>Not widely used, though. (and not MULTICS)

TOPS-20 would be another.  Core, swap space, disk -- managed with pointers.
There are cases where it isn't necessary to do the actual I/O -- the pointer in
some table just gets changed.  IIRC, page size is 1000(8), or 512 36-bit words.
The algorithms are documented in the TOPS-20 Monitor Tables and TOPS-20 Monitor
Internals documents, archived in the usual repositories.  AIUI, the Linux kernel
adopted a similar model.

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

#213508

On 2020-08-30, John Levine <johnl@taugh.com> wrote:

> In article <rif9s1$s59$1@dont-email.me>,
> Dan Espen  <dan1espen@gmail.com> wrote:
>
>> 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.

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

> 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.

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

#213512

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?

John Savard

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

#213537

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.

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web