RT11 sysgen and disk partitions
Jerome H. Fine
jhfinexgs2 at compsys.to
Mon Mar 14 19:42:57 CST 2005
>>Megan, if you are reading this, might it be possible to expand the number
>>of units to 128 or even 256? I seem to see at least one bit that is not
>>being used and maybe even two bits.
>Depends... where are you talking about getting the two bits?
Jerome Fine replies:
I would use the same general area as the other 6 bits.
Looking around, one promising area is where the
job number is kept. The high order bit seems the
be unused - except that some code may depend
on it being zero at all times. It would likely
be easier to remove that dependency if the high
bit for the job number field is always zero. In
addition, since the job number is actually the
( job number * 2), i.e. the low order bit is
always zero, then it might also be reasonable
to add the extra code to bit clear both the high
order and low order bits at the same time when
the (job number * 2) is to be extracted.
I am not saying there is a simple trivial answer
(just as finding the second set of 3 bits was a
bit tricky as well), just that it seems possible.
I have not looked at other areas, but other areas
in the queue entry might be possible as well.
You do agree that it is the queue element
that is the difficulty?
Megan, do you have any other suggestions?
Assuming that I am correct and that the job
number field always has the high order and
low order bits as zero, is it at least possible
to work the way I have suggested?
>>I know that naming would be a problem - what about:
>>D00 -> D77:
>>for the 128 unit device drivers, then add 8 more
>>"hex" values to the last RAD50 character
>>D08: -> D0F:
>>D78: -> D7F:
>>for the 256 unit device drivers, then add 16 more
>>values to the last RAD50 character
>>D0G: -> D0V:
>>D7G: -> D7V:
>uggh... I'd not want to see go this route.
I did not say I liked the above suggestion, but do you have
any other possibilities? A pure "octal" yields only 64 names
which is the present solution. A pure "hex" WOULD yield
256 names, BUT the use of D00: -> DFF: would almost
certainly conflict with a few other 2 character device names
for the portion starting with DA0: -> DFF: Keeping the
middle RAD50 characters at 0 -> 7 should mean that no
conflict are possible with other 2 character device names
which are NOT allowed an octal character for the second
character, i.e. they must be one of the 26 alpha characters.
YES!! My suggestion is not pretty! Do you have one
that will work instead? Otherwise, perhaps at least
128 active RT-11 partitions would require only the
third device name to be a "hex" character and that
naming might be a bit more acceptable, i.e.
D00: -> D7F:
>>Since all the device names are RAD50, numbering is not really a problem.
>>By keeping the middle character as an octal value, the PNAME2 table
>>should still be happy.
>You've got me on that, I would have to look at the code to see why
>PNAME2 is an issue.
I tend to observe that the P2NAME table assume that the second
character is an octal character with the second character being
allowed, if it is zero, to default to the second in the 2 character
name in the PNAME table. If you can see any other possibility,
then the "uggh" names that are suggested above would not be
>As for the number of disks... I find 64 unwieldy... I'd hate to have
>to worry about 2 or 4 times that number on RT. I personally would
>rather see RT be able to natively handle 32-bit blocks numbers before
>it went this route...
I agree that 256 active RT-11 partitions which can
cover 8 GBites is more than unwieldy. Since 64 active
RT-11 partitions covers 2 GBytes, that should really
be more than enough.
HOWEVER, if you are really considering 32-bit block
numbers, that is a 512 GByte hard drive with 65536
RT-11 partitions. Should be a snap! The map entry
for each RT-11 partition is already 32 bits or 2 words
and uses (WASTES?) 16 bits for the unit number, but
allows only 8 bits (a byte) each for the port number and
RT-11 partition number. It should no be much of a
problem to swap the word for the unit number with the
byte for the partition number. Since RT-11 already
allows a 32-bit block number with ONLY 8 bits being
used from the 8 bit RT-11 partition number, ... Do you
get the point or do I need to spell out the extra
If you are answering, I would be extremely useful to
know if the first set of map entries in low memory
are essential as opposed to the second set of map
entries in high memory for the DUX.SYS device driver?
I am always disappointed that the 64 unit DUX.SYS
driver requires so much extra low memory for the
extra entries in the map entry table. I never could
quite understand why two tables are present, let alone
if the one in lower memory might be located somewhere
else and initialized into high memory during a LOAD or
.Fetch from a separate area in the device driver
outside of the portion which is copied to low memory?
Perhaps both enhancements could be done at the same time,
i.e. a 32-bit block number (16 bit partition number)
and the elimination of the map entry table from low memory?
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
More information about the cctalk