Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

I have a very small mind and must live with it. -- E. Dijkstra


computers / comp.sys.unisys / Re: Working on a series of mini-articles about OS 2200

SubjectAuthor
* Working on a series of mini-articles about OS 2200Kira Ash
+* Re: Working on a series of mini-articles about OS 2200Stephen Fuld
|+* Re: Working on a series of mini-articles about OS 2200Kira Ash
||`- Re: Working on a series of mini-articles about OS 2200Stephen Fuld
|`* Re: Working on a series of mini-articles about OS 2200Scott Lurndal
| `- Re: Working on a series of mini-articles about OS 2200Stephen Fuld
+* Re: Working on a series of mini-articles about OS 2200Kira Ash
|`* Re: Working on a series of mini-articles about OS 2200Bill Gunshannon
| `* Re: Working on a series of mini-articles about OS 2200David W Schroth
|  +* Re: Working on a series of mini-articles about OS 2200Stephen Fuld
|  |`- Re: Working on a series of mini-articles about OS 2200Lewis Cole
|  +- Re: Working on a series of mini-articles about OS 2200Bill Gunshannon
|  `* Re: Working on a series of mini-articles about OS 2200Kurt Duncan
|   `* Re: Working on a series of mini-articles about OS 2200Kira Ash
|    `* Re: Working on a series of mini-articles about OS 2200David W Schroth
|     `- Re: Working on a series of mini-articles about OS 2200Stephen Fuld
`* Re: Working on a series of mini-articles about OS 2200Lewis Cole
 +* Re: Working on a series of mini-articles about OS 2200Andrew
 |`- Re: Working on a series of mini-articles about OS 2200David W Schroth
 `* Re: Working on a series of mini-articles about OS 2200Kira Ash
  `* Re: Working on a series of mini-articles about OS 2200Lewis Cole
   +- Re: Working on a series of mini-articles about OS 2200jns
   `* Re: Working on a series of mini-articles about OS 2200Stephen Fuld
    +* Re: Working on a series of mini-articles about OS 2200Kira Ash
    |+- Re: Working on a series of mini-articles about OS 2200Lewis Cole
    |`* Re: Working on a series of mini-articles about OS 2200Stephen Fuld
    | `* Re: Working on a series of mini-articles about OS 2200Kira Ash
    |  +* Re: Working on a series of mini-articles about OS 2200Stephen Fuld
    |  |+- Re: Working on a series of mini-articles about OS 2200Kira Ash
    |  |`* Re: Working on a series of mini-articles about OS 2200Scott Lurndal
    |  | `* Re: Working on a series of mini-articles about OS 2200Stephen Fuld
    |  |  `* Re: Working on a series of mini-articles about OS 2200Scott Lurndal
    |  |   +* Re: Working on a series of mini-articles about OS 2200Paul Kimpel
    |  |   |`- Re: Working on a series of mini-articles about OS 2200Scott Lurndal
    |  |   `* Re: Working on a series of mini-articles about OS 2200Stephen Fuld
    |  |    `- Re: Working on a series of mini-articles about OS 2200Scott Lurndal
    |  `* Re: Working on a series of mini-articles about OS 2200Lewis Cole
    |   +- Re: Working on a series of mini-articles about OS 2200Andrew
    |   +- Re: Working on a series of mini-articles about OS 2200Scott Lurndal
    |   +* Re: Working on a series of mini-articles about OS 2200Bill Gunshannon
    |   |`* Re: Working on a series of mini-articles about OS 2200Lewis Cole
    |   | +* Re: Working on a series of mini-articles about OS 2200Paul Kimpel
    |   | |`- Re: Working on a series of mini-articles about OS 2200Lewis Cole
    |   | +* Re: Working on a series of mini-articles about OS 2200Scott Lurndal
    |   | |`* Re: Working on a series of mini-articles about OS 2200Lewis Cole
    |   | | `* Re: Working on a series of mini-articles about OS 2200Scott Lurndal
    |   | |  `- Re: Working on a series of mini-articles about OS 2200Lewis Cole
    |   | `* Re: Working on a series of mini-articles about OS 2200Bill Gunshannon
    |   |  `- Re: Working on a series of mini-articles about OS 2200Lewis Cole
    |   +- Re: Working on a series of mini-articles about OS 2200Paul Kimpel
    |   `- Re: Working on a series of mini-articles about OS 2200Stephen Fuld
    `* Re: Working on a series of mini-articles about OS 2200Lewis Cole
     `- Re: Working on a series of mini-articles about OS 2200Stephen Fuld

Pages:123
Re: Working on a series of mini-articles about OS 2200

<th719c$pmff$1@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=228&group=comp.sys.unisys#228

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Fri, 30 Sep 2022 08:17:00 -0700
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <th719c$pmff$1@dont-email.me>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 30 Sep 2022 15:17:00 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="cf43316ba01d9f33b2852c333d498242";
logging-data="842223"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Mudvqguk98SNWQzBrABQ2RAa+dzRum+Y="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.1
Cancel-Lock: sha1:qoMxvnmUqYeWgF1HbR/etyfFKrI=
In-Reply-To: <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
Content-Language: en-US
 by: Stephen Fuld - Fri, 30 Sep 2022 15:17 UTC

On 9/28/2022 6:48 AM, Kira Ash wrote:
> On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:

>> Rereading parts of your web site, a few minor nits.

Your section on other mainframe systems got me to do some research.

1. You mention that GCOS was emulated on Itanium hardware, but with its
demise, you didn't know what happened. According to

https://en.wikipedia.org/wiki/General_Comprehensive_Operating_System#Legacy

it is now emulated on various Xeon based systems.

2. Your mention of the Siemens BS2000, systems brought up a memory that
they were another of the "almost IBM S/360 compatible" systems, but I
wasn't sure. Again from Wikipedia

https://en.wikipedia.org/wiki/BS2000

it was based on the RCA Spectra/70 series, which is the same series
that, when RCA decided to exit the computer business, they sold to
Univac which became the high end of the Univac Series 90!

Probably OT for this group, but all of this got me to wondering why,
several companies chose to build their own computer lines, and their own
OS, designed their hardware to be "almost" IBM compatible? Or, to put
it another way, What was so compelling about the ISA that several
companies decided to adopt it, even when the software wouldn't be
compatible?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Working on a series of mini-articles about OS 2200

<dfa37c3d-6198-45b9-8c86-fd39df0ffe6fn@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=230&group=comp.sys.unisys#230

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:a05:620a:4450:b0:6ce:8a73:1ba with SMTP id w16-20020a05620a445000b006ce8a7301bamr6602497qkp.625.1664554223128;
Fri, 30 Sep 2022 09:10:23 -0700 (PDT)
X-Received: by 2002:a05:6808:2387:b0:350:741f:1588 with SMTP id
bp7-20020a056808238700b00350741f1588mr4184598oib.25.1664554222797; Fri, 30
Sep 2022 09:10:22 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Fri, 30 Sep 2022 09:10:22 -0700 (PDT)
In-Reply-To: <th719c$pmff$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=68.186.103.105; posting-account=qPbaDgoAAADbIvbos5AEJa5zMjgnmjMM
NNTP-Posting-Host: 68.186.103.105
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <th719c$pmff$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <dfa37c3d-6198-45b9-8c86-fd39df0ffe6fn@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: hpeinteg...@gmail.com (Kira Ash)
Injection-Date: Fri, 30 Sep 2022 16:10:23 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 2977
 by: Kira Ash - Fri, 30 Sep 2022 16:10 UTC

On Friday, September 30, 2022 at 8:17:13 AM UTC-7, Stephen Fuld wrote:
> On 9/28/2022 6:48 AM, Kira Ash wrote:
> > On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:
>
> >> Rereading parts of your web site, a few minor nits.
> Your section on other mainframe systems got me to do some research.
>
> 1. You mention that GCOS was emulated on Itanium hardware, but with its
> demise, you didn't know what happened. According to
>
> https://en.wikipedia.org/wiki/General_Comprehensive_Operating_System#Legacy
>
> it is now emulated on various Xeon based systems.
>

I know that's what Wikipedia says, and I think it's likely right - but Atos has publicly said almost nothing about M9600/M9600V beyond "it exists", while they provide a full set of specs and details for the G7-oriented M7200/M7200V. I've asked some folks I know at Atos for clarification and will probably get a more solid answer soon. The G8 customer base at this point is tiny, so they may just not see fit to actively market it. V9000 - the G8 emulator on IPF - has a couple of aspects that would make it a little complex to do a straight port to x86, but they're certainly obstacles that can be overcome if resources were devoted to the problem. (V7000, for GCOS 7, was comparatively a much simpler environment and always ran on both IPF and Xeon..)

Re: Working on a series of mini-articles about OS 2200

<tzEZK.240992$PRW4.19882@fx11.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=231&group=comp.sys.unisys#231

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx11.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Working on a series of mini-articles about OS 2200
Newsgroups: comp.sys.unisys
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com> <dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com> <86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <th719c$pmff$1@dont-email.me>
Lines: 36
Message-ID: <tzEZK.240992$PRW4.19882@fx11.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Fri, 30 Sep 2022 16:12:09 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Fri, 30 Sep 2022 16:12:09 GMT
X-Received-Bytes: 2569
 by: Scott Lurndal - Fri, 30 Sep 2022 16:12 UTC

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 9/28/2022 6:48 AM, Kira Ash wrote:
>> On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:
>
>>> Rereading parts of your web site, a few minor nits.
>
>Your section on other mainframe systems got me to do some research.
>
>1. You mention that GCOS was emulated on Itanium hardware, but with its
>demise, you didn't know what happened. According to
>
>https://en.wikipedia.org/wiki/General_Comprehensive_Operating_System#Legacy
>
>it is now emulated on various Xeon based systems.
>
>2. Your mention of the Siemens BS2000, systems brought up a memory that
>they were another of the "almost IBM S/360 compatible" systems, but I
>wasn't sure. Again from Wikipedia
>
>https://en.wikipedia.org/wiki/BS2000
>
>it was based on the RCA Spectra/70 series, which is the same series
>that, when RCA decided to exit the computer business, they sold to
>Univac which became the high end of the Univac Series 90!
>
>Probably OT for this group, but all of this got me to wondering why,
>several companies chose to build their own computer lines, and their own
>OS, designed their hardware to be "almost" IBM compatible? Or, to put
>it another way, What was so compelling about the ISA that several
>companies decided to adopt it, even when the software wouldn't be
>compatible?

Burroughs chose EBCDIC for compatability with IBM peripherals.

Why design your own ISA if you can use one with an existence proof;
likely made it easier to hire programmers away from IBM sites.

Re: Working on a series of mini-articles about OS 2200

<thhmup$2mogl$1@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=233&group=comp.sys.unisys#233

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Tue, 4 Oct 2022 09:28:05 -0700
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <thhmup$2mogl$1@dont-email.me>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<th719c$pmff$1@dont-email.me> <tzEZK.240992$PRW4.19882@fx11.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 4 Oct 2022 16:28:09 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="69ba7dc78530efe5a43b63ccb2c2b105";
logging-data="2843157"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/fGf1xD6iRDiwWRHcwD9nXRm1hIkHPeyQ="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.1
Cancel-Lock: sha1:/hc1LXLFu/9TzgbwG7bOygk90Uc=
Content-Language: en-US
In-Reply-To: <tzEZK.240992$PRW4.19882@fx11.iad>
 by: Stephen Fuld - Tue, 4 Oct 2022 16:28 UTC

On 9/30/2022 9:12 AM, Scott Lurndal wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> On 9/28/2022 6:48 AM, Kira Ash wrote:
>>> On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:
>>
>>>> Rereading parts of your web site, a few minor nits.
>>
>> Your section on other mainframe systems got me to do some research.
>>
>> 1. You mention that GCOS was emulated on Itanium hardware, but with its
>> demise, you didn't know what happened. According to
>>
>> https://en.wikipedia.org/wiki/General_Comprehensive_Operating_System#Legacy
>>
>> it is now emulated on various Xeon based systems.
>>
>> 2. Your mention of the Siemens BS2000, systems brought up a memory that
>> they were another of the "almost IBM S/360 compatible" systems, but I
>> wasn't sure. Again from Wikipedia
>>
>> https://en.wikipedia.org/wiki/BS2000
>>
>> it was based on the RCA Spectra/70 series, which is the same series
>> that, when RCA decided to exit the computer business, they sold to
>> Univac which became the high end of the Univac Series 90!
>>
>> Probably OT for this group, but all of this got me to wondering why,
>> several companies chose to build their own computer lines, and their own
>> OS, designed their hardware to be "almost" IBM compatible? Or, to put
>> it another way, What was so compelling about the ISA that several
>> companies decided to adopt it, even when the software wouldn't be
>> compatible?
>
> Burroughs chose EBCDIC for compatability with IBM peripherals.

I presume you meant data compatibility of the media (primarily tape),
not the peripheral, as things like tape drives don't care at all what
data you write (i.e. "bits is bits").

Univac used IBM compatible peripherals in order to reduce their hardware
development costs (e.g. buy tape drives from Storage Tek, and disk
drives from various companies rather than develop their own), but used
their own character encoding (Fieldata or ASCII). For tape interchange
with IBM systems, They did provide optional translation to/from EBCDIC
in their own channel equivalent hardware.

