RT11 sysgen and disk partitions

Jerome H. Fine jhfinexgs2 at compsys.to
Sat Mar 12 20:35:54 CST 2005

 >Megan wrote:

>Although these will work, I have found that for purposes of simplicity,
>and maximizing the ability to boot a given disk on multiple 
>configurations, it is best to use the lower DU unit numbers for physical
>drives, and the higher ones for logical mappings.
>So, for example, I would have
Jerome Fine replies:

The above works fine with an RD53.  If you add a second
RD53. then add:
at which point the RX50 floppy is DU2: and DU3:

I might add that a hardware boot on an MSCP drive can
be done ONLY (well there are a few exceptions that
very experienced RT-11 users have fun with) when:
which is why Megan and I suggest that the lower DU
unit numbers be used for the same UNIT numbers with
a PART=0.

>When you use the 64-unit version of the driver, you're on your own...:-)
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.  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:
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.

If anyone else has any comments, they would be
VERY appreciated!!!!!!!!!!!!!!!!!!!!!

For 64 units, I run 3 Hitachi ESDI  DK515-78 hard disk
drives as:
SET  D00: -> D23:  UNIT=0, PART=00 to 19
SET  D30: -> D53:  UNIT=1, PART=24 to 43
SET  D60: -> D77:  UNIT=2, PART=48 to 63
SET  D54: -> D57:  UNIT=2, PART=44 to 47
ASSIGN  D80:  D54:
ASSIGN  D81:  D55:
ASSIGN  D82:  D56:
ASSIGN  D83:  D57:
Sometimes I also use a 4th ESDI as temporary
scratch in which case:
SET  D24: -> D27:  UNIT=3, PART=20 to 23
ASSIGN  D90:  D24:
ASSIGN  D91:  D25:
ASSIGN  D92:  D26:
ASSIGN  D93:  D27:

NOTE that within the SET command values are in
DECIMAL while the command SHOW DEVICE : DU displays
the partition numbers in OCTAL.  The device names
may seem the be in OCTAL, but are always RAD50.
THUS, the D8n: and D9n: can be used, but must
be assigned to the actual device names.

ALSO, while the standard distributed DEC code
for DU.MAC and UM.MAC does not include a boot
table EXCEPT for DU0: -> DU7:, I modified the
boot code to allow all 64 devices to be software
booted via DUP after RT-11 is running.  Thus I
must first do a hardware boot using DU0:, then
I can boot any of the other RT-11 partitions
which have a bootable set of files.  I realize
that not many RT-11 users even have this large
a real hard disk drive, but if you run SIMH, then
container files up to 64 RT-11 partitions are
possible with most Windows and probably Linux
as well.  However, it is legal for hobby users
of RT-11 to run only up to V05.03 of RT-11 under
SIMH.  And most hobby users will find that V05.03
of RT-11 is sufficient for almost all their needs.

Versus the fact that later versions of RT-11
are legally available only with a legal license
from DEC (prior to about 1994) or now Mentec at
about $ US 900 for a Qbus license and $ US 1600
for a binary RT-11 distribution - assuming that
Mentec will respond to any of your requests for
information.  Lately, they do not respond and I
assume that at least the RT-11 DOC set for V05.06
is "out of print".

Under the commercial version of E11,
it is possible to concatenate container files
or even use raw SCSI hard drives of any size.

Finally, since I use a Sigma RQD11-EC  ESDI
controller, I am able to use a passive front
panel which allows me to WRITE  PROTECT UNITS
0, 1 and 2.  I run that way 99.9% of the time
and remove the WRITE  PROTECT only when I have
finished testing a new file which I want to save
on the hard drive.  I have lost a few files this
way when I crashed during testing, but better that
than not being able to boot the system the next
day until I return to a very old backup.  Usually
I can arrange to save the file (to be tested) on
the hard drive under a different name while the VM:
disk has the test file with the real name and I
am stepping through with a DEBUG program active.
After a few hours or days of testing, the original
file on the hard drive is replaced with the new
temporary file (very easy if the temporary file
is the same size - just overwrite using DUP)
and delete the temporary file.  After final testing,
copy the new file to the backup partition and
BINCOM everything again.

If you are wondering how I use so many partitions,
99% of the time UNITs 1 and 2 are the backups for
UNIT 0 (and are rarely powered up).  This means that
I can use BINCOM to check that each of corresponding
partitions is identical.  It also means that I can:
BOOT  D32:
instead of D02: when I want to make changes to D02:
which I am not positive can be done while D02: is the
system device.  After the changes, I again BOOT D02:
and test.  If everything checks out, I can:
to make a backup while I still have D62: in reserve
for a bit longer.

If you have any more questions, please ask.

Sincerely yours,

Jerome Fine
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 cctech mailing list