RT11 sysgen and disk partitions

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 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: 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 needed. 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 details? 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? 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.