Jerome Fine replies: I am not sure if that is a benefit. Since my wife used to refer to the terminals for the PDP-11 systems (VT100, etc.) as the actual computers and could not even tell or understand what a hard disk drive was, there was obviously no meeting of the minds as far as work was concerned. BUT, when we met and were married (1957) BEFORE any real computers were widely known and understood, neither of us could even recognize a computer. I did not meet my first computer until about 1958 at an insurance company during a summer job. Probably a BRIEF outline of RT-11 file structures: (a) Home block in block 1 which contains non-essential Volume ID. (b) Directory segments of 2 blocks each (maximum of 31) start in block 6 (c) First 5 words of each directory segment: - Maximum number of directory segments - Next directory segment number (0 if end of chain) - Highest number of directory segments - Extra number of bytes for each directory entry - Start block number of directory entries for THIS directory segment (d) Standard file entries contain 7 words - Status word for the directory entry - 3 words of Radix50 (2 for file name, 1 for file type) - Number of blocks for this directory entry (0 to 65535 blocks) - Spare word used for a Tentative File Entry - word for Creation Date Agreed that version numbers were NOT possible ONLY File Creation Date (NO File Creation Time), let alone other file parameters Files could be PROTECTED against being DELETED; DEC NEVER had code to allow files to be RO (Read ONLY). The RT-11 command: [UN]PROTECT FOOBAR TSX-PLUS used the extra word as the (Creation Time/3) for each file in seconds/3 AFTER the file was made permanent. The extra bytes allowed for each file entry can be used to hold any data for each file such as Reference Date/Time, Modification Date/Time, Backup Date/Time. Some privately used systems have a modified USR which supports such enhancements. Starting with V05.00 in 1983, DEC supported the LD(X).SYS device drivers (Logical Disks) which allowed the RT-11 command: MOUNT LDn: DEV:FOOBAR.DSK after which LDn: could be used as a normal data disk, including having its own file directory. Thus, the single file directory for the primary physical hard disk drive (maximum size of 65536 blocks) can hold hundreds (normally only a dozen at most) of files which can also be used a logical devices (normally 8 at one time - can be extended to 64 at one time with a SYSGEN). These words were NOT supported by DEC. I understand that Dibol programs may have used them. Does your wife remember and if so, how were they used? YES - that aspect was a bit inconvenient, but not really difficult. The big problem was that a file could NOT be expanded in size unless the space immediately following the file was empty and had the number of blocks that were required. This almost never caused a problem. It was what RT-11 users expected, if they even thought about it at all. This was a problem at times, especially for those RT-11 users who did not pay attention to fragmentation in the disk space. NOT a problem at all if the users were aware of the problem. HOWEVER, for myself, I would ALWAYS make a backup copy of a hard disk before doing this since any failure would be catastrophic. But most RT-11 users ignored the possibility and on rare occasions lost many files. What did she do?????? By the time I worked on a PDP-11/34 in 1979, my wife and I had been married for 22 years and I was no longer the geek. Anyone who can type quickly does not have a problem. The commands are a bit stark, but no more difficult to remember than DCL (DEC COMMAND LANGUAGE). Why was the /S switch important in Dibol????? These days, the equivalent command for DUP stops the user from using the <CTRL/C> until the squeeze is finished. Actually, the <CTRL/C> (^C) is part of RT-11. The program can disable the feature when it requests to do so (providing the user does not crash RT-11 during a window when RT-11 is vulnerable due to an RT-11 bug). If the <CTRL/C> is enabled, then RT-11 kills execution. As stated above, DUP (which now performs the squeeze) has <CTRL/C> DISABLED while the squeeze is in progress. While I agree that early RT-11 systems had severe limitations, eventually RT-11 evolved into a rich operating system, especially when TSX-PLUS became available (actually a complete rewrite of the resident portion of the operating system by S&H) which supported multi-job and even multi-task usage. It was actually called a poor man's VMS since even security was very strong for the early 1980s. 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.

Maybe these guys can help ? http://dcf.sk/microweb/ I'm using this product and I'm happy with it. Stephane On Sat, 23 Oct 2004 18:50:16 -0500, Tom Hudson &lt;tomhudson(a)execpc.com&gt; wrote: ... ... -- Stephane Paris, France.

Jerome Fine replies: You are correct. RT-11 has NEVER had version numbers! If you can find those sources, it would be VERY appreciated. While the manner in which overlays were handled is not critical, it would certainly help reduce low memory. BUT, even more interesting would be the information about how non-contiguous files were handled. PIC is standard in the USR since it moves up and down in memory ALL the time. So I do not understand why you even mention the PIC aspect, let alone that something special needed to be done, although perhaps with overlays, something extra was required. On the other hand, device drivers which execute their overlays within the USR buffer do that all the time. The only aspect I see a being a REAL difficulty is that it is on hard copy. Any idea how many pages. At one point about 20 years ago, I started to write code for the USR which allowed a Reference Date and Modification Date for each file. Also useful was what VMS would call the LNL (Logical Name List) which I would call a Path Handler or something similar to the PATH NAME in DOS. A Pseudo Device handler (PHX.SYS) would be used with, for example: PH3: => LD2:, LD4:, DU3: along with the ability to: ASSIGN PH3: SRC: so that the standard command files which are already using device names such as SRC:, OBJ:, BIN:, LST: and SAV: could be used unchanged. Since little or no development is still being done, especially at a commercial level, this would be of interest ONLY for hobby users and would be done for free. But since these would likely involve changes to the USR and other DEC programs, the problem of making changes to Mentec owned copyright poses a problem. 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.

Jerome Fine replies: MACRO-11 is extremely flexible and as long as the person writing the code is able to tell MACRO-11 that the code is in a different PSECT, MACRO-11 behaves correctly. Based on what you are saying, since the buffer resides in RMON, even though the code still MUST be PIC since RMON loads into a variable address range (because the resident device driver is always located at the top of memory - and is variable in size dependent on which device driver is used), the linker is able to figure out differences between different PSECTS since that aspect is part of how PDP-11 instructions work. The KEY point is that the linker can't figure out an actual address, but must use execution time code based on the current PC counter. Macros such as .Addr help a lot! None of the above is saying that your statements about PIC are incorrect, only that all of the USR and RMON are that way in any case. The more important question I have not asked is how many words of memory (or blocks within the USR less the extra buffer in RMON) were saved. For those RT-11 users who are not aware, the USR is always an exact multiple of 512 bytes or an even number of blocks. Not sure why, but that is the way the code needs to be. For RT11FB, the USR is always 10 blocks while for RT11XM, the usual size is 12 blocks. How were those figures changed? PLUS, since the USR in RT11XM is resident, there must have been a time penalty. Was that a problem? That seems about 100 to 150 pages which is not excessive. I would certainly pay to have them duplicated and mailed via snail mail if you were willing. What I am MOST interested in is how you managed to handle NON-contiguous files. Since the CSWs (Channel Status Words) for each open file have no method of "seeing" more than one file segment, was there a limit to the number of file segments allowed and where was the information stored? ALSO, for programs which needed to .SAVESTATUS and .REOPEN files, where and how was the extra information saved? I would think that the data for the segments was actually a pointer, but that would then require the information to be saved somewhere and that part I do not understand!!!!! 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.