| S/360 model 20 [message #398841] |
Sun, 30 August 2020 00:27  |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #398876 is a reply to message #398841] |
Sun, 30 August 2020 14:34  |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #398881 is a reply to message #398876] |
Sun, 30 August 2020 15:51 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: modern computers and S/360 model 20 [message #398887 is a reply to message #398881] |
Sun, 30 August 2020 18:07 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: modern computers and S/360 model 20 [message #398890 is a reply to message #398887] |
Sun, 30 August 2020 18:32 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: modern computers and S/360 model 20 [message #398891 is a reply to message #398890] |
Sun, 30 August 2020 18:38 |
|
|
Originally posted by: J. Clarke
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-sec tor-hard-drives-master-ti/>
|
|
|
|
| Re: modern computers and S/360 model 20 [message #398896 is a reply to message #398891] |
Sun, 30 August 2020 20:37 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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-sec tor-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
|
|
|
|
| Re: modern computers and S/360 model 20 [message #398908 is a reply to message #398887] |
Mon, 31 August 2020 04:54 |
|
|
Originally posted by: Bob Eager
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
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #398924 is a reply to message #398908] |
Mon, 31 August 2020 12:36 |
John Levine
Messages: 1405
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #398926 is a reply to message #398924] |
Mon, 31 August 2020 12:57 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
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".
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #398928 is a reply to message #398924] |
Mon, 31 August 2020 13:21 |
|
|
Originally posted by: Bob Eager
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
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #398930 is a reply to message #398928] |
Mon, 31 August 2020 14:10 |
scott
Messages: 4237
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #398940 is a reply to message #398928] |
Mon, 31 August 2020 19:10 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #398953 is a reply to message #398876] |
Tue, 01 September 2020 00:40 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: S/360 model 20 [message #398957 is a reply to message #398953] |
Tue, 01 September 2020 01:10 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #398980 is a reply to message #398940] |
Tue, 01 September 2020 10:14 |
|
|
Originally posted by: Bob Eager
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
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #398987 is a reply to message #398980] |
Tue, 01 September 2020 12:41 |
Bill Findlay
Messages: 286
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #398988 is a reply to message #398876] |
Tue, 01 September 2020 14:00 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: S/360 model 20 [message #398989 is a reply to message #398953] |
Tue, 01 September 2020 14:03 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: S/360 model 20 [message #398998 is a reply to message #398957] |
Tue, 01 September 2020 15:09 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: S/360 model 20 [message #399002 is a reply to message #398998] |
Tue, 01 September 2020 15:41 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #399016 is a reply to message #398988] |
Tue, 01 September 2020 20:05 |
Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #399018 is a reply to message #399016] |
Tue, 01 September 2020 20:25 |
|
|
Originally posted by: J. Clarke
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.
|
|
|
|
| Re: S/360 model 20 [message #399020 is a reply to message #399016] |
Tue, 01 September 2020 20:50 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 2020-09-02, Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Tuesday, September 1, 2020 at 12:00:35 PM UTC-6,
> hancock4@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.
Yes, I remember those days. I wrote a little utility that would take
a record size and calculate optimum blocking factors for a CKD disk.
> 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.
Considering how cheap and plentiful disk space is these days,
it doesn't take much trouble to be too much.
--
/~\ 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.
|
|
|
|
| Re: modern computers and S/360 model 20 [message #399052 is a reply to message #398908] |
Wed, 02 September 2020 03:04 |
usenet
Messages: 556
Registered: May 2013
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: paging, modern computers and S/360 model 20 [message #399057 is a reply to message #398987] |
Wed, 02 September 2020 04:34 |
|
|
Originally posted by: Bob Eager
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
|
|
|
|
| Re: S/360 model 20 [message #399162 is a reply to message #398953] |
Thu, 03 September 2020 11:42 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #399163 is a reply to message #399002] |
Thu, 03 September 2020 11:44 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #399164 is a reply to message #398988] |
Thu, 03 September 2020 11:51 |
Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
hancock4@bbs.cpcn.com wrote:
>
> 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.
With careful design, you could make efficient use of the disk, as you made
the records just the right size, with no wasted space at the end. But, with
poor thought, you could also waste a huge amount of space by choosing a size
that left almost a whole record unusable at the end of each track. And,
when your installation moved to a new disk drive model, this could require
program redesign to accomodate the new track capacity.
But, I think there was another factor. By allocating entire tracks and
cylinders for data sets, you left unused capacity at the end of each one.
Also, it was easy to get a fragmentation condition where enough contiguous
cylinders were not available to create a data set. I think this actually
wasted quite a bit of disk space that could have been made use of in a fixed
block size, random allocation file system.
Jon
|
|
|
|
| Re: S/360 model 20 [message #399165 is a reply to message #399163] |
Thu, 03 September 2020 11:51 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #399169 is a reply to message #399165] |
Thu, 03 September 2020 12:41 |
Niklas Karlsson
Messages: 265
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #399170 is a reply to message #399163] |
Thu, 03 September 2020 12:46 |
|
|
Originally posted by: J. Clarke
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.
|
|
|
|
| Re: S/360 model 20 [message #399183 is a reply to message #398998] |
Thu, 03 September 2020 14:09 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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/n1 03/mode/1up
IBM dumped its clock division in the late 1950s.
|
|
|
|
| Re: S/360 model 20 [message #399186 is a reply to message #399162] |
Thu, 03 September 2020 14:12 |
hancock4
Messages: 6746
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: S/360 model 20 [message #399189 is a reply to message #399170] |
Thu, 03 September 2020 14:32 |
|
|
Originally posted by: drb
> 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
|
|
|
|
| Re: S/360 model 20 [message #399191 is a reply to message #399189] |
Thu, 03 September 2020 14:44 |
Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: S/360 model 20 [message #399192 is a reply to message #399183] |
Thu, 03 September 2020 14:48 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<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/n1 03/mode/1up
>
> IBM dumped its clock division in the late 1950s.
>
--
Pete
|
|
|
|
| Re: S/360 model 20 [message #399193 is a reply to message #399186] |
Thu, 03 September 2020 14:48 |
Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
<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
|
|
|
|
| Re: S/360 model 20 [message #399199 is a reply to message #399186] |
Thu, 03 September 2020 15:49 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: S/360 model 20 [message #399200 is a reply to message #399183] |
Thu, 03 September 2020 15:49 |
Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
Members
Search
Help
Register
Login
Home