Caveat, I just don't know if "paper" peripherals such as printers, card
readers or the specialized banking peripherals used with many Burroughs
systems know about character set.

BTW, what character code did the Burroughs 5000 series use, as I think
they were designed before IBM announced EBCDIC?

> Why design your own ISA if you can use one with an existence proof;
> likely made it easier to hire programmers away from IBM sites.

Interesting point. So those companies must have expected to use
software (OS and other stuff), or perhaps just marketing power, as
product differentiators. And they must have felt they could build
hardware at a cost that was at least competitive with what one could buy
from IBM. Clearly, while these ideas might have been true for a while
(though I have my doubts), they eventually didn't work out.

And, of course, there were several companies that went a different way,
building IBM compatible hardware, but supplying no software at all,
relying on the users to use IBM software. They also succeeded for a
while, but eventually succumbed.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Working on a series of mini-articles about OS 2200

<xoZ_K.181336$479c.136188@fx48.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=234&group=comp.sys.unisys#234

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx48.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Working on a series of mini-articles about OS 2200
Newsgroups: comp.sys.unisys
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com> <dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com> <86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <th719c$pmff$1@dont-email.me> <tzEZK.240992$PRW4.19882@fx11.iad> <thhmup$2mogl$1@dont-email.me>
Lines: 69
Message-ID: <xoZ_K.181336$479c.136188@fx48.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Tue, 04 Oct 2022 16:43:09 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Tue, 04 Oct 2022 16:43:09 GMT
X-Received-Bytes: 4308
 by: Scott Lurndal - Tue, 4 Oct 2022 16:43 UTC

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 9/30/2022 9:12 AM, Scott Lurndal wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> On 9/28/2022 6:48 AM, Kira Ash wrote:
>>>> On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:
>>>
>>>>> Rereading parts of your web site, a few minor nits.
>>>
>>> Your section on other mainframe systems got me to do some research.
>>>
>>> 1. You mention that GCOS was emulated on Itanium hardware, but with its
>>> demise, you didn't know what happened. According to
>>>
>>> https://en.wikipedia.org/wiki/General_Comprehensive_Operating_System#Legacy
>>>
>>> it is now emulated on various Xeon based systems.
>>>
>>> 2. Your mention of the Siemens BS2000, systems brought up a memory that
>>> they were another of the "almost IBM S/360 compatible" systems, but I
>>> wasn't sure. Again from Wikipedia
>>>
>>> https://en.wikipedia.org/wiki/BS2000
>>>
>>> it was based on the RCA Spectra/70 series, which is the same series
>>> that, when RCA decided to exit the computer business, they sold to
>>> Univac which became the high end of the Univac Series 90!
>>>
>>> Probably OT for this group, but all of this got me to wondering why,
>>> several companies chose to build their own computer lines, and their own
>>> OS, designed their hardware to be "almost" IBM compatible? Or, to put
>>> it another way, What was so compelling about the ISA that several
>>> companies decided to adopt it, even when the software wouldn't be
>>> compatible?
>>
>> Burroughs chose EBCDIC for compatability with IBM peripherals.
>
>I presume you meant data compatibility of the media (primarily tape),
>not the peripheral, as things like tape drives don't care at all what
>data you write (i.e. "bits is bits").

Actually, IBM (compatiable, e.g. Memorex) peripherals themselves
were often rebadged and used with Burroughs systems.

'Burroughs intended target was the low-end 360/30 and 360/40
which were marketed to SMBs. Thus, the machines used IBM's EBCDIC
coding for data and emulated IBM's file structures [ed. on tape]'.

https://books.google.com/books?id=Mk9-EAAAQBAJ&pg=PA120&lpg=PA120&dq=dave+dahm+ebcdic+burroughs&source=bl&ots=Noc6PbRnKC&sig=ACfU3U1gnPP99Wsx3UufLwMVBcTqaAUH7Q&hl=en&sa=X&ved=2ahUKEwjIhZiogcf6AhX9LEQIHZHqDwsQ6AF6BAgkEAM#v=onepage&q=dave%20dahm%20ebcdic%20burroughs&f=false

>
>Caveat, I just don't know if "paper" peripherals such as printers, card
>readers or the specialized banking peripherals used with many Burroughs
>systems know about character set.

The peripherals simply return bytes to the controller. On Medium systems,
the I/O descriptors included a bit that requested how those bytes should
be translated by the IOP into the host native EBCDIC (e.g. from 6-bit BCL or 7/8-bit
ASCII to EBCDIC), and vice versa outbound.

>
>BTW, what character code did the Burroughs 5000 series use, as I think
>they were designed before IBM announced EBCDIC?

Originally, they used the same character set as the B300 (6-bit BCL).

Note that both the B5000 and the B2500 were developed in the old
electrodata plant in Pasadena by the same folks that did the E220
and the B300 series.

Re: Working on a series of mini-articles about OS 2200

<thhvnc$2nj4s$2@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=235&group=comp.sys.unisys#235

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: paul.kim...@digm.com (Paul Kimpel)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Tue, 4 Oct 2022 11:57:48 -0700
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <thhvnc$2nj4s$2@dont-email.me>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<th719c$pmff$1@dont-email.me> <tzEZK.240992$PRW4.19882@fx11.iad>
<thhmup$2mogl$1@dont-email.me> <xoZ_K.181336$479c.136188@fx48.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 4 Oct 2022 18:57:48 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="c6d171a7db8bb182395c1b17ef9854c5";
logging-data="2870428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/dIzWu+xveeSmOCF/0EzQP2IUITPJ/6DA="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.1
Cancel-Lock: sha1:bOJ49UDuGywlM+yx57nAzInPxsY=
In-Reply-To: <xoZ_K.181336$479c.136188@fx48.iad>
Content-Language: en-US
 by: Paul Kimpel - Tue, 4 Oct 2022 18:57 UTC

On 10/4/2022 9:43 AM, Scott Lurndal wrote:
>> BTW, what character code did the Burroughs 5000 series use, as I think
>> they were designed before IBM announced EBCDIC?
> Originally, they used the same character set as the B300 (6-bit BCL).
>
> Note that both the B5000 and the B2500 were developed in the old
> electrodata plant in Pasadena by the same folks that did the E220
> and the B300 series.
>

Actually, the B5000/5500/5700 used three character encodings. BCL was
similar to the IBM 1401 code, although the glyphs for a number of the
special characters were different. It was the standard used to
communicate from the various I/O interfaces to most peripheral devices.
When writing to magnetic tape in "alpha" (even-parity) mode, BCL is what
was written.

BCL was not used internally, however. That was referred to as "Internal
Code," which I'll refer to as BIC. It was also used internally on the
B100/200/300/500 systems. There is a symmetric mapping between BIC and
BCL, which was translated by the I/O controller hardware. When writing
to magnetic tape in "binary" (odd-parity) mode, BIC is what was written.
Interestingly, when writing to the head-per-track disk units, the B5500
MCP caused the data to be translated from BIC to BCL instead of writing
it transparently.

The third encoding was never visible. It was the collating sequence
implemented by the character comparison hardware, and matched the 1401
collating sequence.

The data communications adapters could translate BCL to/from 7-bit ASCII
on the wire, but the systems could not process ASCII internally, except
by extensive bit-fiddling in software.

For BCL, BIC, and collating sequence encodings, see Appendix A in

http://bitsavers.org/pdf/burroughs/B5000_5500_5700/1021326_B5500_RefMan_May67.pdf

I assume by "E220" Scott meant the Burroughs 220, which was a
vacuum-tube, decimal, core memory system. ca. 1958. The Pasadena plant
was also the origin of the ElectroData Datatron 203/204/205 systems,
which were also vacuum-tube, decimal systems, but with a drum memory.

Burroughs purchased ElectroData in 1956 to gain an entry into the
commercial computer market and re-badged the Datatron 205 as the
Burroughs 205, which is well known to fans of the 1960s Lost in Space
and Batman TV shows, among others.

Paul

Re: Working on a series of mini-articles about OS 2200

<ts0%K.201564$IRd5.83849@fx10.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=236&group=comp.sys.unisys#236

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx10.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Working on a series of mini-articles about OS 2200
Newsgroups: comp.sys.unisys
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com> <86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <th719c$pmff$1@dont-email.me> <tzEZK.240992$PRW4.19882@fx11.iad> <thhmup$2mogl$1@dont-email.me> <xoZ_K.181336$479c.136188@fx48.iad> <thhvnc$2nj4s$2@dont-email.me>
Lines: 52
Message-ID: <ts0%K.201564$IRd5.83849@fx10.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Tue, 04 Oct 2022 20:12:09 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Tue, 04 Oct 2022 20:12:09 GMT
X-Received-Bytes: 3468
 by: Scott Lurndal - Tue, 4 Oct 2022 20:12 UTC

Paul Kimpel <paul.kimpel@digm.com> writes:
>On 10/4/2022 9:43 AM, Scott Lurndal wrote:
>>> BTW, what character code did the Burroughs 5000 series use, as I think
>>> they were designed before IBM announced EBCDIC?
>> Originally, they used the same character set as the B300 (6-bit BCL).
>>
>> Note that both the B5000 and the B2500 were developed in the old
>> electrodata plant in Pasadena by the same folks that did the E220
>> and the B300 series.
>>
>
>Actually, the B5000/5500/5700 used three character encodings. BCL was
>similar to the IBM 1401 code, although the glyphs for a number of the
>special characters were different. It was the standard used to
>communicate from the various I/O interfaces to most peripheral devices.
>When writing to magnetic tape in "alpha" (even-parity) mode, BCL is what
>was written.

Correction noted. I started in Pasadena after Large Systems left
for Mission Viejo and Forest Lake, so I was only exposed to the
B7900 as a user while simulating the new medium systems _Omega_
architecture.

>
>I assume by "E220" Scott meant the Burroughs 220, which was a

