REXXSEM

The FAQ

Some questions come up often. Some are just simply too interesting to pass up. Either way, they'll likely end up here.

Question 1. If I create a mutex and my rexx script either dies or terminates without closing the mutex, does it persist for discovery by later opens and creates? I'm not sure just how important it is to do cleanup or if some of it is at least "automatic".

Answer: Um, time for a small course in REXX and DLL internals.

The DLL is smart enough to remove all of its semaphores when it is unloaded by a process.
OS/2 is smart enough to close all semaphores in a process when it dies (all kernal resources are cleaned up at the end of a process, including semaphores, file handles, etc.). With RXSem, the kernal won't worry about the semaphores since the DLL will have just closed them right before the process ends.

So far, this tells us little. When does the process go away?

REXX runs in the process space of the calling program. Usually this is CMD.EXE or whatever command processor you're using. So the process ends when the command processor's process ends.

The question then becomes, does your command process end when the script does? For example, most of my scripts are run from an icon, which amounts to "CMD.EXE /c Script.CMD". (Actually, I explicitly make the "Path and file name" set to my command processor, and set the parameters to "/c Script.CMD", but I don't need to.) This means that the script will be run, and then the processor will exit, automatically. From #1 above, this means your semaphores will be cleaned up (released and closed) automatically. However, if you're in a command session and simply run the script and it aborts for some reason, then the process won't end until you close that session (either with the "exit" command, or by closing the window).

Question 2. So, how do I clean up all my semaphores if I don't want to exit my process?

Answer: Try the following:

/* clean up any outstanding semaphores */
call SemMCloseAll
call SemECloseAll

Put this in a file, say cleanup.cmd, and call it from your commandline, as normal.

Question 3. REXXUTIL has lately come out with some semaphore functions - why use yours? Answer: There is a definite advantage to using IBM's semaphores. Here is what I have so far - if you have more, please let me know.

Standard functions. Using these functions in your code will make them work on anyone's machine who has the right fixlevel.
Support. IBM can offer commercial support - I am merely a single developer working in his spare time and will offer the best support I can, but IBM can offer much better. Of course, this may require a service contract that, well, I know I cannot afford.

On the other hand, there are advantages to using RXSem instead.

Fixpak-independant. Sharing your scripts that use RXSem will work on Warp3, for instance.
Cheaper support :-)
Better documentation of the code. The functionality is much better defined.
Access to the developer to find out what isn't in the documentation.
16-bit semaphores. Through practically the same interface. (In fact, if you use SemMCreate rather than SemMCreate32 or SemMCreate16, it is exactly the same interface!)
Open/Create semaphore in the same function call. Let's be honest - we don't need to call both - if we want access we generally don't care if no one else has it or if someone else has already created it.
Most functions abstract the API underneath to some degree to make your code more readable. (For example, compare SysSetPriority vs PrioritySet)
Other extras are available (OpenNetscapeWindow, MyProcessID, Window-List functions, etc.)