Setting aside the issue of whether or not you are legally allowed to
look at the internals of the disk file image (I thought disassembly was
one of the things forbidden in the license), then I would suggest that
you take a look for an old IRM (Installation Reference Manual) as I
think the internal joys of the Exec8/OS1100/OS2200 file system were
documented there.
Unfortunately, Univac/Sperry Univac/Sperry/Unisys (USUSU) has had a long standing habit of making such old manuals disappear and so I suspect
that it will be virtually impossible for you to find such a manual.

The best alternative that I can think of is an old Exec Data Structures
manual and as luck would have it, there's a copy of one laying around in BitSavers in their </pdf/univac/1100/exec > directory.
See chapter 7 on the Master File Directory (MFD) in RUP-8731.

Good luck with your spelunking.

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Boyd wrote:

lewiscole wrote:

Setting aside the issue of whether or not you are legally allowed to
look at the internals of the disk file image (I thought disassembly was
one of the things forbidden in the license),

Not sure how this differs from using IOW$ to explore the file system
from within OS2200 itself. The same info is being looked at one way or another. This way is just easier since I don't have to mess with MASM.

Well, I could be wrong, but I suspect that the Exec won't allow a user
to arbitrarily look at anything on disk using a IOW$ or any other I/O
related ER.

Also, like I said, this is strictly an academic exercise. It's not like
I'm trying to reverse engineer Exec. That would be a career not a hobby
and I'm way too old for that.

Regardless of the reason, I'm pointing out that you may be violating the
terms of your licensing agreement which COULD (at the very least) lead
the Company to not renewing your PS2200 license if they wanted to.
That may not be a problem for you, but if you're interested in continue
to play around with it, it's a risk you should be aware of.

Unfortunately, Univac/Sperry Univac/Sperry/Unisys (USUSU) has had a long
standing habit of making such old manuals disappear and so I suspect
that it will be virtually impossible for you to find such a manual.

Very true. I have an old version of the Data Structures manual and there
is a lot of stuff in there that isn't in the new one. There are problems
with even the old manual though. First, it assumes a level of knowledge
of Exec internals that I simply don't have. [...]

Unfortunately, I suspect there's not really all that much you can do
about that.
The Exec is a proprietary product and I doubt that the Company is going
to release its source, and the Company clearly doesn't want users to
find out how things work internally on their own.
I suspect this is the reason why they didn't include @FLIT in PS2200.

I'm sure that there are people who could answer the questions you have
who work for the Company, as well as plenty of people outside of the
Company (which is to say people who are retired or dead) who can answer
the question, but they might feel restrained by the confidentiality
clauses of their employment agreement.

[...] Second, it is out of date. The structures described in the manual
don't always match the latest version. [...]

Well, I could be wrong, but I suspect that the Exec's file system isn't something that is going to change much without a very good reason.

But a more important factor that I think you need to keep in mind is
that what you're looking at (a disk "image") might not actually be a
disk "image".
The Company could have tweaked to make things "easier" to implement
PS2200 knowing that it was Good Enough for the purposes of providing a
platform for users to get a taste of the OS2200 experience via PS2200.

[...] Third, it is just plain vague in places. Which was always a
problem
with Univac docs, 1100 or otherwise.

I don't disagree.

I even tried looking at the source for an old version of the MFD
processor. But, like the manual, it is out of date and some of the code simply doesn't match the modern reality.

I assume this means that you've already looked for an old version of the
MFD processor itself rather than just its source.
Just in case, however, here is the URL of a Web site that contains
1100/2200 executables, including MFD processor (10R8C) which was last
updated in 2023, that might be of interest:

< http://cgibin.rcn.com/leistlc/cgi-bin/indexbld.pl >

But I can't help shake the feeling that it might be possible to resort
this processor to answer your question if you were to provide more
information about your question.