Yes, the Burroughs 220 (I believe development had started prior
to the acquisition). I have here "An Introduction to Coding the
Burroughs 220 (Dec '58)" that I should have referred to prior to posting.

One B220 word is 11 BCD digits (10 + sign). the columns on paper tape and cards
are mapped in to the BCD digits (e.g. 10- or 11-column fields are mapped
to consecutive words in memory). The 11th row, if punched, denoted a
minus sign (for 10-column fields - a 1 in the first column of a
field denotes the minus sign for 11-column fields).

Uppercase letters have use the 12th, 11th and 0 rows to designate
the 26 letters with other (unspecifed in this document) punches
for special characters. Characters handled by the "Cardatron
Control Unit" and translated appropriately for the B220.

>vacuum-tube, decimal, core memory system. ca. 1958. The Pasadena plant
>was also the origin of the ElectroData Datatron 203/204/205 systems,
>which were also vacuum-tube, decimal systems, but with a drum memory.

I have several original Elecrodata manuals for the 203/204/205
systems & periperhals that I acquired when Unisys discarded most of the historical
documents that used to be in the Pasadena documentation library
and had been in storage at Iron Mountain since pasadena closed in
the early 90's.

Re: Working on a series of mini-articles about OS 2200

<thi4ha$2o1s2$1@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=237&group=comp.sys.unisys#237

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Tue, 4 Oct 2022 13:19:51 -0700
Organization: A noiseless patient Spider
Lines: 75
Message-ID: <thi4ha$2o1s2$1@dont-email.me>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<th719c$pmff$1@dont-email.me> <tzEZK.240992$PRW4.19882@fx11.iad>
<thhmup$2mogl$1@dont-email.me> <xoZ_K.181336$479c.136188@fx48.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 4 Oct 2022 20:19:55 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="69ba7dc78530efe5a43b63ccb2c2b105";
logging-data="2885506"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/9kjCrSKQ/VG/c+SlIpzwg9GpL/G3hoJk="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.1
Cancel-Lock: sha1:N/iPBvBxPGRbMwUMSgWNDh4VXPk=
In-Reply-To: <xoZ_K.181336$479c.136188@fx48.iad>
Content-Language: en-US
 by: Stephen Fuld - Tue, 4 Oct 2022 20:19 UTC

On 10/4/2022 9:43 AM, Scott Lurndal wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> On 9/30/2022 9:12 AM, Scott Lurndal wrote:
>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>>> On 9/28/2022 6:48 AM, Kira Ash wrote:
>>>>> On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:
>>>>
>>>>>> Rereading parts of your web site, a few minor nits.
>>>>
>>>> Your section on other mainframe systems got me to do some research.
>>>>
>>>> 1. You mention that GCOS was emulated on Itanium hardware, but with its
>>>> demise, you didn't know what happened. According to
>>>>
>>>> https://en.wikipedia.org/wiki/General_Comprehensive_Operating_System#Legacy
>>>>
>>>> it is now emulated on various Xeon based systems.
>>>>
>>>> 2. Your mention of the Siemens BS2000, systems brought up a memory that
>>>> they were another of the "almost IBM S/360 compatible" systems, but I
>>>> wasn't sure. Again from Wikipedia
>>>>
>>>> https://en.wikipedia.org/wiki/BS2000
>>>>
>>>> it was based on the RCA Spectra/70 series, which is the same series
>>>> that, when RCA decided to exit the computer business, they sold to
>>>> Univac which became the high end of the Univac Series 90!
>>>>
>>>> Probably OT for this group, but all of this got me to wondering why,
>>>> several companies chose to build their own computer lines, and their own
>>>> OS, designed their hardware to be "almost" IBM compatible? Or, to put
>>>> it another way, What was so compelling about the ISA that several
>>>> companies decided to adopt it, even when the software wouldn't be
>>>> compatible?
>>>
>>> Burroughs chose EBCDIC for compatability with IBM peripherals.
>>
>> I presume you meant data compatibility of the media (primarily tape),
>> not the peripheral, as things like tape drives don't care at all what
>> data you write (i.e. "bits is bits").
>
> Actually, IBM (compatiable, e.g. Memorex) peripherals themselves
> were often rebadged and used with Burroughs systems.

Thanks, I had forgotten that. But my point is that the choice to use
IBM PCM peripheral devices is independent of the choice to use EBCDIC as
the character code. Many vendors used IBM PCM devices primarily to save
development costs even if they used something other than EBCDIC.

If you did want to interchange tape media, then you did need to be able
to write and read EBCDIC, but a translation in the I/O device connection
(Channel, DLP, etc.) is sufficient for that, as you wrote. And if you
wanted to, you could even use a non-IBM PCM tape drive, as long at it
read and wrote compatible 9 track tapes.

Especially for disk drives, where unless you planned to allow
interchange of removable disk packs with IBM systems (I don't, know of
any systems vendor that did that), what you wrote on the disks didn't
matter to anyone except you internally.

>
> 'Burroughs intended target was the low-end 360/30 and 360/40
> which were marketed to SMBs. Thus, the machines used IBM's EBCDIC
> coding for data and emulated IBM's file structures [ed. on tape]'.
>
> https://books.google.com/books?id=Mk9-EAAAQBAJ&pg=PA120&lpg=PA120&dq=dave+dahm+ebcdic+burroughs&source=bl&ots=Noc6PbRnKC&sig=ACfU3U1gnPP99Wsx3UufLwMVBcTqaAUH7Q&hl=en&sa=X&ved=2ahUKEwjIhZiogcf6AhX9LEQIHZHqDwsQ6AF6BAgkEAM#v=onepage&q=dave%20dahm%20ebcdic%20burroughs&f=false

Makes sense. The excerpt at that link is quite interesting. It gives a
lot of detail on internals, ISA etc. Thanks.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Working on a series of mini-articles about OS 2200

<h53%K.358460$wLZ8.36388@fx18.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=238&group=comp.sys.unisys#238

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx18.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Working on a series of mini-articles about OS 2200
Newsgroups: comp.sys.unisys
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com> <86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <th719c$pmff$1@dont-email.me> <tzEZK.240992$PRW4.19882@fx11.iad> <thhmup$2mogl$1@dont-email.me> <xoZ_K.181336$479c.136188@fx48.iad> <thi4ha$2o1s2$1@dont-email.me>
Lines: 25
Message-ID: <h53%K.358460$wLZ8.36388@fx18.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Tue, 04 Oct 2022 23:12:13 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Tue, 04 Oct 2022 23:12:13 GMT
X-Received-Bytes: 2443
 by: Scott Lurndal - Tue, 4 Oct 2022 23:12 UTC

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 10/4/2022 9:43 AM, Scott Lurndal wrote:

>
>>
>> 'Burroughs intended target was the low-end 360/30 and 360/40
>> which were marketed to SMBs. Thus, the machines used IBM's EBCDIC
>> coding for data and emulated IBM's file structures [ed. on tape]'.
>>
>> https://books.google.com/books?id=Mk9-EAAAQBAJ&pg=PA120&lpg=PA120&dq=dave+dahm+ebcdic+burroughs&source=bl&ots=Noc6PbRnKC&sig=ACfU3U1gnPP99Wsx3UufLwMVBcTqaAUH7Q&hl=en&sa=X&ved=2ahUKEwjIhZiogcf6AhX9LEQIHZHqDwsQ6AF6BAgkEAM#v=onepage&q=dave%20dahm%20ebcdic%20burroughs&f=false
>
>Makes sense. The excerpt at that link is quite interesting. It gives a
>lot of detail on internals, ISA etc. Thanks.

I've got a working simulator, with the most recent MCP, compilers, CANDE,
and so forth for the Medium systems line, which can be configured
for each of B2500, B4700, B4800, B4900, V380, V430, V530, V560, V590
with a full set of simulated peripherals (except for the
document processors (check sorters) and multiple-tape listers).

(The comment in the book that the B4700 was the final model in the
series is incorrect, three further generations of the architecture
were sold until the early 90's when the line was discontinued[*]).

[*] DS (Discontinue) was the MCP command to terminate a process :-)

Re: Working on a series of mini-articles about OS 2200

<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=239&group=comp.sys.unisys#239

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:a05:620a:24d6:b0:6cd:f2d9:4a59 with SMTP id m22-20020a05620a24d600b006cdf2d94a59mr19068261qkn.457.1664935090366;
Tue, 04 Oct 2022 18:58:10 -0700 (PDT)
X-Received: by 2002:a05:6870:562c:b0:132:9226:ad41 with SMTP id
m44-20020a056870562c00b001329226ad41mr1445607oao.264.1664935090009; Tue, 04
Oct 2022 18:58:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Tue, 4 Oct 2022 18:58:09 -0700 (PDT)
In-Reply-To: <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=174.31.251.138; posting-account=DycLBQoAAACVeYHALMkZoo5C926pUXDC
NNTP-Posting-Host: 174.31.251.138
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: l_c...@juno.com (Lewis Cole)
Injection-Date: Wed, 05 Oct 2022 01:58:10 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 6581
 by: Lewis Cole - Wed, 5 Oct 2022 01:58 UTC

> On Wednesday, September 28, 2022 at 6:48:32 AM UTC-7, Kira Ash wrote:
>> On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:
< snip >
>> Rereading parts of your web site, a few minor nits.
>>
< snip >
>>
>> 2. When you talk about file names you missed a subtlety. Note that the
>> dollar sign $, is a legal character in file names. With a flat file
>> system, you have to insure that the combination of Qualifier and
>> Filename are unique across the whole system. But the OS has various
>> system files, some visible to the user (e.g system libraries), some not,
>> e.g. the swap file. So in your file naming, you have to insure you
>> don't mistakenly use a name that the system is already using. So early
>> on, Univac decided that all Exec files would contain a dollar sign in
>> the name. So to insure no conflicts, all a use has to do is not use a
>> dollar sign in the name any of his files.
>>
< snip >
>> - Stephen Fuld
>> (e-mail address disguised to prevent spam)
>
> I've revised the section on filenames to mention that system files all contain a $ - I had actually noticed that and > was curious about the reason, so thanks for explaining it! Also corrected the mention of decimal floating point.
>
> Thanks again for your feedback - I want to get this right!

You probably don't want to hear from me again, but it occurred to me that the OS2200/OS1100/Exec8 file system might be a good place to show case the fact that it might not be as backward of a system as those coming from a micro/mini environment might imagine, but rather simply different because of the different evolutionary path involved.

I assume that you are probably aware of this, but just in case, what I'm specifically referring to is the fact that due to their evolutionary history, many/most? folks used to micros/minis often times assume that there's a one-to-one relationship between disks and file systems.
That is each disk must have on it one and only one file system, and for each file system must exist on one and only one disk.
Given that in the Good Old Days folks were lucky if there as even one disk on early micro/mini systems and the media on such a disk might be physically removeable, it makes sense to assume that any given disk must contain a complete file system so that moving the media doesn't cause the data on it to become inaccessible.

Mainframe systems, however, usually had quite a few attached disks, some of which might have physically removable disk packs.
But just because a disk pack could be or couldn't be physically moved without taking apart the drive it was attached to did not/does not mean that the OS has to treat it, or rather the disk drive that pack was attached/mounted on, that way.
An OS can treat a disk drive with its mounted disk pack as being "logically removable" even though its pack couldn't be removed (AKA physically "fixed") or treat a disk drive with its mounted pack as "fixed" even though its pack could be physically removed (AKA physically "removable").

In the case of OS2200/OS1100/Exec8, a disk pack that is "prep" ("prepared"/initialized) as "removable" did contain enough stuff on it so that it could be moved around in the disk farm attached to an 1100/2200 system.

But if the pack was prepped "fixed", then the OS regarded it as being permanently a part of the system and so the OS doesn't do anything to try to restrict the files so that they reside entirely on one and only one disk pack.
IOW, parts of files can be spread out over just about ANY ("fixed") disk in the system.
This is of course something that folks familiar with Unix/Linux think of as a modern invention of Sun in the form of the ZFS file system and its ilk since 2000-something ... except that it's been present in OS2200/OS1100/Exec8 for something like 40+ years before.

I recently saw a question elsewhere in comp.sys.unisys where a person asked if there was a utility for finding out what files were on a particular pack.
The people who answered appeared to be fluent in Burroughs systems, which makes sense because that question is usually effectively meaningless for 1100/2200 systems.

Of course, one of the nice things about ZFS is interest in detecting and/or preventing bit rot and I this is something that (AFAIK) wasn't really a concern for OS2200/OS1100/Exec8 systems.
Perhaps bit rot was somewhat ameliorated by rolling out mass storage files to tape and rolling them in from tape to mass storage, but that's something I never really thought about.
Perhaps Mr. Fuld and/or Mr. Schroth can wave their arms at this.

In any case, I don't think that this distribution of file parts across disks is something that most folks even those who come from an 1100/2200 environment would notice or care about and therefore bother mentioning when talking to someone who comes from a non-1100/2200 environment.

Re: Working on a series of mini-articles about OS 2200

<thjcph$1ggb$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=240&group=comp.sys.unisys#240

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!aioe.org!5o/dDybsjSwKCUt9oFhEPg.user.46.165.242.75.POSTED!not-for-mail
From: Dou...@hyperspace.vogon.gov (Andrew)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Wed, 5 Oct 2022 09:46:57 +0200
Organization: Aioe.org NNTP Server
Message-ID: <thjcph$1ggb$1@gioia.aioe.org>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="49675"; posting-host="5o/dDybsjSwKCUt9oFhEPg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.13
X-Notice: Filtered by postfilter v. 0.9.2
 by: Andrew - Wed, 5 Oct 2022 07:46 UTC

Lewis Cole wrote:
>> On Wednesday, September 28, 2022 at 6:48:32 AM UTC-7, Kira Ash wrote:
>>> On Tuesday, September 27, 2022 at 10:27:09 PM UTC-7, Stephen Fuld wrote:
> < snip >
>>> Rereading parts of your web site, a few minor nits.
>>>
> < snip >
>>>
>>> 2. When you talk about file names you missed a subtlety. Note that the
>>> dollar sign $, is a legal character in file names. With a flat file
>>> system, you have to insure that the combination of Qualifier and
>>> Filename are unique across the whole system. But the OS has various
>>> system files, some visible to the user (e.g system libraries), some not,
>>> e.g. the swap file. So in your file naming, you have to insure you
>>> don't mistakenly use a name that the system is already using. So early
>>> on, Univac decided that all Exec files would contain a dollar sign in
>>> the name. So to insure no conflicts, all a use has to do is not use a
>>> dollar sign in the name any of his files.
>>>
> < snip >
>>> - Stephen Fuld
>>> (e-mail address disguised to prevent spam)
>>
>> I've revised the section on filenames to mention that system files all contain a $ - I had actually noticed that and > was curious about the reason, so thanks for explaining it! Also corrected the mention of decimal floating point.
>>
>> Thanks again for your feedback - I want to get this right!
>
> You probably don't want to hear from me again, but it occurred to me that the OS2200/OS1100/Exec8 file system might be a good place to show case the fact that it might not be as backward of a system as those coming from a micro/mini environment might imagine, but rather simply different because of the different evolutionary path involved.
>
> I assume that you are probably aware of this, but just in case, what I'm specifically referring to is the fact that due to their evolutionary history, many/most? folks used to micros/minis often times assume that there's a one-to-one relationship between disks and file systems.
> That is each disk must have on it one and only one file system, and for each file system must exist on one and only one disk.
> Given that in the Good Old Days folks were lucky if there as even one disk on early micro/mini systems and the media on such a disk might be physically removeable, it makes sense to assume that any given disk must contain a complete file system so that moving the media doesn't cause the data on it to become inaccessible.
>
> Mainframe systems, however, usually had quite a few attached disks, some of which might have physically removable disk packs.
> But just because a disk pack could be or couldn't be physically moved without taking apart the drive it was attached to did not/does not mean that the OS has to treat it, or rather the disk drive that pack was attached/mounted on, that way.
> An OS can treat a disk drive with its mounted disk pack as being "logically removable" even though its pack couldn't be removed (AKA physically "fixed") or treat a disk drive with its mounted pack as "fixed" even though its pack could be physically removed (AKA physically "removable").
>
> In the case of OS2200/OS1100/Exec8, a disk pack that is "prep" ("prepared"/initialized) as "removable" did contain enough stuff on it so that it could be moved around in the disk farm attached to an 1100/2200 system.
>
> But if the pack was prepped "fixed", then the OS regarded it as being permanently a part of the system and so the OS doesn't do anything to try to restrict the files so that they reside entirely on one and only one disk pack.
> IOW, parts of files can be spread out over just about ANY ("fixed") disk in the system.
> This is of course something that folks familiar with Unix/Linux think of as a modern invention of Sun in the form of the ZFS file system and its ilk since 2000-something ... except that it's been present in OS2200/OS1100/Exec8 for something like 40+ years before.
>
> I recently saw a question elsewhere in comp.sys.unisys where a person asked if there was a utility for finding out what files were on a particular pack.
> The people who answered appeared to be fluent in Burroughs systems, which makes sense because that question is usually effectively meaningless for 1100/2200 systems.
>
If the pack is Fixed, @fas can tell you although it's a bit clumsy.
If the pack is Rem, @prt,d is the way to go.

> Of course, one of the nice things about ZFS is interest in detecting and/or preventing bit rot and I this is something that (AFAIK) wasn't really a concern for OS2200/OS1100/Exec8 systems.
> Perhaps bit rot was somewhat ameliorated by rolling out mass storage files to tape and rolling them in from tape to mass storage, but that's something I never really thought about.
> Perhaps Mr. Fuld and/or Mr. Schroth can wave their arms at this.
>
> In any case, I don't think that this distribution of file parts across disks is something that most folks even those who come from an 1100/2200 environment would notice or care about and therefore bother mentioning when talking to someone who comes from a non-1100/2200 environment.
>
In my last job I would move files from one pack to another (both Fixed
and Rem) and then I really cared what was on a pack. Normally my
utilities would insist on exclusive use of a file, although sometimes
I'd accept read-only access from other processes.
This was on high-availability systems and I wrote the utilities so we
could migrate from older discs to newer ones. Obviously older Fixed
packs would be in SUspend mode.
Once I had the usage of the old packs down to a minimum it was time for
a JK4+9 boot.

Re: Working on a series of mini-articles about OS 2200

<1fg%K.112972$tRy7.100599@fx36.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=241&group=comp.sys.unisys#241

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx36.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Working on a series of mini-articles about OS 2200
Newsgroups: comp.sys.unisys
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com> <dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com> <86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
Lines: 57
Message-ID: <1fg%K.112972$tRy7.100599@fx36.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Wed, 05 Oct 2022 14:10:05 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Wed, 05 Oct 2022 14:10:05 GMT
X-Received-Bytes: 3957
 by: Scott Lurndal - Wed, 5 Oct 2022 14:10 UTC

Lewis Cole <l_cole@juno.com> writes:
>> On Wednesday, September 28, 2022 at 6:48:32 AM UTC-7, Kira Ash wrote:

>Mainframe systems, however, usually had quite a few attached disks, some of=
> which might have physically removable disk packs.
>But just because a disk pack could be or couldn't be physically moved witho=
>ut taking apart the drive it was attached to did not/does not mean that the=
> OS has to treat it, or rather the disk drive that pack was attached/mounte=
>d on, that way.
>An OS can treat a disk drive with its mounted disk pack as being "logically=
> removable" even though its pack couldn't be removed (AKA physically "fixed=
>") or treat a disk drive with its mounted pack as "fixed" even though its p=
>ack could be physically removed (AKA physically "removable").
>
>In the case of OS2200/OS1100/Exec8, a disk pack that is "prep" ("prepared"/=
>initialized) as "removable" did contain enough stuff on it so that it could=
> be moved around in the disk farm attached to an 1100/2200 system.
>
>But if the pack was prepped "fixed", then the OS regarded it as being perma=
>nently a part of the system and so the OS doesn't do anything to try to res=
>trict the files so that they reside entirely on one and only one disk pack.
>IOW, parts of files can be spread out over just about ANY ("fixed") disk in=
> the system.

Burroughs medium systems also provided similar capabilities. It distinguished
between the original 100-byte sector media (disk) and 180-byte sector media
(pack). The disk array could consist of one or more subsystems, with
files allocated across units within a subsystem (under control of the
application).

Packs were organized into named "Families" which could consist of a single
unit or multiple units as required for capacity, throughput and load balancing.

For Medium systems, up to four hosts could be loosely coupled and fully share
disk subsystems or pack families[*]; something I've not heard that the Univac
decendents could do.

[*] FPM (file Protect Memory) or later SSP (Shared System Processor) units provided
record-level lockout capabilities betwen hosts.

>This is of course something that folks familiar with Unix/Linux think of as=
> a modern invention of Sun in the form of the ZFS file system and its ilk s=
>ince 2000-something ... except that it's been present in OS2200/OS1100/Exec=
>8 for something like 40+ years before.

It's been present in Unix systems since 1990, which is over thirty years
ago (see, for example, Veritas (nee Tolerant) file systems).

>The people who answered appeared to be fluent in Burroughs systems, which m=
>akes sense because that question is usually effectively meaningless for 110=
>0/2200 systems.

As noted above, Burroughs systems have similar capabilities to the Univac
descendents with respect to disk (medium systems) and pack families (large
systems and medium systems).

Re: Working on a series of mini-articles about OS 2200

<jq5jsuFcuu4U1@mid.individual.net>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=242&group=comp.sys.unisys#242

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: bill.gun...@gmail.com (Bill Gunshannon)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Wed, 5 Oct 2022 10:50:05 -0400
Lines: 21
Message-ID: <jq5jsuFcuu4U1@mid.individual.net>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net lzv9PkH/EWEUWvQ578PVoAMSQkFFE6Kds5QRePHXf+drBoc5mC
Cancel-Lock: sha1:ejnunUhYIFrcqR3RzKB4Fx/uJ30=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.11.0
Content-Language: en-US
In-Reply-To: <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
 by: Bill Gunshannon - Wed, 5 Oct 2022 14:50 UTC

On 10/4/22 21:58, Lewis Cole wrote:
>
> I assume that you are probably aware of this, but just in case, what I'm specifically referring to is the fact that due to their evolutionary history, many/most? folks used to micros/minis often times assume that there's a one-to-one relationship between disks and file systems.

Why on earth would you think that?

> That is each disk must have on it one and only one file system, and for each file system must exist on one and only one disk.
> Given that in the Good Old Days folks were lucky if there as even one disk on early micro/mini systems and the media on such a disk might be physically removeable, it makes sense to assume that any given disk must contain a complete file system so that moving the media doesn't cause the data on it to become inaccessible.

Sorry, but that isn't at all real. Unix, which began on the PDP-11
minicomputer, not only supported multiple file systems on a single
disk (even on disks as small as the 10 Meg RL02) but in some cases
required it for a properly working system.

And then, PC's from the very early days supported multiple (and often
very different) file systems on single disks which gave us the concept
of dual (or more) booting systems. Even on DOS only systems it was
not unusual to partition the disk and separate the DOS and USER file
systems.

