Jump to content

REXXSEM:The FAQ: Difference between revisions

From EDM2
Ak120 (talk | contribs)
mNo edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
By [[Darin McBride]]
''By [[Darin McBride]]''


Some questions come up often. Some are just simply too interesting to pass up. Either way, they'll likely end up here.  
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".==
==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 clean-up or if some of it is at least "automatic".
'''Answer:''' Um, time for a small course in REXX and DLL internals.


;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.
# 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.  
# OS/2 is smart enough to close all semaphores in a process when it dies (all kernel resources are cleaned up at the end of a process, including semaphores, file handles, etc.). With RXSem, the kernel 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?
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.
# 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?==
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).


'''Answer:''' Try the following:
==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 */
  /* clean up any outstanding semaphores */
  call SemMCloseAll
  call SemMCloseAll
  call SemECloseAll
  call SemECloseAll
Put this in a file, say cleanup.cmd, and call it from your command line, as normal.


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?
==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.
;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.
# Standard functions. Using these functions in your code will make them work on anyone's machine who has the right fix level.
# 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.  
# 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.
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.
* Fixpak-independent. Sharing your scripts that use RXSem will work on Warp3, for instance.
* Cheaper support :-)
* Cheaper support :-)
* Better documentation of the code. The functionality is much better defined.
* Better documentation of the code. The functionality is much better defined.
Line 42: Line 42:
* 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.
* 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)
* 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.)  
* Other extras are available (OpenNetscapeWindow, MyProcessID, Window-List functions, etc.)
 


[[Category:Tools Articles]]
[[Category:REXX Function Library]]

Latest revision as of 22:35, 30 October 2022

By Darin McBride

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 clean-up or if some of it is at least "automatic".

Answer
Um, time for a small course in REXX and DLL internals.
  1. The DLL is smart enough to remove all of its semaphores when it is unloaded by a process.
  2. OS/2 is smart enough to close all semaphores in a process when it dies (all kernel resources are cleaned up at the end of a process, including semaphores, file handles, etc.). With RXSem, the kernel 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?

  1. 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 command line, 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.
  1. Standard functions. Using these functions in your code will make them work on anyone's machine who has the right fix level.
  2. 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-independent. 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.)