TECO can edit binary files, IIRC. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

I can understand using TECO to inspect an RT-11 filesystem in a general fashion to look at text strings in files that can't be found since the file structure is corrupted. Actually, I would think that KED would be just as good in that regard to INSPECT the contents of a device with a corrupted filesystem. However, I don't understand how you can use TECO to actually repair an RT-11 filesystem. For that purpose, I can only see SIPP as being able to change or repair anything. For example, until I can implement the feature in PIP, I use SIPP to set the READ ONLY bit for a file in RT-11 (the three lines of code are there in the Monitor to prevent a WRITE to a READ ONLY file, just not advertised). Can you describe how you used TECO to recover data from a borked RT-11 filesystem (assuming that you did more than just READ the text contents of the files in the same manner that KED would also allow using a non-file-structured edit of the whole device)? Otherwise, if you just used TECO to just READ the text strings, please confirm that as well. I am certainly not saying that TECO can't do that, but if it can, I would certainly like to now how it is done! Jerome Fine

OK!! I understand completely!! If anyone else who is interested does not understand, please ask some questions. If the ASCII data in question was not in the first buffer, than I assume that something like the TECO command: <ASstring$:;J9999K>$$ was what you used to find the start of the file which you had lost. By the way, KED can do the same, but is limited to devices (I assume that you must have done a non-file-structured open, i.e. ERdev:$$) that are less than 32768 blocks. Since I have never had occasion to edit a full MSCP device of 65535 blocks, I just never noticed the limitation. This restriction for KED also applies to files. So KED can INSPECT a logical device which is 32767 blocks or less or an RL02 device, but no physical device or file larger than 32767 blocks in total. My backup interval can be as short as 5 minutes. This is because it now takes only about 1.58 seconds to backup a complete MSCP device of 65535 blocks. I realize that this speed seems rather incredible, but I just measured it to be sure. In case anyone is interested, I am using Ersatz-11 running on a Pentium III under Windows 98SE with 160 GB ATA 100 seagate hard disk drives. The SL: (Single Line Editor - runs under RT-11 and is similar to DOSKEY or NDE) which I enhanced requires only 2 keystrokes to find and execute the RT-11 command: COPY/DEVICE/NOQU D61: D01: I keep approximately ten backup files of 128 MBytes each (4 RT-11 partitions) for the current work I am doing. I ALSO keep all of my permanent devices (under E11, I think of a permanent device as a file which E11 has opened and uses as an RT-11 physical device, i.e. using the E11 command: MOUNT DU0: C:\E11\MSCPFILE.DSK /RONLY) as READ ONLY devices. This is because the RT-11 monitor is not protected I was fixing bugs and making enhancements to the actual operating system software, even on the real DEC PDP-11/83 when it took about 240 seconds or 4 minutes to copy a complete RT-11 partition from one physical drive to another, I also always kept the physical drives under READ ONLY status and only allowed a WRITE to the physical drive when I was confident that I was using a stable operating system. More than likely, you just found the source ASCII text you were looking for and wrote that to the floppy file using something similar the the TECO command that I suggested. TECO is not designed nor able to show individual words of a specific block as SIPP is able to do. Been there - done that - understood. I really don't think so. TECO can, as far as I know, work only with ASCII text strings. Binary data can't be managed easily, if at all, by TECO such as what SIPP can do. I rarely use the PDP-11/83, even with the 3 * 600 MBytes ESDI hard drives any more. When I have literally 10 GBytes of files (or even more) to choose from and the E11 system is 15 times faster than a PDP-11/93, there is little to choose from. On addition, I still have 6 * VT100 terminals to use with the PDP-11/83 since there is no easy way to quickly switch between screens. E11 supports 12 different screens which I can switch between by using the <ALT/Fn> key combination. In effect, each Function Key controls its own terminal display which is effectively an instant switch due to the speed of the display on a PC. Since I can look at only one at a time, it would take me longer to move my head to look at a different terminal than it does to press <ALT/Fn>. In addition, an actual benefit that I have used more than once is to be able to visually inspect two displays which are almost identical and be able to observe the few changes flip between one <ALT/Fn> to the other and back again repeatedly. And those stats are low. When I complete my upgrade to the core 2 duo CPU I have already tested, RT-11 then runs 100 times as fast as on the PDP-11/93 and I will have more than 100 GBytes of files out of 1 TB of disk storage to use for RT-11. Since the sound and feel of hardware is not a factor for me, only the ability to run RT-11 software, there seems little to entice me back to the real DEC PDP-11/83 although I expect that I will keep it around for at least until January 31st, 2036 when the DATE value become negative. If possible, I will celebrate NEW YEARS by watching the DATE value change from 071777 to 102040 (all values in octal). I can't remember what YDMV means at this point????? Jerome Fine

Hi On a PC, I use XTree in the Hex edit mode. Dwight