bill

Re: Working on a series of mini-articles about OS 2200

<thk6ko$30lnc$2@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=243&group=comp.sys.unisys#243

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: paul.kim...@digm.com (Paul Kimpel)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Wed, 5 Oct 2022 08:08:08 -0700
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <thk6ko$30lnc$2@dont-email.me>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 5 Oct 2022 15:08:09 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="38c87f5d657722ff67c74a5c6772f3f7";
logging-data="3167980"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/iTemZQFjszP6WQqY2lxar+wav3S1eHKg="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.1
Cancel-Lock: sha1:McZDxHw4K1jVzUOZI7wswkIb1ss=
Content-Language: en-US
In-Reply-To: <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
 by: Paul Kimpel - Wed, 5 Oct 2022 15:08 UTC

On 10/4/2022 6:58 PM, Lewis Cole wrote:
> I recently saw a question elsewhere in comp.sys.unisys where a person asked if there was a utility for finding out what files were on a particular pack.
> The people who answered appeared to be fluent in Burroughs systems, which makes sense because that question is usually effectively meaningless for 1100/2200 systems.

If I'm thinking of the same post that Lewis is, the question was one of
searching for files of the same name on any (meaning all) pack units of
a system, but what that actually means depends on the interpretation of
"pack".

Since the mid-1970s the ClearPath MCP disk file systems have been
organized around the concept a "pack family". A family is a set of one
or more hardware-addressable disk units. Of course, just what a
hardware-addressable disk unit is from the MCP perspective has become a
complex question in the context of Storage Area Networks and Network
Attached Storage, and may not relate to a single spindle or SSD, let
alone all of one.

Each family has a unique name and a separate directory structure. User
applications identify individual files as "filename ON familyname." Each
file consists of a number of "areas" (extents) of contiguous storage
space on a unit, and with multi-unit families, the areas of a file are
typically distributed across all units of its family.

So, if you interpret "pack" as an addressable disk unit (whatever that
means these days), then the question is equally meaningless on MCP
systems, since a file can be spread across many "packs".

I think that most MCP users will interpret "pack" in the context of the
OP as "pack family", though, in which case the question is entirely
meaningful, as I thought it was when I saw the OP.

BTW, there is a utility (SYSTEM/FILEDATA) that will report which areas
of a file are on a specific disk unit, along with their starting
addresses, but in my experience, people hardly ever care about that.

Paul

Re: Working on a series of mini-articles about OS 2200

<thlrhk$381db$1@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=244&group=comp.sys.unisys#244

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Wed, 5 Oct 2022 23:10:58 -0700
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <thlrhk$381db$1@dont-email.me>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 6 Oct 2022 06:11:00 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="ebcbfec707691958bbdaa325f155b593";
logging-data="3409323"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX193W41toSj8SYGx0IUEd9sqKPB+D68hemI="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.3.1
Cancel-Lock: sha1:HboVh2sDaBVoxXduNwcnxkeJgpc=
Content-Language: en-US
In-Reply-To: <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
 by: Stephen Fuld - Thu, 6 Oct 2022 06:10 UTC

On 10/4/2022 6:58 PM, Lewis Cole wrote:

snip

> You probably don't want to hear from me again, but it occurred to me that the OS2200/OS1100/Exec8 file system might be a good place to show case the fact that it might not be as backward of a system as those coming from a micro/mini environment might imagine, but rather simply different because of the different evolutionary path involved.
>
> I assume that you are probably aware of this, but just in case, what I'm specifically referring to is the fact that due to their evolutionary history, many/most? folks used to micros/minis often times assume that there's a one-to-one relationship between disks and file systems.
> That is each disk must have on it one and only one file system, and for each file system must exist on one and only one disk.
> Given that in the Good Old Days folks were lucky if there as even one disk on early micro/mini systems and the media on such a disk might be physically removeable, it makes sense to assume that any given disk must contain a complete file system so that moving the media doesn't cause the data on it to become inaccessible.
>
> Mainframe systems, however, usually had quite a few attached disks, some of which might have physically removable disk packs.
> But just because a disk pack could be or couldn't be physically moved without taking apart the drive it was attached to did not/does not mean that the OS has to treat it, or rather the disk drive that pack was attached/mounted on, that way.
> An OS can treat a disk drive with its mounted disk pack as being "logically removable" even though its pack couldn't be removed (AKA physically "fixed") or treat a disk drive with its mounted pack as "fixed" even though its pack could be physically removed (AKA physically "removable").
>
> In the case of OS2200/OS1100/Exec8, a disk pack that is "prep" ("prepared"/initialized) as "removable" did contain enough stuff on it so that it could be moved around in the disk farm attached to an 1100/2200 system.
>
> But if the pack was prepped "fixed", then the OS regarded it as being permanently a part of the system and so the OS doesn't do anything to try to restrict the files so that they reside entirely on one and only one disk pack.
> IOW, parts of files can be spread out over just about ANY ("fixed") disk in the system.
> This is of course something that folks familiar with Unix/Linux think of as a modern invention of Sun in the form of the ZFS file system and its ilk since 2000-something ... except that it's been present in OS2200/OS1100/Exec8 for something like 40+ years before.
>
> I recently saw a question elsewhere in comp.sys.unisys where a person asked if there was a utility for finding out what files were on a particular pack.
> The people who answered appeared to be fluent in Burroughs systems, which makes sense because that question is usually effectively meaningless for 1100/2200 systems.
>
> Of course, one of the nice things about ZFS is interest in detecting and/or preventing bit rot and I this is something that (AFAIK) wasn't really a concern for OS2200/OS1100/Exec8 systems.
> Perhaps bit rot was somewhat ameliorated by rolling out mass storage files to tape and rolling them in from tape to mass storage, but that's something I never really thought about.
> Perhaps Mr. Fuld and/or Mr. Schroth can wave their arms at this.

First of all, I won't comment on or worse yet disparage other systems,
especially as I don't know enough about many of them. But I think the
difference between fixed and removable storage is important. It comes
from the self imposed requirement to be upward compatible with prior
versions. So we have to go back to the beginning of the 1100 series,
before disks became popular.

The mass storage for early 1100 systems was on drums, not disks. (note
that IBM commonly used used the term"drum" for what was actually a fixed
head disk - model 2305, but Univac used real drums for storage).

There were two types of drums. The FH series (432, 880, and 1782)
referred to in another thread were head per track and relatively low
capacity. BTW, the FH stood for flying head, not fixed head, as is
commonly thought. This referred to the fact that the heads "flew" above
the disk surface. They were primarily used for holding the OS itself and
swap files, and other important system files.