As the IRM (and I think the Exec Data Structures) chapter mentioned, the Directory Allocation Sector (DAS) keeps track of the (28-word) sector allocation of a (1792-word) directory track.
The DAS contains a bunch of 3-word entries, one for each sector it's
keeping track of (no pun intended), and there are more such entries that
their are sectors in a track.
So the DAS in the first sector of the first directory track actually
keeps track of sectors in other directory tracks and so you don't see
(or at least didn't used to) another DAS at the start of a directory
track until you've exhausted all such descriptors ... which just happens
to be (or used to be) every *NINE* (9) directory tracks IIRC.

It could be a coincidence, but I can't help but feel that there's a
possible correlation between your having to subtract 18 (i.e. 2 * 9) in
order to get your addresses to work out.
It's just a thought.

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

lewiscole wrote:

Stephen Boyd wrote:

lewiscole wrote:

snip

Not sure how this differs from using IOW$ to explore the file system
from within OS2200 itself. The same info is being looked at one way or
another. This way is just easier since I don't have to mess with MASM.

Well, I could be wrong, but I suspect that the Exec won't allow a user
to arbitrarily look at anything on disk using a IOW$ or any other I/O
related ER.

All IO ERs (including the TIP ones) require a filename, and the
addresses you use are file-relative and not device relative.
I have vague memories that someone managed to access TSS$FILE in real
time (not looking at the tape backup) by placing it under TIP. The Exec
fix for that one was to disallow SYS$ as a qualifier for TIP files.
That indicates clearly that there was no general way of accessing data.
DPREP and similar tools required the device to be in RV status.

snip

--

And I've gone from being "retired" to "long retired".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Boyd wrote:

lewiscole wrote:
It could be a coincidence, but I can't help but feel that there's a
possible correlation between your having to subtract 18 (i.e. 2 * 9) in
order to get your addresses to work out.
It's just a thought.

I've wondered about the same thing myself but have been unable to come
up with any logical reason for it.

Okay, I'm just a poor dumb former bootstrap programmer (not a File
Control expert by any means), but long, long ago, I was interested in
how to go about find bits and pieces of a file on a disk (just like
other Bootstrap programmers have at one time or another) while playing
with the idea of putting the Exec in a file.
(And yes, this was a long time ago, back in the 2200/900 days before
MFA, et. al., actually did manage to put the Exec in a file.)
So, I'm not entirely ignorant about the joys of dealing with directory
tracks as they used to work, but it's clear to me that there's not
enough information here to make much sense of what's going on (at least
based on what I know).

Okay, let's start from the beginning again, shall we?

A directory track is a 1792-word long unit of storage made up of 28-word sectors where a word is 36-bits long.
A DAS relative track number is the number of the directory track
starting at zero (0), so the first directory track is directory track 0,
the next directory track is directory track 1, and so on, up to a
maximum number of 4096 (AKA 010000) tracks per logical device (at least
in the Good Old Days).

To keep track of what sectors are in use within a directory track,
there's a Directory Allocation Sector (DAS) which internally contains
enough descriptors to describe the allocation of sectors in up to 9
directory tracks.
But there's also a pointer at the end of the each DAS, in the form of a
DAS relative track number, which points to the next directory track that contains a DAS in it.
The directory tracks aren't so much a table as a linked list so I'm
somewhat confused by your reference to indexing into a table of DAS
entries.

To find the sector of the first directory track (assuming that there's
no Exec available to ask for help), one presumably would read the disk's
label (VOL1) which is to say read the third record (counting from one
[1]).
The sector address of the first directory track is kept in the label.

So when you talk about finding a DAS, how did you find it?
How do you know it's actually a DAS?
When you say that you have to "subtract 18 from the relative track
number", where did you get that track number to start with?
How do you know that the track number you got after subtracting 18 from
it was somehow "correct"?
And are all relative track numbers off by the same amount or does it
change as you make your way through the directory track chain?

And just to be thorough ...

What does the label say is the size of a sector in 36-bit words? (4,,H2)
What does the label say the size of track is in sectors? (4,,H1)
Where is the first directory track (in sectors?)? (3,,W)
And is the disk "fixed" (so that it has a non-zero LDAT index) or
"removable" (so that it has a zero LDAT index)?

Enquiring minds want to know ....

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 15 Jan 2025 02:04:07 +0000, l_cole@juno.com (lewiscole) wrote:

Stephen Boyd wrote:

