Excerpted from message dated 04-07-96, Phil Crown to All:

PC>If didn't call PtcDropFuncs / RxFuncDrop in the test.cmd used to test
  >the .DLL, it was causing some strange problems.  Once the .DLL is
  >loaded it must be unloaded with *DropFuncs / RxFuncDrop before I can
  >recompile and test any changes.  Otherwise, the only way to unload
  >the .DLL is to reboot.  Even though the .DLL didn't appear to be
  >loaded, because I could copy the freshly compiled version over the
  >version in my LIBPATH.

    I use a different technique that doesn't involve RxFuncDrop.  I run
two separate (full-screen) text-mode sessions when writing and testing
REXX external function DLLs.  "Compiler sessions" are started from the
desktop icon for the compiler I am using; it executes a CMD file to set
up the environment for that compiler ("set beginlibpath=..." for those
DLLs used only by the compiler, and "set path=...;%path%;" for the paths
to those directories used only while compiling) and leaves the session
open in full-screen text mode.  The "driver session" is started from the
OS/2 full-screen icon in the launchpad.  Both sessions are using the
same working directory.  I use the appropriate compiler session to
write, compile, and link the DLL; and the driver session to run the test
driver.  All I have to do to modify the DLL after a test run shows it
doesn't work is to switch back to the compiler session.  No RxFuncDrop;
no rebooting.

    I write my REXX external function DLLs with CSet++ (v 2.01) from the
command line (multitasking to call my text-mode editor) rather than
working from an "Integrated Development Environment."  This technique
may not work if you compile from Borland's IDE, but I think it should. I
assume the important matter is that the "driver" session be a
full-screen command-line OS/2 "window," so it is independent of any
other sessions that may be running on the system.

    Try it.  You may like it.  IMO, RxFuncDrop is a dangerous command,
and I avoid it if at all possible.

          --Murray

___
 * MR/2 2.25 #120 * User-friendly: (adj.) trivialized, slow, incapable, and boring

--- Maximus/2 2.02