The main storage was provided by an incredible device called a Fastrand
drum. These were very large drums with a "head boom" that moved along
the drum axis to access different parts of the drum. For a great
overview, see the article on John Walker's wonderful, worth exploring
site, Fourmilab.

https://www.fourmilab.ch/documents/univac/fastrand.html

Note that this was the origin story of things that remain to this day
such as 28 word sectors and the use of "TRK", and "POS" to refer to
granularity in @asg statements.

Of course, the drum was not physically removable, so there was no
concept of removable devices. As such, all the storage, from as many
Fastrand Devices as a system had, was one big pool. A user neither knew
nor cared which physical device or devices his file was located on
(though there were ways to tell that if you really wanted to know). In
A slight exception was that a user could specify the type of device,
e.g. FH drum or Fastrand.

At this point, it will be useful to take a detour for a bit into
software. Univac provided a program, then called @SECURE, now called
@FAS. This was a file backup and restore program, making backup copies
of mass storage files to tape. But this was integrated with the OS, so
backup information for a file was kept in the directory entry for that
file. This allowed the creation of a "virtual file system". Virtual in
the sense that if the amount of physical mass storage you had got too
full, the OS would call @Secure to move (called Rollout) some files from
disk to tape, and free up the disk space used by those files for some
other file to use. If a user later needed the rolled out file, when he
@asg'd it, the OS automatically called @SECURE to roll it back in.

Later, physical disks were introduced, and some of these had physically
removable disk packs. This allowed the creation of a new type of
storage, called naturally enough, "Removable". The existing storage,
which used to be just "storage" was then called "Fixed". Fixed storage
was managed just as the original storage was, i.e. allocations could go
anywhere, rollout/rollback worked, etc.

But removable storage (by this I mean disks prepped as removable) worked
differently. for a start, when you created a file, if you wanted it on
a particular removable disk pack, you specified the pack-id in the @asg
that created the file. Of course, this information was kept in the
file's directory entry. (actually there were two directory entries for
such files, one on the removable pack itself and another, smaller one,
just containing basic information an the packid where the file was)
While file backup still used @Secure, the Rollout/Rollback mechanism
wasn't used, relying on changing disk packs in the drives to provide
more storage than you have physical devices (for those devices that
supported pack swap).

As Louis mentioned, later, when disk devices without physically
removable packs were introduced (8434, 8450, 8470 and later) the fixed
versus removable idea was maintained, again for backward compatibility.

One other note. While if you wanted to create a file on multiple
removable packs, you would just specify all the pack-ids on the creating
@asg statement, but there was no concept of "families" or predefined
groups of drives.

I apologize that this got too long. :-( I hope your time reading it
wasn't wasted! :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Working on a series of mini-articles about OS 2200

<8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=246&group=comp.sys.unisys#246

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:ad4:5bee:0:b0:4bb:eaab:1a5e with SMTP id k14-20020ad45bee000000b004bbeaab1a5emr32985660qvc.40.1667705525908;
Sat, 05 Nov 2022 20:32:05 -0700 (PDT)
X-Received: by 2002:a05:6808:1b0d:b0:35a:6cdf:921b with SMTP id
bx13-20020a0568081b0d00b0035a6cdf921bmr4072817oib.249.1667705525546; Sat, 05
Nov 2022 20:32:05 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Sat, 5 Nov 2022 20:32:05 -0700 (PDT)
In-Reply-To: <jq5jsuFcuu4U1@mid.individual.net>
Injection-Info: google-groups.googlegroups.com; posting-host=174.31.69.185; posting-account=DycLBQoAAACVeYHALMkZoo5C926pUXDC
NNTP-Posting-Host: 174.31.69.185
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
<jq5jsuFcuu4U1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: l_c...@juno.com (Lewis Cole)
Injection-Date: Sun, 06 Nov 2022 03:32:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 9218
 by: Lewis Cole - Sun, 6 Nov 2022 03:32 UTC

On Wednesday, October 5, 2022 at 7:50:08 AM UTC-7, Bill Gunshannon wrote:
> On 10/4/22 21:58, Lewis Cole wrote:
> >
>> I assume that you are probably aware of this,
>> but just in case, what I'm specifically referring
>> to is the fact that due to their evolutionary history,
>> many/most? folks used to micros/minis often
>> times assume that there's a one-to-one
>> relationship between disks and file systems.
>
> Why on earth would you think that?

You mean, aside from the fact that what I said is true?

>> That is each disk must have on it one and only
>> one file system, and for each file system must
>> exist on one and only one disk.
>> Given that in the Good Old Days folks were lucky
>> if there as even one disk on early micro/mini
>> systems and the media on such a disk might be
>> physically removeable, it makes sense to assume
>> that any given disk must contain a complete file
>> system so that moving the media doesn't cause
>> the data on it to become inaccessible.
>
> Sorry, but that isn't at all real. Unix, which began on
> the PDP-11 minicomputer, not only supported multiple
> file systems on a single disk (even on disks as small
> as the 10 Meg RL02) but in some cases required it
> for a properly working system.

Sorry, but no.

Unix began on a PDP-7, not a PDP-11, and in the beginning there were *NO* disks on the PDP-7 ... zero, zip, nada, none. Instead it had tapes.
Although I'm certainly no expert on Unix development history, the story I heard is that when Unix was first being developed on the PDP-7 with *ONE*, count 'em, *ONE* disk which had a capacity of a few megabytes at most, and it was not partitioned.

Unix was ported to the PDP-11, but that's not how it began.
I assume that you are confused by the fact that when Unix was first announced to the World, it was on a PDP-11.

In any event, it is my understanding that while Unix file system has changed a bit since the early days, back in the time of the PDP-11, it still involved what amounts to a file descriptor (an "inode") and a list of granules allocated to a particular file.
Each entry in the granule list basically contained what amounts to a disk address without any further identification as to location, unlike an 1100/2200 DAD (Device Address Descriptor) pointed at by an 1100/2200 file item.
IOW, the list could *NOT* indicate that a particular granule was located on a different disk.

So while you could argue that by partitioning a real physical disk into multiple virtual disks, you could have more than one file system per (physical) disk (with one file system per virtual disk), that's only from the prospective of the human looking at the system and not the OS that actually has to deal with the "disks".
In effect, it was basically impossible for a file in a file system to span more than one "disks" the way files on "fixed" mass storage do on the 1100/2200.

If you think I am mistaken, then I await with bated breath for you to present evidence to show that this was the case.

> And then, PC's from the very early days supported
> multiple (and often very different) file systems on
> single disks which gave us the concept of dual (or
> more) booting systems.

Sorry but again no.

In the beginning, which is to say even before the IBM PC hit the fan, disk drives of any sort were very much a rarity.
And if they existed, they were 8.5-inch floppies, not 5.25-inch floppies or hard drives, and each floppy or hard disk contained one and only one "file system" if you can call it that.
In the case of CP/M, for example, its file structure basically described a list of allocated granules for a file where each granule did *NOT* allow for the specification of a different disk.
In fact, if you ever changed a floppy on CP/M, you had to effectively reboot the "OS" each time so that it could recognize the fact that a disk had changed.

When (IBM compatible) PCs came along, 8.5-inch floppies gave way to 5.25-inch floppies and eventually hard disks.
In each case, however, there was one-to-one relationship between disks and file systems, in no small part because they used FAT12.
In FAT12, there's a table (well actually two tables but since one is a copy of the other, let's call it one) called a FAT (File Allocation Table) that contains 12-bit pointers to allocated clusters of a file with NO other information at all that would allow bits of files on one physical disk to be linked to bits of files on a different disk.
And this continued on with FAT16 and FAT32 where the pointers simply grew in size from 12-bits to 16-bits and then 32-bits.

"Dual booting" did *NOT* change this in the slightest.
Instead, a trick was cooked up where a table was set up in the Master Boot Record (MBR) that allowed one to treat the disk as if it were actually four separate (virtual) "disks", one "primary" and three "logical".
And with a little extra code and this partition table, you could have a boot loader that could boot from each of the virtual "disks" on the physical disk, but once again, since the file system installed in any of these virtual disks was some version of FAT, it was *NOT* possible for file to span "disks".

Even when HPFS came along, IIRC, they are still using something that amounts to a list of granules without any drive identifier which would allow a file in a file system to span multiple "disks", no matter how you define a "disk" although pointers to lots of other crud in file descriptors was added.

And OBTW, I did this with OS/2 and (I think) MSDOS (although it could have been an early version of Windows) so I can assure you that what I've said is correct from person experience.

> Even on DOS only systems
> it was not unusual to partition the disk and separate
> the DOS and USER file systems.

Again, we're talking about something that eventually developed, but wasn't the case originally.
And due to the limitations of the structures that described files, it wasn't possible (unless you didn't really care about file integrity at least) for files to span "drives" no matter how they were defined.

And what I said still holds true today.

Just the other day, I poked around with a Linux Mint distribution "live" USB drive and looked at the hardware on an old laptop that I'm thinking about installing Linux Mint.
What I see still clearly indicates that there's an MBR with a partition table that can make the hard drive "look" like up to four hard drives, where each "drive" contains one and only one file system.
In fact, if this weren't the case, then the old trick of putting ones "usr" tree on its own "drive" so that everything remains on that one "drive" despite installing newer versions of the OS wouldn't work.

> bill

If you goal was to point out that one can partition physical disk drives so that they can be treated as multiple virtual disk which allows one to have more than one file system per physical disk, then I stand corrected and that you were/are right.
However, as this correction doesn't affect whether or not a file systems of yore could support files that span more than one "disk" -- you know, the first sentence after you asked, "Why on earth would you think that?" -- or where/when things happened historically, you'll pardon me if I don't particularly care about it.

Re: Working on a series of mini-articles about OS 2200

<tk8elb$3539f$1@dont-email.me>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=248&group=comp.sys.unisys#248

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: paul.kim...@digm.com (Paul Kimpel)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Sun, 6 Nov 2022 06:00:11 -0800
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <tk8elb$3539f$1@dont-email.me>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
<jq5jsuFcuu4U1@mid.individual.net>
<8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 6 Nov 2022 14:00:11 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="842d91bcdaff8dda4cd44f72a05b5136";
logging-data="3312943"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/3myWcu+jRGPXOhDT3d32kG+4i6O07znk="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.4.2
Cancel-Lock: sha1:PGgrIqLV8p4/vUrm+VcI1gXhGS0=
In-Reply-To: <8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
Content-Language: en-US
 by: Paul Kimpel - Sun, 6 Nov 2022 14:00 UTC

On 11/5/2022 8:32 PM, Lewis Cole wrote:
> When (IBM compatible) PCs came along, 8.5-inch floppies gave way to 5.25-inch floppies and eventually hard disks.

