Mr. BeHanna:

   Regarding renaming symbols (and retyping them, too) in DISM32:

   The methodology I use is:

    1) scan the first edition .MAR file with an editor in read-only mode.
       what I am scanning for are symbols with embedded dollar signs ($);
       almost always, these are Run-Time Library or system service calls.
       as such, the meanings of the arguments are very well known. From
       this, I try to derive what the arguments stand for in each call
       context. For example:

      a) the third argument to the SYS$PUTMSG service is a procedure that
         is passed a string by descriptor and an arbitrary user value. SO,
         I can arbitrarily change the name of said procedure to something
         like "P_$PUTMSG_actrtn".

      b) the first argument to SYS$ASSIGN is a descriptor-passed device
         name string, and the second argument is a word buffer for the
         returned channel. Hence, I can go look at the device name string
         pointed by that descriptor, and change the symbol on the descriptor
         to something meaningful (i.e. DSC_input_devnam_str) and similarly
         for the device channel word (i.e. W_input_dev_chan).

      c) some of the fields in RMS control blocks point to strings; the
         contents of the strings may help you determine what those RMS
         blocks are used for (and then the procedures that calls the RMS
         services with those control blocks).

      Another useful trick is to look for CALLS instructions to such
      known procedures, and note where register values are pushed for
      the arguments. Knowing what the argument is supposed to be, and manually
      scanning backwards through the .MAR file to where the register was
      loaded (probably with a MOVAB or MOVAL instruction), and fix the
      symbol type and name that was loaded into the register. For example:

              MOVAB   B_00001234,R5
              PUSHAB  (R5)
              CALLS   S^#1,@#SYS$OPEN

      implies that B_00001234 is actually an RMS File Access Block (FAB),
      not just a byte stream. So I edit the TYPE field in the .SYM file for
      address 00001234 to set the bit for RMS control blocks (whatever the
      value of SYM_D_RMS in DISMSYMTBL.INC is) in the second column, and
      either replace the DISM32-supplied name with blanks (so DISM32 will
      assign an RMS_xxxx name instead of a B_xxxx name), or replace the name
      with an actual descriptive name as shown above.

      Another dirty trick some compilers pull is to load commonly used
      procedure addresses into registers, and then do a CALLS #n,(R6) or
      something like that. In that case, the disassembler cannot figure
      out what procedure is being called at the point of the call, and
      so can't interpret the arguments as being potentially high-level
      complex data structures (LIB$TPARSE state tables, for example).
      Here, you have to manually analyze the arguments on the stack to
      see what type they are and possibly correct the symbol type assignments
      in the .SYM file.

    2) I find all the occurrences of such things as I can from the .MAR
      file and jot them down (I don't have a workstation with multiple
      edit windows readily available), then exit the .MAR edit session
      and edit the .SYM file to change the lines I wish to change. Note
      that if you change the type of something, its name won't change unless
      you replace its old name with blanks (otherwise DISM32 assumes you
      want to keep the name in the .SYM file for whatever reason). Then
      re-run the disassembler so it can read the modified .SYM file to help
      "prime the pump" for the next disassembly. 

      Note that any symbols you do not want forced in name or type should
      be deleted from the .SYM file; the disassembler will regenerate them
      anyway, but you may want to let it change the names (for example, in
      a place where you changed a byte symbol to a procedure symbol, the
      newly defined procedure directly calls some other procedure that was
      referenced by register-indirect in code that was disassembled as code
      before; this will cause the other symbol to change its type and name
      [unless you force the name] as well).

    3) Then, I read the new .MAR file and go around again until the image is
      completely deciphered or until I have the information I want (whichever
      comes first).

   That's basically all it is. Note that you can force the retyping of
   anything in the symbol table just by editing its TYPE and EXT_ATTR
   fields in the .SYM file (the EXT_ATTR number is ignored unless the
   SYM_D_EXTENDED bit is set in the TYPE mask for the entry).

   Good luck, and let me know how it comes out.

				Andrew Pavlin
				General Electric Co.
                                CSP-3-18A
				Syracuse, NY 13221

   P.S. My telephone number has changed; I'm now at (315)456-7493 if
        you need to call.

   P.P.S. Let me know what disassembler version and VMS version you are
          using; I'm trying to improve the documentation, and suspect I'm
          going to add a version of this letter to the DISM32.RNO file.