RSX program to delete a file by ACP QIO

  Using SIMH to simulate PDP11s is a real convenience. From the comfort of your easy chair, you can start and stop virtual machines at will. You can quickly copy disks to do backups and create copies to perform experiments that might prove fatal.

  Last week, however, I discovered a draw back to this ease of use. While working with several simulated machines, I got confused and started two instances of RSX11M-Plus, using the same system disk, at once.

  It worked with no complaints at all. However, the two copies of the OS were simultaneously accessing the same system disk, without coordination. That means each one was merrily assuming it had the definitive copies of things like the index file, and the storage bitmap, and could allocate things in each one freely. This is a recipe for disaster.

  Fortunately, I don't automatically execute much stuff at boot time, and I noticed what I had done in only a few minutes. I shut them both down and rebooted just one copy. It booted fine and seemed to be working OK, but, I figured, I needed to check things out rather than wait for any disk data damage to grow to a level that could no longer be ignored.

   I booted a different copy of RSX from a different system disk, that was not involved in this lapse of attention, and mounted the possibly damaged system disk as a data disk on that system (you don't want any activity going on on a disk while you run VFY). A VFY run showed it was not as bad as it could be, but, far from as good as it could have been.

  The scan showed that I had multiply allocated blocks - that is, I had at least two files that claimed to have some of the same blocks. That obviously happened when the two systems allocated some blocks that each thought were free - and weren't. Normally VFY tells you what the files involved are, so you can delete at least one of them, and then rebuild the index file and bitmap, to get them to reflect actual usage in the files. But, this time, it only listed one file, and it wasn't in any directory. Worse yet, for some reason, a lost file scan did not restore it into [1,3], and it would not delete successfully using PIP  with the /FI switch (this switch lets you access a file by File ID instead of name). All attempts to access it produced a "bad file header" error message. And the other file it was commingled with, I had no idea what or where it was.

  So, I was in a bit of a pickle. I decided to have a go at deleting it using an ACP QIO with the IO.DEL function. Simple QIOs I figure everybody is familiar with by now - they do IO to devices, like terminals, or tapes, or lots of other things. ACP QIOs are QIOs that issue instructions to the file system of a disk, rather than to the data on the disk itself. They are used for things like creating a file, setting the attributes of a file, entering and removing files from directories, and about a dozen other things, one of which is deleting a file.

 Turns out that this particular call is  a piece of cake - the QIO looks like


         qiow$      io.del,lun,efn,,iostat,,<fid,,,,,>
  
where io.del is the function code, lun is a logical unit number assigned to the disk, efn is an event flag number, iostat is a 2 word buffer for the io status, and fid is address of the three word file id, which consists of one word of file number, one word of sequence number, and one unused word, that was going to be for relative volume number, but RSX11 never got multi-disk volumes (except for SCS-11, but that's another story).

  I cobbled up a macro program that would accept a device name and file ID, and issue the delete QIO. It worked. A new VFY run didn't report on that file, but now reported on the file it had been tangled with as containing blocks that were marked free in the bitmap. That was no surprise, since when I deleted the first file, its blocks were marked as free, which included the blocks contained in the file it was entagled with. I deleted the second file, and then did a VFY with the /UP switch, to mark as used all blocks that are contained in files, and another with the /RE switch, which makes sure the storage bitmap accurately reflects the blocks marked used in file headers, and then a third with no switches, which was error free.

 Anyway, here's the program, on the off chance someone ever has need to delete a file by file ID and PIP won't do the business. In any case, it's a middln'  good example of using TPARS to parse command input. It also uses three of my favorite RSX things - GCML/CSI (well, not much CSI, but GCML), TPARS parsing, and ACP QIOs, which by coincidence are all covered in the same manual, the RSX IO Operations Manual. I spend more time using that manual than all of the rest of them put together.

fiddel.mac


  To use, 

>mac fiddel=fiddel
>tkb 
TKB>fiddel=fiddel
/
Enter Options:
TKB>task=...FID
     (optional libraries)
TKB>libr=fcsres:ro
or
TKB>suplib=fcsfsl:sv
//
>
>run fiddel           (or install it and invoke with FID)
FID>disk:fid:seq

  where disk is the name of the disk, fid is the file number, and seq is the sequence number
eg
FID>DU2:1024:17


  I should mention, that fiddel just deletes the file, but, if the file has a directory entry, it is not deleted. Usually, when you have a problem that fiddel helps with,the file won't have a directory entry - but, if it does, you'll have to delete it separately, using the /RM switch with PIP.