No, 5.25-inch floppies came along quite a bit earlier (1976) than the
IBM PC (1981). I bought an Apple ][ Plus in 1979 to host Apple Pascal
that had dual 5.25 single-sided disks, storing a whopping 140KB each.
Each disk could have only a single file system, and of course there was
no spanning of file systems across disks.

See https://en.wikipedia.org/wiki/Floppy_disk.

Paul

Re: Working on a series of mini-articles about OS 2200

<TbQ9L.29753$BRy2.6016@fx48.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=249&group=comp.sys.unisys#249

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx48.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Working on a series of mini-articles about OS 2200
Newsgroups: comp.sys.unisys
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com> <86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com> <jq5jsuFcuu4U1@mid.individual.net> <8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
Lines: 41
Message-ID: <TbQ9L.29753$BRy2.6016@fx48.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Sun, 06 Nov 2022 15:14:59 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Sun, 06 Nov 2022 15:14:59 GMT
X-Received-Bytes: 2762
 by: Scott Lurndal - Sun, 6 Nov 2022 15:14 UTC

Lewis Cole <l_cole@juno.com> writes:
>On Wednesday, October 5, 2022 at 7:50:08 AM UTC-7, Bill Gunshannon wrote:
>> On 10/4/22 21:58, Lewis Cole wrote:=20
>> >=20
>>> I assume that you are probably aware of this,=20
>>> but just in case, what I'm specifically referring=20
>>> to is the fact that due to their evolutionary history,=20
>>> many/most? folks used to micros/minis often=20
>>> times assume that there's a one-to-one=20
>>> relationship between disks and file systems.
>>=20
>> Why on earth would you think that?
>
>You mean, aside from the fact that what I said is true?

Given that mainframe systems had no such constraints
in the periods before, during and after the mini
era, and most people using minicomputers in those
days were familiar with one or more mainframe
families, I'm not sure why you think that is true.

For PC and hobby users, on the other hand, multivolume
floppies or cassettes weren't uncommon.

>In any event, it is my understanding that while Unix file system has change=
>d a bit since the early days, back in the time of the PDP-11, it still invo=
>lved what amounts to a file descriptor (an "inode") and a list of granules =
>allocated to a particular file.

That fundamentally describes most file systems, with variations in terminology.

Multivolume filesystems showed up in Unix in the late 80's/early 90's with the
Tolerant filesystem volume manager (later Veritas VxFS/VxVM).

>
>In the beginning, which is to say even before the IBM PC hit the fan, disk =
>drives of any sort were very much a rarity.

For PCs, perhaps. There were of course wide ranges of disk subsystems
from the 1960's forward on mini and mainframe computers.

Re: Working on a series of mini-articles about OS 2200

<jsq6vjFgs1tU1@mid.individual.net>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=250&group=comp.sys.unisys#250

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: bill.gun...@gmail.com (Bill Gunshannon)
Newsgroups: comp.sys.unisys
Subject: Re: Working on a series of mini-articles about OS 2200
Date: Sun, 6 Nov 2022 11:50:59 -0500
Lines: 166
Message-ID: <jsq6vjFgs1tU1@mid.individual.net>
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
<jq5jsuFcuu4U1@mid.individual.net>
<8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net s6Sl+hqIe0DMkTEGme8ipQQZVsjGcuLa66V6wiOMVwjwt+9YhJ
Cancel-Lock: sha1:AKCF+0qpL5AkEXg3Xnq4uYlsZpI=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
Content-Language: en-US
In-Reply-To: <8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
 by: Bill Gunshannon - Sun, 6 Nov 2022 16:50 UTC

On 11/5/22 23:32, Lewis Cole wrote:
> On Wednesday, October 5, 2022 at 7:50:08 AM UTC-7, Bill Gunshannon wrote:
>> On 10/4/22 21:58, Lewis Cole wrote:
>>>
>>> I assume that you are probably aware of this,
>>> but just in case, what I'm specifically referring
>>> to is the fact that due to their evolutionary history,
>>> many/most? folks used to micros/minis often
>>> times assume that there's a one-to-one
>>> relationship between disks and file systems.
>>
>> Why on earth would you think that?
>
> You mean, aside from the fact that what I said is true?
>
>>> That is each disk must have on it one and only
>>> one file system, and for each file system must
>>> exist on one and only one disk.
>>> Given that in the Good Old Days folks were lucky
>>> if there as even one disk on early micro/mini
>>> systems and the media on such a disk might be
>>> physically removeable, it makes sense to assume
>>> that any given disk must contain a complete file
>>> system so that moving the media doesn't cause
>>> the data on it to become inaccessible.
>>
>> Sorry, but that isn't at all real. Unix, which began on
>> the PDP-11 minicomputer, not only supported multiple
>> file systems on a single disk (even on disks as small
>> as the 10 Meg RL02) but in some cases required it
>> for a properly working system.
>
> Sorry, but no.
>
> Unix began on a PDP-7, not a PDP-11, and in the beginning there were *NO* disks on the PDP-7 ... zero, zip, nada, none. Instead it had tapes.

Sorry, I thought we were discussing disks and partitions and not the
history of Unix development.

> Although I'm certainly no expert on Unix development history, the story I heard is that when Unix was first being developed on the PDP-7 with *ONE*, count 'em, *ONE* disk which had a capacity of a few megabytes at most, and it was not partitioned.

Having started with Verison 7 I have no idea how things were handled
on the PDP-7 but I suspect even then it may have been partitioned,
just not like we think of partitioning today.

>
> Unix was ported to the PDP-11, but that's not how it began.
> I assume that you are confused by the fact that when Unix was first announced to the World, it was on a PDP-11.

Again, I didn't think we were discussing Unix History.

>
> In any event, it is my understanding that while Unix file system has changed a bit since the early days, back in the time of the PDP-11, it still involved what amounts to a file descriptor (an "inode") and a list of granules allocated to a particular file.
> Each entry in the granule list basically contained what amounts to a disk address without any further identification as to location, unlike an 1100/2200 DAD (Device Address Descriptor) pointed at by an 1100/2200 file item.
> IOW, the list could *NOT* indicate that a particular granule was located on a different disk.

True, but that has nothing to do with whether or not there were
multiple filesystems on a single disk. In fact, there were.

>
> So while you could argue that by partitioning a real physical disk into multiple virtual disks, you could have more than one file system per (physical) disk (with one file system per virtual disk), that's only from the prospective of the human looking at the system and not the OS that actually has to deal with the "disks".
> In effect, it was basically impossible for a file in a file system to span more than one "disks" the way files on "fixed" mass storage do on the 1100/2200.

Now we're talking about two distinct concepts. Multiple filesystems
on a single disk and a single filesystem on multiple disks. The first
existed in Unix from very early on and the second much later.

>
> If you think I am mistaken, then I await with bated breath for you to present evidence to show that this was the case.

I suggest you look at:
"http://bitsavers.org/pdf/dec/pdp11/ultrix-11/2.0/AA-X343B-TC_ULTRIX-11_SysMgmt_1984.pdf"

Appendix D.

>
>> And then, PC's from the very early days supported
>> multiple (and often very different) file systems on
>> single disks which gave us the concept of dual (or
>> more) booting systems.
>
> Sorry but again no.

Then what was FDISK for?

>
> In the beginning, which is to say even before the IBM PC hit the fan, disk drives of any sort were very much a rarity.
> And if they existed, they were 8.5-inch floppies, not 5.25-inch floppies or hard drives, and each floppy or hard disk contained one and only one "file system" if you can call it that.
> In the case of CP/M, for example, its file structure basically described a list of allocated granules for a file where each granule did *NOT* allow for the specification of a different disk.
> In fact, if you ever changed a floppy on CP/M, you had to effectively reboot the "OS" each time so that it could recognize the fact that a disk had changed.

I never said every OS had partitioned disks. I only need to show
one to disprove your argument. And I did. Unix.

>
> When (IBM compatible) PCs came along, 8.5-inch floppies gave way to 5.25-inch floppies and eventually hard disks.
> In each case, however, there was one-to-one relationship between disks and file systems, in no small part because they used FAT12.
> In FAT12, there's a table (well actually two tables but since one is a copy of the other, let's call it one) called a FAT (File Allocation Table) that contains 12-bit pointers to allocated clusters of a file with NO other information at all that would allow bits of files on one physical disk to be linked to bits of files on a different disk.
> And this continued on with FAT16 and FAT32 where the pointers simply grew in size from 12-bits to 16-bits and then 32-bits.
>
> "Dual booting" did *NOT* change this in the slightest.
> Instead, a trick was cooked up where a table was set up in the Master Boot Record (MBR) that allowed one to treat the disk as if it were actually four separate (virtual) "disks", one "primary" and three "logical".

Isn't that exactly what you said they didn't do? One
disk. Multiple partitions. Each partition with a
different file system on it.

> And with a little extra code and this partition table, you could have a boot loader that could boot from each of the virtual "disks" on the physical disk, but once again, since the file system installed in any of these virtual disks was some version of FAT, it was *NOT* possible for file to span "disks".

That's not what I was trying to show in the first place.
We started out with the premise that no one did multiple
filesystems on a single disk. I showed that they did.
Now, all of a sudden it is the inverse of that. One File
systems spanning ,multiple disks. That didn't come about
until RAID. But it was done in Unix and eventually on
PC class machines but usually on PC class machines it was
done in hardware.

>
> Even when HPFS came along, IIRC, they are still using something that amounts to a list of granules without any drive identifier which would allow a file in a file system to span multiple "disks", no matter how you define a "disk" although pointers to lots of other crud in file descriptors was added.
>
> And OBTW, I did this with OS/2 and (I think) MSDOS (although it could have been an early version of Windows) so I can assure you that what I've said is correct from person experience.
>
>> Even on DOS only systems
>> it was not unusual to partition the disk and separate
>> the DOS and USER file systems.
>
> Again, we're talking about something that eventually developed, but wasn't the case originally.
> And due to the limitations of the structures that described files, it wasn't possible (unless you didn't really care about file integrity at least) for files to span "drives" no matter how they were defined.
>
> And what I said still holds true today.

RAID controllers?

>
> Just the other day, I poked around with a Linux Mint distribution "live" USB drive and looked at the hardware on an old laptop that I'm thinking about installing Linux Mint.
> What I see still clearly indicates that there's an MBR with a partition table that can make the hard drive "look" like up to four hard drives, where each "drive" contains one and only one file system.

No. there is one drive and multiple partitions and each partition
can have a different file system. That's what partitioning does.
It makes a partition look like a drive but there is still only
one drive with multiple file systems on it.

> In fact, if this weren't the case, then the old trick of putting ones "usr" tree on its own "drive" so that everything remains on that one "drive" despite installing newer versions of the OS wouldn't work.

It's not a second "drive", although that's another way of doing it.
It's a partition on the single drive in the system.


Click here to read the complete article
Re: Working on a series of mini-articles about OS 2200

<4ad0b9e1-dd55-48d1-af8c-2ca76a82098an@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=254&group=comp.sys.unisys#254

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:a05:620a:254f:b0:6cf:9b54:11dd with SMTP id s15-20020a05620a254f00b006cf9b5411ddmr33146805qko.55.1667770763005;
Sun, 06 Nov 2022 13:39:23 -0800 (PST)
X-Received: by 2002:a05:6808:2da:b0:35a:1129:9e1b with SMTP id
a26-20020a05680802da00b0035a11299e1bmr20495575oid.23.1667770759256; Sun, 06
Nov 2022 13:39:19 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Sun, 6 Nov 2022 13:39:19 -0800 (PST)
In-Reply-To: <tk8elb$3539f$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=174.31.70.252; posting-account=DycLBQoAAACVeYHALMkZoo5C926pUXDC
NNTP-Posting-Host: 174.31.70.252
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
<jq5jsuFcuu4U1@mid.individual.net> <8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
<tk8elb$3539f$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4ad0b9e1-dd55-48d1-af8c-2ca76a82098an@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: l_c...@juno.com (Lewis Cole)
Injection-Date: Sun, 06 Nov 2022 21:39:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4002
 by: Lewis Cole - Sun, 6 Nov 2022 21:39 UTC

On Sunday, November 6, 2022 at 6:00:13 AM UTC-8, Paul Kimpel wrote:
> On 11/5/2022 8:32 PM, Lewis Cole wrote:
> > When (IBM compatible) PCs came along, 8.5-inch floppies gave way to 5.25-inch floppies and eventually hard disks.
> No, 5.25-inch floppies came along quite a bit earlier (1976) than the
> IBM PC (1981). I bought an Apple ][ Plus in 1979 to host Apple Pascal
> that had dual 5.25 single-sided disks, storing a whopping 140KB each.
> Each disk could have only a single file system, and of course there was
> no spanning of file systems across disks.
>
> See https://en.wikipedia.org/wiki/Floppy_disk.
>
> Paul

You are correct about when 5.25-inch floppies came out relative to the IBM PC.
What I was trying to indicate was that there was a historical progression from 8-inch floppies to 5.25-inch floppies and hard drives that ultimately lead to the IBM PC using 5.25-inch floppies and hard drives after they too weaned themselves off of tape.
Sorry for the confusion.

However, let's be clear here with regard to the sequence of events so as to not leave anyone with the impression that Apple introduced the World to 5.25-inch floppies, shall we?

Shugart introduced the 5.25-inch floppy sometime around 1977 (1976 seems a bit early to me), but they weren't standardized until a couple years later (meaning something like 1978 or 1979 ... I'm too lazy to look up the dates right at the moment).
People began using them in their own homebrew PCs (meaning "Personal Computers", not "PCs" as in the product put out by IBM) pretty much as soon as they became available, and that occurred well before Apple ever included them with the Apple II which started out using tapes for mass storage.
The first commercially produced PCs to use first 5.25-inch based system that I recall were from North Star which I believed used a tweaked version of CP/M they called North Star DOS.

Until the standardization occurred, however, everyone and their brother who offered software on 5.25-inch floppies had to specify what format they were using, with a format by Xerox being one of the most (if not the most) popular version.

And again, not of the various versions supported files spanning disks.

Re: Working on a series of mini-articles about OS 2200

<c96bb391-030a-41b2-9472-cee3d2bbc8c8n@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=255&group=comp.sys.unisys#255

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:a05:620a:1379:b0:6fa:31bf:2ee9 with SMTP id d25-20020a05620a137900b006fa31bf2ee9mr26240725qkl.292.1667771272923;
Sun, 06 Nov 2022 13:47:52 -0800 (PST)
X-Received: by 2002:a05:6870:338c:b0:13a:f214:ff51 with SMTP id
w12-20020a056870338c00b0013af214ff51mr27664165oae.123.1667771272609; Sun, 06
Nov 2022 13:47:52 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Sun, 6 Nov 2022 13:47:52 -0800 (PST)
In-Reply-To: <TbQ9L.29753$BRy2.6016@fx48.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=174.31.70.252; posting-account=DycLBQoAAACVeYHALMkZoo5C926pUXDC
NNTP-Posting-Host: 174.31.70.252
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com> <86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com> <jq5jsuFcuu4U1@mid.individual.net>
<8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com> <TbQ9L.29753$BRy2.6016@fx48.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c96bb391-030a-41b2-9472-cee3d2bbc8c8n@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: l_c...@juno.com (Lewis Cole)
Injection-Date: Sun, 06 Nov 2022 21:47:52 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 7743
 by: Lewis Cole - Sun, 6 Nov 2022 21:47 UTC

>On Wednesday, October 5, 2022 at 7:50:08 AM UTC-7, Bill Gunshannon wrote:
>> On 10/4/22 21:58, Lewis Cole wrote:=20
>>>>
>>>> I assume that you are probably aware of this,=20
>>>> but just in case, what I'm specifically referring=20
>>>> to is the fact that due to their evolutionary history,=20
>>>> many/most? folks used to micros/minis often=20
>>>> times assume that there's a one-to-one=20
>>>> relationship between disks and file systems.
>>>
>>> Why on earth would you think that?
>>
>>You mean, aside from the fact that what I said is true?
>
> Given that mainframe systems had no such constraints
> in the periods before, during and after the mini
> era, and most people using minicomputers in those
> days were familiar with one or more mainframe
> families, I'm not sure why you think that is true.

