RT11 sysgen and disk partitions

Jerome Fine replies: The above works fine with an RD53. If you add a second RD53. then add: SET DU6: UNIT=1 PART=1 SET DU7: UNIT=1 PART=2 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: SET DUn: UNIT=n PART=0 which is why Megan and I suggest that the lower DU unit numbers be used for the same UNIT numbers with a PART=0. 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 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: COPY/DEVICE D02: D32: 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.