RE: [MI400] Dave McKenzie's UNDELete utility - a LifeSaver!

[Dave McKenzie <davemck@xxxxxxxxxxxxx>]

In addition to modifying one machine instruction, the MI pgm UNDELM has
to be made system state to work.  Is that what you mean by "modifying
the domain bit/byte"?

Just for fun, I tried running it with UNDELM as user state, and the
first error it got was MCH6801 "Object domain violation".  That's
because it tried to do

  SETSPPFP  FILSPP, FILSYP;

That is, set a space pointer to the file header object from a system
pointer.  Since the header is a system domain object, a pgm has to be
system state to set a space pointer to it.

The modified machine instruction in UNDELM is in the VMCRD subroutine
(showing its CISC heritage: VMC was the "vertical microcode" on
CISC--what is called SLIC, System Licensed Internal Code, on RISC).

VMCRD reads memory at a virtual address (in the field PADDR).  Here's
how the instruction is compiled from source:

  CPYBLA  ADDR, PADDR;

The modification is to change this instruction so that it loads the
address (PADDR) into SRCMSP, a machine space pointer.  Then SRCMSP is
used to copy memory from that address into some variable.

The instruction before sets SRCMSP to point to ADDR (an unused
variable), so without the modification, the copy will just copy ADDR,
and what comes after it if the length is longer than 8, to the
destination variable.  In other words, when any caller of VMCRD calls it
to read some data from the file, instead it will just get garbage.

Trying to predict the result of that is like trying to predict what a
mechanical clock will do if you throw a machine screw into its works :-)

The reason it's quick after the first time is just that once the pages
of the program and file are paged in from disk, it's all just memory to
memory copies.

So, I'll change it and let the silicon drip!
  
--Dave

On Wed, 2004-09-01 at 07:58, Dan Bale wrote: 
> > -----Original Message-----
> > From: mi400-bounces@xxxxxxxxxxxx / Dave McKenzie
> > Sent: Wednesday, September 01, 2004 10:27 AM
> >
> > Actually the source in undelsrc.zip is the RISC source.  However, you
> > can't just compile it to get a running pgm.  You have to modify a
> > machine instruction with SST.
> 
> Maybe that's why I was getting the error I reported (TOL0011 "Invalid
> relative record #")?  Are you modifying the domain bit/byte?
> 
> <snip>
> >
> > I originally made the number only 5 digits out of paranoia that people
> > would tie their machines in knots scanning for billions of records
> > interactively.  But as I get older, I get more libertarian, so what the
> > heck!
> 
> You know what I always say, give me the liberty of "burning" the CPU and
> I'll take the heat!
> 
> Well, just so you know, when we tried this out yesterday, it went through
> 99999 records in a blink of an eye.  Hmmm, the first iteration takes a few
> seconds, but when I exit UNDEL, and run it again on the same file, it's
> seemingly instantaneous.
> 
> > Let me look into this.
> 
> Much appreciated, Dave!
> 
> db