I think it's true because the "givens" you think applied at the time, didn't.

I don't know you hung out with in your youth, but the people that I was familiar with who messed with minis did so because the college they were had one in one of their departments.
Said mini was fed and cared for by students (because they were cheap) under the nominal control of some faculty member who may well have never set foot in the campus computing center where the mainframe was kept.
For the most part, most students' familiarity with mainframes, including those who played with a mini, was in the form of submitting a deck to a window/keyhole in the morning and hoping that their job would be run by the next day.
Terminals (often times dial-up) eventually came onto the scene to access the mainframe, but you didn't know how/where anything was physically stored on disk (or in my case, drum).

But moreover, we're talking about a time that is now more than two generations ago, and as it so happens, information tends to get lost as time passes.
In one of my previous posts, I bitched about a Retro Computing Roundtable video or two.
In that video, or in one a few videos earlier, the four roundtable members ALL indicated that they had NO IDEA what they were talking about when it came to mainframes.
Some snapshot/slide was shown that had words like JCL, MVS, OS1100, MCP, and one of the members (who happens to be a programmer by the way) said they didn't know what any of the terms meant.

> For PC and hobby users, on the other hand, multivolume
> floppies or cassettes weren't uncommon.

In the early days, this was not the case because disk mass storage of any type was a luxury.
Until prices dropped, one was lucky to have even a cassette drive.

Eventually, disk prices did drop and you could have more than one hard drive in your PC, but as I indicated before, the very structure of FAT rules out the possibility of files that span more than one disk.
So to the extent that you had "multivolume" floppies, each floppy contained one file system and had stored as a file one part of a larger file or collection of files, NOT at all like files are stored on "fixed" mass storage on an 1100/2200.
(And yes, I had a lot of "fun" feeding floppy after floppy into my PC in the Good Old Days to install OS/2, so been there, done that.)

>>In any event, it is my understanding that while Unix file system has change=
>>d a bit since the early days, back in the time of the PDP-11, it still invo=
>>lved what amounts to a file descriptor (an "inode") and a list of granules =
>>allocated to a particular file.
>
>That fundamentally describes most file systems, with variations in terminology.
>

Well, sort of.

I would agree that a "file system" is a system for managing files.
But the devil is in the details when it comes to how/why that management is done.

Yes, many OSs use a list of allocated granules to keep track of the parts of a file, but for a single disk system, you can also use bit maps to keep track of what records are allocated and to who.
And this was in fact done on at least one homebrew FORTH system I read about many, many, many moons ago (I think in BYTE).
It worked just fine AFAIK, but you're clearly not going to be able to describe a file spanning multiple disks with this system.
Why? Because you can't describe what drives some part of a file that's spread across multiple drives is located.

The thing is that you can't do that with a list of granules unless that list allows you to associate granules with disks for basically the same reason.
You can't identify where granules are that are on some other disk unless you happen to partition a physical disk into multiple virtual disks and then keep track of space by an address that identifies physical records.
And in this latter scheme, you can't spread the file beyond the confines of the single physical disk.

This is NOT the case with Exec8/OS1100/OS2200 on the 1100/2200 Series.
Device Address Descriptors (DADs) describe where the granules of a file are located, not just in terms of what records make up the granules, but also what device the records are on.

> Multivolume filesystems showed up in Unix in the late 80's/early 90's with the
> Tolerant filesystem volume manager (later Veritas VxFS/VxVM).

I'm sorry, but I really don't give a rat's ass when multivolume file systems showed up on Unix.
Whenever year you'd like to point at, that year was sometime *AFTER* Exec8 appeared with "fixed" mass storage in its quiver.
This clearly demonstrates that spreading files across multiple disks is a feature that appeared BEFORE Unix ever came onto the scene, and so any notion that its being a "modern" feature, especially one that made its way out of Unix, is wrong.

>>
>> In the beginning, which is to say even before the IBM PC hit the fan, disk
>> drives of any sort were very much a rarity.
>
> For PCs, perhaps. There were of course wide ranges of disk subsystems
> from the 1960's forward on mini and mainframe computers.

Disks were expensive even back in the 1960s.
They were prevalent in places where there were Big Bucks.
Since minis were often times purchased because they were relatively "cheap", they too often times had very few, if any, disks.

Re: Working on a series of mini-articles about OS 2200

<94c6cd59-a891-440a-9eb8-4532c2e66fb5n@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=256&group=comp.sys.unisys#256

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:a05:6214:2aa4:b0:4bc:d3a:7486 with SMTP id js4-20020a0562142aa400b004bc0d3a7486mr32247716qvb.82.1667772122376;
Sun, 06 Nov 2022 14:02:02 -0800 (PST)
X-Received: by 2002:a05:6830:2aa3:b0:66c:9a3a:539 with SMTP id
s35-20020a0568302aa300b0066c9a3a0539mr6213012otu.317.1667772121996; Sun, 06
Nov 2022 14:02:01 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Sun, 6 Nov 2022 14:02:01 -0800 (PST)
In-Reply-To: <jsq6vjFgs1tU1@mid.individual.net>
Injection-Info: google-groups.googlegroups.com; posting-host=174.31.70.252; posting-account=DycLBQoAAACVeYHALMkZoo5C926pUXDC
NNTP-Posting-Host: 174.31.70.252
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<dadf9204-d67e-4795-a89f-8da1e6c38a56n@googlegroups.com> <79311289-d3ff-46a0-9505-f8b9db84b30an@googlegroups.com>
<86e6b563-3b6b-48ee-baa4-48cc15153e40n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me>
<707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me>
<2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com>
<jq5jsuFcuu4U1@mid.individual.net> <8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com>
<jsq6vjFgs1tU1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <94c6cd59-a891-440a-9eb8-4532c2e66fb5n@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: l_c...@juno.com (Lewis Cole)
Injection-Date: Sun, 06 Nov 2022 22:02:02 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 10208
 by: Lewis Cole - Sun, 6 Nov 2022 22:02 UTC

< lots of irrelevant stuff SNIPPED >

>>> If you goal was to point out that one can partition physical
>>> disk drives so that they can be treated as multiple virtual
>>> disk which allows one to have more than one file system per
>>> physical disk, then I stand corrected and that you were/are
>>> right.
>>> However, as this correction doesn't affect whether or not a
>>> file systems of yore could support files that span more than
>>> one "disk" -- you know, the first sentence after you asked,
>>> "Why on earth would you think that?" -- or where/when things
>>> happened historically, you'll pardon me if I don't particularly
>>> care about it.
>
> I'm just baffled at how this went from multiple file systems on
> one disk to multiple disks containing one file system. [...]

Perhaps you'd be less baffled if you re-read what I wrote, including the part you referenced in your original response.
I'll include the relevant part below so you don't have to search for it:

[...] but just in case, what I'm specifically referring
to is the fact that due to their evolutionary history,
many/most? folks used to micros/minis often
times assume that there's a one-to-one
relationship between disks _*AND*_[emphasis added is mine]
file systems.

I thought (and still think) that I was plainly saying many people conflate the word "disk" with the words "file system".
I stand by this statement as nothing you've written gives me cause to think otherwise.

Since I was interested in pointing something out about how Exec8/OS1100/OS2200 deals with files on "fixed" storage, namely how files can be spread across multiple disks, I expressed the conflation by stating two separate statements about disks and file systems which I joined together with the word "and".
IOW, both parts are supposed to be read and taken together.
You, however, appear to have read only the first condition, stopped reading, and then started pounding away at your keyboard to "correct" me for my ignorance.
And now you want to feign ignorance about how we got here ....

> [...] Both of which
> various Unixes have supported for several decades. [...]

Once again, you are conveniently ignoring what I wrote.
Further down in my original post, I wrote:

But if the pack was prepped "fixed", then the OS regarded it
as being permanently a part of the system and so the OS
doesn't do anything to try to restrict the files so that they
reside entirely on one and only one disk pack.
IOW, parts of files can be spread out over just about ANY ("fixed")
disk in the system.
_This is of course something that folks familiar with Unix/Linux
think of as a modern invention of Sun in the form of the ZFS
file system and its ilk since 2000-something ... except that it's
been present in OS2200/OS1100/Exec8 for something like 40+ years
before._ [emphasis added is mine]

And to try to be clear so hopefully I don't have to deal with more misreading of what I wrote, I'm not saying that Unix doesn't support file systems that allow the spreading of files across disk.
I am not saying that this isn't something that hasn't been around for a LONG time in Unix or other "modern" OSs.
I am not saying that other mainframe OSs didn't/don't have this feature either.
And I am not saying that Exec8/OS1100/OS2200 was the first to implement this feature.

What I am saying -- what I have said -- is that this is something that existed long ago even before it made its appearance on more "modern" computers and OSs ... something I think that many/most? people seem to forget.
Computing history did not start with the PDPs, Altairs, Apples, IBM PC, or with Unix.
Many of the features that youngsters like to think of as (relatively) "new" and "innovative" are actually the result of old stuff being rediscovered during their own evolutionary path.
One example of that is files being spread across disks which occurred long before it appeared on Unix, something which clearly shows that it wasn't something added to Exec in response to Unix or some other more "modern" OS.

In response to me pointing out that you were wrong about what machine Unix (at least started on) being developed on, you tried to deflect from the fact that you stated something that was wrong you said that you thought "we" were talking about partitions and file systems, not Unix history.
Well, "we" which is to say "I" am talking about history by way of an example involving disks and file systems.
The fact that one can partition a physical drive into more than one virtual drive doesn't change what I'm talking about, and your attempts to harp on this fact does nothing to change what I'm talking about either.
It's just a piddly aside, but if you want to bring up piddly asides, I'm willing to do the same vis-a-vis the fact that Unix didn't start out on the PDP-11.

> I ran small disks
> combined by software into large disks back in the days we were still
> running SPARC at the University. Needed it for large user file
> space to support over a hundred students and to support very large
> storage area for our USENET News Server.

That's nice. And when was that compared to the introduction of fixed mass storage on Exec8? Ten years later? Twenty years later?
If you can't come up with a date that's *BEFORE* the introduction of Exec8, this comment is like others in your response that I don't care about.

Just to quickly take a swipe a few of them:

1. FDISK (and with it the MBR and its partition table) was introduced into MS-DOS to compensate for the fact that disk sizes had grown beyond the 10MB that FAT12 could deal with sometime in the 1980s IIRC.
The MBR's partition table allowed a single physical hard drive could be broken up into multiple virtual drives, each of which would hold another instance of a FAT12 file system, not some foreign file system.

2. The Appendix that you cited simply shows that Ultrix supported partitioning of a physical drive into more than one virtual drive.
You seem to think that this disproves by counterexample my "argument". It doesn't since I didn't claim in any of my posts that once couldn't do such partitioning.
In fact, since I said that it could, but instead pointed to the fact that each such partition can be thought of/treated as a "disk", showing that partitioning can be done simply shows that I am right about that one part.

3. You seem intent on playing word games with "drive"/"disk" and "partition" when it suits you.
That "works" on Unix I supposed where there are separate entries for drives and partitions in the /dev directory, but for the rest of us with Windows on our desktops, a partition is a drive and has a drive letter assigned to it just alike a real live different physical disk has.
And oddly enough, it's one drive/one file system for us.

4. Since you apparently are intent on not reading both parts of the statement I tried together with the word "and", you "understandably" failed to realize what would actually show that I'm wrong, which is that granule list pointed at by an Inode in some way contains enough information to allow a part of a file that's on a different disk entirely to be located.
The best you can do with partitioning is to say, "well if the granule address is indeed a record address, then that address can reference a different partition on the same physical disk" which unfortunately for you doesn't get you into the same ballpark as spreading a file across any "fixed" disk on an 1100/2200.

5. You mentioned RAID for some reason.
Since I don't know what you were trying to get at, I'll just point out that as an expression it showed up sometime in the late 1980s while the first use of RAID (mirroring=RAID 1) occurred sometime in the early 1980s on the 1100.
(The first 8470s had a nasty habit head crashing and so the "UD" key was cooked up so that the contents of a disk could be moved to a good disk before the head(s) finally gave out.)
Some form of RAID was used on other machines before (Tandem?) and I'm pretty sure that IBM patented at least some form of RAID even before the 1980s.
Are you trying to claim that RAID sprang forth from Unix before anyone else thought of it as well???

Re: Working on a series of mini-articles about OS 2200

<qU9aL.23346$1449.20068@fx14.iad>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=257&group=comp.sys.unisys#257

 copy link   Newsgroups: comp.sys.unisys
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx14.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: sco...@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Working on a series of mini-articles about OS 2200
Newsgroups: comp.sys.unisys
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com> <tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com> <th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com> <b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com> <jq5jsuFcuu4U1@mid.individual.net> <8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com> <TbQ9L.29753$BRy2.6016@fx48.iad> <c96bb391-030a-41b2-9472-cee3d2bbc8c8n@googlegroups.com>
Lines: 63
Message-ID: <qU9aL.23346$1449.20068@fx14.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Mon, 07 Nov 2022 15:56:06 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Mon, 07 Nov 2022 15:56:06 GMT
X-Received-Bytes: 3969
 by: Scott Lurndal - Mon, 7 Nov 2022 15:56 UTC