lewiscole wrote:
It could be a coincidence, but I can't help but feel that there's a
possible correlation between your having to subtract 18 (i.e. 2 * 9) in
order to get your addresses to work out.
It's just a thought.

I've wondered about the same thing myself but have been unable to come
up with any logical reason for it.

Okay, I'm just a poor dumb former bootstrap programmer (not a File
Control expert by any means), but long, long ago, I was interested in
how to go about find bits and pieces of a file on a disk (just like
other Bootstrap programmers have at one time or another) while playing
with the idea of putting the Exec in a file.
(And yes, this was a long time ago, back in the 2200/900 days before
MFA, et. al., actually did manage to put the Exec in a file.)

While MFA is a Mike, they didn't put the Exec in a file. That was
done by Mikey and CWeed.

So, I'm not entirely ignorant about the joys of dealing with directory
tracks as they used to work, but it's clear to me that there's not
enough information here to make much sense of what's going on (at least
based on what I know).

Okay, let's start from the beginning again, shall we?

A directory track is a 1792-word long unit of storage made up of 28-word >sectors where a word is 36-bits long.
A DAS relative track number is the number of the directory track
starting at zero (0), so the first directory track is directory track 0,
the next directory track is directory track 1, and so on, up to a
maximum number of 4096 (AKA 010000) tracks per logical device (at least
in the Good Old Days).

To keep track of what sectors are in use within a directory track,
there's a Directory Allocation Sector (DAS) which internally contains
enough descriptors to describe the allocation of sectors in up to 9
directory tracks.
But there's also a pointer at the end of the each DAS, in the form of a
DAS relative track number, which points to the next directory track that >contains a DAS in it.
The directory tracks aren't so much a table as a linked list so I'm
somewhat confused by your reference to indexing into a table of DAS
entries.

To find the sector of the first directory track (assuming that there's
no Exec available to ask for help), one presumably would read the disk's >label (VOL1) which is to say read the third record (counting from one
[1]).
The sector address of the first directory track is kept in the label.

So when you talk about finding a DAS, how did you find it?
How do you know it's actually a DAS?
When you say that you have to "subtract 18 from the relative track
number", where did you get that track number to start with?
How do you know that the track number you got after subtracting 18 from
it was somehow "correct"?
And are all relative track numbers off by the same amount or does it
change as you make your way through the directory track chain?

And just to be thorough ...

What does the label say is the size of a sector in 36-bit words? (4,,H2)
What does the label say the size of track is in sectors? (4,,H1)
Where is the first directory track (in sectors?)? (3,,W)
And is the disk "fixed" (so that it has a non-zero LDAT index) or
"removable" (so that it has a zero LDAT index)?

Enquiring minds want to know ....

I know better than to try and answer questions that are better
addressed by Linda B.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 13 Jan 2025 10:02:27 -0500, Stephen Boyd <sboydlns@gmail.com>
wrote:

On 2025-01-12 1:49 p.m., lewiscole wrote:

Well, I could be wrong, but I suspect that the Exec won't allow a user
to arbitrarily look at anything on disk using a IOW$ or any other I/O
related ER.

Tou're not wrong, Lewis.

From looking at an admittedly old version of MFD, this is exactly how
it reads the MFD. It uses ER IOW$, reads sector 0 to get the pointer to
the MFD and starts to read certain parts of the MFD into a temporary file.

While it has ben literally decades since I looked at MFD, I'm quite
sure it's not doing what you describe. It is almost certainly reading
a snapshot of the MFD that was placed in a file specified by MFD.
As the MFD (not the program) is effectively contained in a temporary
file assigned by the Exec, there is no way for a user to read the MFD
directly.

<snip>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David W. Schroth wrote:

Lewis Cole wrote:
Okay, I'm just a poor dumb former bootstrap programmer (not a File
Control expert by any means), but long, long ago, I was interested in
how to go about find bits and pieces of a file on a disk (just like
other Bootstrap programmers have at one time or another) while playing
with the idea of putting the Exec in a file.
(And yes, this was a long time ago, back in the 2200/900 days before
MFA, et. al., actually did manage to put the Exec in a file.)

While MFA is a Mike, they didn't put the Exec in a file. That was
done by Mikey and CWeed.

Thank you for the correction.

Having said that, let me dig myself a deeper hole by waving my arms at
my understanding/recollection of the events surrounding the
implementation of the Exec in a file effort.
Feel free to elaborate upon and/or make corrects to my understandings/recollections.

It is my understanding/recollection that MFA argued for Exec in a file
long before it was actually implemented, even before the Mercury adapt
effort was started, but that he ignored ... just like a certain other individual who shall remain nameless who tried to warn Management
relatively early on during the Mercury adapt effort that increasing the
size of the DRS area on the system disk wasn't going over well with
customers.
Presumably because Management was fixated on getting Mercury out the
door, the size of the DRS area used during development was simply double
in old size and we all went about our business as if the matter were
settled.

My understanding/recollection is that once Management finally
realized/accepted that increasing the size of the DRS would violate a
promise that the size of the DRS area wouldn't increase without two (2)
SB releases advanced warning (something that would never occur because
the Company didn't plan that far ahead), then things suddenly hit the
fan and an effort was made to whittle the Exec to fit with the currently
DRS area size known to customers shortly before Mercury was released.
The bulk of the work to get there from here being done by the individual
who shall remain nameless as well as Mikey and CWEED.
(It is my recollection that when the individual who shall remain
nameless was asked in a DDRB meeting what caused Management suddenly
reconsider its position WRT the DRS area's size, he responded with, "Kaopectate?" ... a response that I hope is still immortalized in the
DDRB minutes somewhere.)

However, it is my understanding/recollection that while it should have
been obvious that a longer term solution was needed/required at that
point, Management still wanted to drag their feet, and that it took
screaming by various individuals, most memorably for me MFA, for
Management to get off their dead penguin butts and do something.
I am aware of MFA because I still talked to him from time to time about Bootstrap stuff, but it wouldn't surprise me in the slightest if there
was a lot of screaming from others (like the individual who shall remain nameless) that was also needed to push the dead elephant forward a
millimeter or two.
That is why I credited MFA with getting the Exec in a file even though
Mikey and CWEED (and I suspect the individual who shall remain nameless) actually did the heavy lifting to get there from here.

I don't think that MFA contributed *ANYTHING* in terms of design or code
to the Exec in a file effort, but I suspect that without his (and
others) screaming, the Exec in a file effort would have been delayed
until someone finally recognized that there was probably no chance to
put in another Exec feature without running into the DRS size
limitation.
While that shouldn't have taken too long, I've always been amazed at Management's ability to procrastinated.

Nevertheless, I can well understand how my comment regarding MFA could
be seen as a slight to those who actually made Exec in a file a reality.
If CWEED were still alive, I probably be apologizing to her right now.
Ditto Mikey if I knew how to get a hold of him.
Please pass along my apologies to the individual who shall remain
nameless for neglecting to mention is work.

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2 Feb 2025 20:50:52 +0000, l_cole@juno.com (lewiscole) wrote:

David W. Schroth wrote:

Lewis Cole wrote:
Okay, I'm just a poor dumb former bootstrap programmer (not a File
Control expert by any means), but long, long ago, I was interested in
how to go about find bits and pieces of a file on a disk (just like
other Bootstrap programmers have at one time or another) while playing
with the idea of putting the Exec in a file.
(And yes, this was a long time ago, back in the 2200/900 days before
MFA, et. al., actually did manage to put the Exec in a file.)

While MFA is a Mike, they didn't put the Exec in a file. That was
done by Mikey and CWeed.

Thank you for the correction.

Having said that, let me dig myself a deeper hole by waving my arms at
my understanding/recollection of the events surrounding the
implementation of the Exec in a file effort.
Feel free to elaborate upon and/or make corrects to my >understandings/recollections.

<snip fascinating recollection>

It's no doubt a result of my advanced age, but I find myself unable to
attach a name to the nameless individual you refer to. I don't think
nameless individual is the engineer who came up with the timeless
State of the Art term, "lump descriptor", but I could be mistaken. I'm otherwise at a loss.

They were giants in them days, weren't they?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)