&.RM55&/&.LM2&/
  A minor addition concerning error handling must be
 made to the TYPES.SCR or TYPES.DOC code. In screen 2
 of the source code,  the system sets up a third
 stack called OSTACK, which incorporates no checking
 for underflow or overflow. In certain circumstances,
 overflow could occur. If you are debugging a new
 type and an operation crashes in such a way that
 FORTH executes an ABORT, OPOP will never be reached
 and a stray item will be left on the OSTACK. If
 repeated enough, this could overflow the stack.
     To solve the problem, you need to modify ABORT
 to reset OSTACK. The way to do this depends on your
 FORTH system. 
     This is the actual code that you'll need:
 : ORESET     OSTACK DUP 16 +  SWAP ! ;  ( Reset
 OSTACK to empty)
 : MYABORT    ORESET ABORT ;
     To replace ABORT by MYABORT, a variety of routes
 are open. In a good professional FORTH system, ABORT
 will be vectored through a variable, or other known
 memory location, to let you set up custom error
 handling. The variable might be called, for example,
 UABORT, and you would use:
     ' MYABORT UABORT !
 You need to find out how it's done in your own
 system. 
     If your system does not provide vectored
 execution for ABORT, then you need to check out the
 internals of the definition of your ABORT,
 perferably by using a decompiler, but at worst by
 studying its hex dump.
     At some point, usually at the very end, ABORT
 calls QUIT. If you can find the address of this call
 to QUIT (let's call it ZZZZ), then instead of
 MYABORT you can define:

 : MYQUIT     ORESET QUIT ;
 and then do a dirty patch of MYQUIT into this
 address:
     ' MYQUIT ZZZZ !
 Test the redefined ABORT  carefully before
 proceeding, as a flaky ABORT is pretty explosive in
 effect. 

