Groups | Search | Server Info | Login | Register

Groups > comp.sys.unisys > #2559

Re: OS2200 MFD question

Show all headers | View raw

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

--

Back to comp.sys.unisys | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

OS2200 MFD question Stephen Boyd <sboydlns@gmail.com> - 2025-01-11 09:29 -0500
  Re: OS2200 MFD question l_cole@juno.com (lewiscole) - 2025-01-11 20:06 +0000
    Re: OS2200 MFD question Stephen Boyd <sboydlns@gmail.com> - 2025-01-12 10:22 -0500
      Re: OS2200 MFD question l_cole@juno.com (lewiscole) - 2025-01-12 18:49 +0000
        Re: OS2200 MFD question R Daneel Olivaw <Danny@hyperspace.vogon.gov> - 2025-01-13 08:41 +0100
        Re: OS2200 MFD question Stephen Boyd <sboydlns@gmail.com> - 2025-01-13 10:02 -0500
          Re: OS2200 MFD question l_cole@juno.com (lewiscole) - 2025-01-15 02:04 +0000
            Re: OS2200 MFD question David W Schroth <davidschroth@harrietmanor.com> - 2025-01-31 22:34 -0600
              Re: OS2200 MFD question l_cole@juno.com (lewiscole) - 2025-02-02 20:50 +0000
                Re: OS2200 MFD question David W Schroth <davidschroth@harrietmanor.com> - 2025-02-02 20:23 -0600
          Re: OS2200 MFD question David W Schroth <davidschroth@harrietmanor.com> - 2025-01-31 22:30 -0600
            Re: OS2200 MFD question Stephen Boyd <sboydlns@gmail.com> - 2025-02-01 10:21 -0500

csiph-web