Lewis Cole <l_cole@juno.com> writes:
>>On Wednesday, October 5, 2022 at 7:50:08 AM UTC-7, Bill Gunshannon wrote:
>>> On 10/4/22 21:58, Lewis Cole wrote:=20
>>>>>
>>>>> I assume that you are probably aware of this,=20
>>>>> but just in case, what I'm specifically referring=20
>>>>> to is the fact that due to their evolutionary history,=20
>>>>> many/most? folks used to micros/minis often=20
>>>>> times assume that there's a one-to-one=20
>>>>> relationship between disks and file systems.
>>>>
>>>> Why on earth would you think that?
>>>
>>>You mean, aside from the fact that what I said is true?
>>
>> Given that mainframe systems had no such constraints
>> in the periods before, during and after the mini
>> era, and most people using minicomputers in those
>> days were familiar with one or more mainframe
>> families, I'm not sure why you think that is true.
>
>I think it's true because the "givens" you think applied at the time, didn't.

Well, I was "messing" with mini's (HP2k, PDP-8, in particular) in the middle
of the 1970s. They had disks, and both hosts were basically obsolete at that time.
I was also messing with HP-3000's during the same timeframe, which had many disks,
and I spent 14 years at Burroughs writing mainframe operating systems (which
supported multivolume filesystems since the 1960s).

>Eventually, disk prices did drop and you could have more than one hard
>drive in your PC, but as I indicated before, the very structure of FAT
>rules out the possibility of files that span more than one disk.

DOS was never the only operating system, nor was FAT the only filesystem
on disks for personal computers even in the early days.

>Yes, many OSs use a list of allocated granules to keep track of the
>parts of a file, but for a single disk system, you can also use bit
>maps to keep track of what records are allocated and to who[m].

In generally, you can divide filesystems into two fundamental types:
- extent-based allocators
- fixed-block-size allocators.

Both have their advantages and both have their disavantages, based on
workload.

In Unix filesystems, the 'inode' encapsulated filesystem metadata, including
addresses of the sectors (or groups of sectors) containing file data. This
should not be confused with a 'directory entry', because it was not such.

This was no different than the Burroughs filesystems other than the terminology
changed; there the 'inode' was called a 'file header'. Both contained the
same metadata, and in both cases, the 'directory' was just a file of tuples
<filename, metadata-pointer>.

The Sperry/Univac systems were similar to the Burroughs systems in that the
device addresses in the file metadata included a device identifier and a
device relative sector address.

The Univac filesystem structure and access methods however, are quite different from
the Burroughs, Unix or microsoft OS methods.

Re: Working on a series of mini-articles about OS 2200

<202e6883-3327-40d4-bad1-bfdf9aa8ddc8n@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=260&group=comp.sys.unisys#260

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:a05:620a:6086:b0:6fa:567b:5c0f with SMTP id dx6-20020a05620a608600b006fa567b5c0fmr22494092qkb.192.1667848024524;
Mon, 07 Nov 2022 11:07:04 -0800 (PST)
X-Received: by 2002:a05:6870:e0d2:b0:13c:d5bd:6f6f with SMTP id
a18-20020a056870e0d200b0013cd5bd6f6fmr27940232oab.163.1667848024269; Mon, 07
Nov 2022 11:07:04 -0800 (PST)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Mon, 7 Nov 2022 11:07:04 -0800 (PST)
In-Reply-To: <qU9aL.23346$1449.20068@fx14.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=174.31.251.97; posting-account=DycLBQoAAACVeYHALMkZoo5C926pUXDC
NNTP-Posting-Host: 174.31.251.97
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<tgvq9p$9m3$1@dont-email.me> <707cf1a3-48ef-407e-b721-c994da0f14ecn@googlegroups.com>
<th0lva$9m3$3@dont-email.me> <2b35c000-40c8-4dc6-956a-ab337c21b57cn@googlegroups.com>
<b8d6c20d-db5b-476a-94ad-2832c32145den@googlegroups.com> <jq5jsuFcuu4U1@mid.individual.net>
<8b8b6ede-9d48-4524-9b1c-a5e517059e99n@googlegroups.com> <TbQ9L.29753$BRy2.6016@fx48.iad>
<c96bb391-030a-41b2-9472-cee3d2bbc8c8n@googlegroups.com> <qU9aL.23346$1449.20068@fx14.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <202e6883-3327-40d4-bad1-bfdf9aa8ddc8n@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: l_c...@juno.com (Lewis Cole)
Injection-Date: Mon, 07 Nov 2022 19:07:04 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 9374
 by: Lewis Cole - Mon, 7 Nov 2022 19:07 UTC

On Monday, November 7, 2022 at 7:56:08 AM UTC-8, Scott Lurndal wrote:
> Lewis Cole <l_c...@juno.com> writes:
> >>On Wednesday, October 5, 2022 at 7:50:08 AM UTC-7, Bill Gunshannon wrote:
> >>> On 10/4/22 21:58, Lewis Cole wrote:=20
< snip >
>>>>>
>>>>> Why on earth would you think that?
>>>>
>>>You mean, aside from the fact that what I said is true?
>>>
>>> Given that mainframe systems had no such constraints
>>> in the periods before, during and after the mini
>>> era, and most people using minicomputers in those
>>> days were familiar with one or more mainframe
>>> families, I'm not sure why you think that is true.
>>
>>I think it's true because the "givens" you think applied at the time, didn't.
>
> Well, I was "messing" with mini's (HP2k, PDP-8, in particular) in the middle
> of the 1970s. They had disks, and both hosts were basically obsolete at that time.
> I was also messing with HP-3000's during the same timeframe, which had many disks,
> and I spent 14 years at Burroughs writing mainframe operating systems (which
> supported multivolume filesystems since the 1960s).

As I said with Mr. Gunshannon, that's nice.

>> Eventually, disk prices did drop and you could have more than one hard
>> drive in your PC, but as I indicated before, the very structure of FAT
>> rules out the possibility of files that span more than one disk.
>
> DOS was never the only operating system, nor was FAT the only filesystem
> on disks for personal computers even in the early days.

No, it wasn't. Nor did I say it did. But let's not try to dismiss it as if it weren't influential either and therefore relevant, shall we?

>> Yes, many OSs use a list of allocated granules to keep track of the
>> parts of a file, but for a single disk system, you can also use bit
>> maps to keep track of what records are allocated and to who[m].
>
> In generally, you can divide filesystems into two fundamental types:
> - extent-based allocators
> - fixed-block-size allocators.>>>
>
> Both have their advantages and both have their disavantages, based on
> workload.
>
> In Unix filesystems, the 'inode' encapsulated filesystem metadata, including
> addresses of the sectors (or groups of sectors) containing file data. This
> should not be confused with a 'directory entry', because it was not such.
>
> This was no different than the Burroughs filesystems other than the terminology
> changed; there the 'inode' was called a 'file header'. Both contained the
> same metadata, and in both cases, the 'directory' was just a file of tuples
> <filename, metadata-pointer>.
>
> The Sperry/Univac systems were similar to the Burroughs systems in that the
> device addresses in the file metadata included a device identifier and a
> device relative sector address.
>
> The Univac filesystem structure and access methods however, are quite different
> from the Burroughs, Unix or microsoft OS methods.

Thank you for the historical background.
Seriously. I actually do appreciate it.

But (yes, there's a "but") now, please go back and re-read what I originally wrote. Why? Because in it, you'll hopefully note that I wrote "many/most?" people.
That wasn't a typo.

With all due respect to you (and even Mr. Gunshannon), I would submit that you are *NOT* "many/most?" people.
Instead, "many/most?" people are those people who are more represented by those who view you as their unpaid go-to guy when they are looking for "tech support" for their PCs (where again, by "PC" I mean "Personal Computer" rather than a particular brand or type).
What is their view of what constitutes a disk and whether or not it contains one and only one file system?

Rather than trying to argue with me over what constitutes a disk versus a partition, or whether or not a file system keeps track of things with bit maps, record numbers, or tuples or whether or not an inode is the same as file item, may I humbly suggest that you just ask them.
I suspect that you already have enough personal experience with them (as I do with mine) that you don't really even need to bother, but if you want to re-affirm what you believe, then I am fairly certain that you can do so fairly quickly and without much effort.

I suggest that you start by asking them if they have any idea what's on their "C:" drive.
I suspect that you'll know right away from their answer whether or not they have a Windows based system because they will know what you are talking about even if they say something like, "How the hell should I know"?
I suspect that you'll get an answer well in excess of 50% if the people you ask are fairly representative of "many/most?" people because Windows is still the dominant OS in the desktop field despite its decline relative to other mostly Unix based or Unix inspired OSs.
(According to a quick Wikipedia search as I just did, their market share is still greater than 75%.)

I then suggest that you ask them if they have a "D:" drive.
Again, I suspect you'll know almost right away from their answer whether or not they think of any extra partitions on their "C:" drive are "just a partition of a real physical drive" or as a separate "drive" in its own right.

Finally, I would suggest that you ask them if they can look for/show you a file -- any file -- on "C:" and then a file -- any file -- any other "drives" they might have.
Again, I suspect that you'll know almost right away whether they think that there's one file system on each "drive" or not by how they do the search.
(For example, if they enter "C:" before "DIR" and "D:" before "DIR" from a command terminal, then as far as they are concerned, each drive contains a separate file system.)

If you do this, I think you will be faced with a dilemma.
You will know about the gory details that lies below the surface when it comes to computers, not just PCs, and you will therefore know that a disk partition is *NOT* really a separate disk, but you will be faced with empirical evidence that shows that as far as "many/most?" people, a "virtual disk" is still a "disk", and that, one "disk" equals one file system and vice versa.
You will know about all the great history you gained from personal experience from before commercial PCs even hit the fan, and yet "many/most?" people don't, in no small part because they didn't have the exposure you did and instead were driven by cost of putting together their own small systems.

I'm not sure what you'll do at that point (if you reach it), but I'd like to think that maybe, just maybe, you'll come to realize that my comments were not the ranting of some completely clueless idiot who doesn't know shit about anything who just happened to wander into this group.
Maybe, just maybe there's a chance you'll realize that there's a chance that I too lived through those times as well, and that thanks to be lucky enough to work 15 years in the group responsible for the care and feeding of Exec8/OS1100/OS2200, I too might just also know a bit about what's under the surface.
Then maybe, just maybe, you might understand why I am not particularly appreciative of responses that do not seem to be based a careful reading of what I actually wrote, and even worse, seem to be used as just an excuse for posting a "correction" that in effect lets the poster say, "Well Unix can do that too".

If you want to talk about file systems, great.
I really would welcome/appreciate it.
But if you want to talk/argue about what I wrote, can we please stick to what I wrote?

Re: Working on a series of mini-articles about OS 2200

<8d8f25fb-231b-4c02-baee-bc9dec8e282dn@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=337&group=comp.sys.unisys#337

 copy link   Newsgroups: comp.sys.unisys
X-Received: by 2002:ad4:55ea:0:b0:62f:eecb:3d93 with SMTP id bu10-20020ad455ea000000b0062feecb3d93mr1048492qvb.5.1687042990780;
Sat, 17 Jun 2023 16:03:10 -0700 (PDT)
X-Received: by 2002:a81:e709:0:b0:568:f589:2b4e with SMTP id
x9-20020a81e709000000b00568f5892b4emr2619952ywl.0.1687042990478; Sat, 17 Jun
2023 16:03:10 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.sys.unisys
Date: Sat, 17 Jun 2023 16:03:10 -0700 (PDT)
In-Reply-To: <o7c7jh9hhgivh7tlrgf3tvsdtg2e5bflcq@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=24.9.238.113; posting-account=mEuitgoAAADY9v63PvAUFdA9nsy_ToEE
NNTP-Posting-Host: 24.9.238.113
References: <6cc88020-5c52-4d0d-9846-936211046399n@googlegroups.com>
<en0tihtn3n50d2dqkrcrkjufa2cr0msv3d@4ax.com> <1f546791-a22b-4b3d-980c-4a34766dd041n@googlegroups.com>
<jp9ek6Fr95U1@mid.individual.net> <o7c7jh9hhgivh7tlrgf3tvsdtg2e5bflcq@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8d8f25fb-231b-4c02-baee-bc9dec8e282dn@googlegroups.com>
Subject: Re: Working on a series of mini-articles about OS 2200
From: kurtadun...@gmail.com (Kurt Duncan)
Injection-Date: Sat, 17 Jun 2023 23:03:10 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 1707
 by: Kurt Duncan - Sat, 17 Jun 2023 23:03 UTC

On Tuesday, September 27, 2022 at 8:26:54 PM UTC-6, David W Schroth wrote:
> IMO, the major difference (from a user code standpoint) between an
> 1100 and a 2200 is that marketing thought 2200 sounded twice as sexy
> as 1100. Mileage almost certainly varies.

Okay, this is the most humorous thing I've read all day. Kudos!

Pages:123
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor