• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Tips for Autostarting Apps/Scripts on OS/2 & eCS: especially REXX dependent ones

Started by RobertM, 2011.12.22, 22:02:31

Previous topic - Next topic

RobertM

Hello all, here are some tips for autostarting various applications on OS/2 and eCS.

I've run into a variety of interesting problems on eCS that I've finally tracked down. These tips may come in handy if you, like me, run a number of things that are REXX based.

Here's my scenario - various aspects of this may apply to you as well, if you've got certain REXX apps autostarting.


On my OS/2 server, I use xWorkplace and Styler/2. I have a timed startup folder that allows processing startup objects in order and with timed delays between them. eCS, by default, does not have the timed startup folder (HINT to Mensys, it NEEDS it). The server makes extensive use of various REXX function calls to external REXX DLLs, such as REXXUTIL (and almost a dozen others).

Besides setting up networking stuff, such as enabling the firewall and firewall rules, I *must* load the REXX DLLs on startup - the server is usually quite busy, and in order to provide more elegance in the REXX code and minimize processing time (by NOT checking whether the DLLs are already loaded each time the scripts are called by the web server), I load the DLLs at boot. In MOST cases, that may not be necessary, as the performance difference is minimal - but on a server that can often be called to process upwards of 100 requests a second, including calls to RxSQL, REXXUTIL and others, it does speed up request handling by not having each call to each script check to see if the DLLs are loaded - they simply assume they are.




Here's the fixes:

* Use an error handler that only is called on a script failure due to a DLL not loaded - then load the DLLs. That prevents repeated calls each script run to see if the DLLs are loaded - it only checks on failure - and should only do that once. (not the option I chose)
* Load all REXX DLLs on boot, preventing the need for extra code and thus streamlining the REXX code (a 100K REXX script/program may not seem like a lot - until over 100 of them are running at once) (I use THIS method)
* Have each script check to see if the DLLs are loaded when they are called - for the reasons noted above, I do not use this method.



Here's the problem with the method I use (for NON-xWorkplace systems)

(for xWP systems, simply enable and use the timed startup folder)
* Since startup items in the startup folders are not processed in a timed fashion, and simply try to load at the "same" time, if the REXX DLLs are not loaded first, other things in the startup folder fail - in my case, the web server control daemon (code for this is located in another thread - the code controls and monitors Apache and MySQL, ensuring they are running, autostarting on daemon failure, and doing timed shutdown & restarts of each to free memory pools). IF you have problems with certain REXX based things (or certain things that require REXX) failing to start properly from the startup folder, the solutions above and below may be helpful.



Thus, one can theoretically address this in the following fashions:

* Use one of the three methods outlined above (again, for the reasons noted, I prefer #2, but the lack of a timed startup folder causes issues)
* Install xWP and use its timed startup folder - that allows option #2 to work properly
* Call a REXX script in startup.cmd to auto-load the DLLs on boot. startup.cmd should be processed before the WPS stuff, thus giving items started by the WPS access to the already-loaded DLLs
* Install Rexx Autostart (by Herwig Bauernfeind with additions from Chuck McKinnis) and use that to control startup objects - though designed for various other issues (such as WPS hang on startup with certain objects in the startup folder), it is ideally suited for this issue as well.



A major advantage of properly addressing this issue, EVEN IF YOU DO NOT USE REXX, are the following:

* Let's say you are using MySQL and are protecting access to it via the firewall - you can ensure the firewall is configured and loaded BEFORE starting MySQLD, thus having NO time (even if it is only a few seconds) that MySQL is "exposed to the world"
* Other similar scenarios of course also apply.



So... there's the solution to a few different problems: (1) certain startup objects not starting due to DLLs not loaded before them, or (2) ensuring various objects are processed before others are loaded (ie: firewall before server daemons).

Hope that helps someone or anyone.


SIDE NOTE 01:
startup.cmd is NOT a REXX script. It is a BATCH FILE. You cannot simply dump REXX code into it unless you change the whole thing to a REXX script that processes the batch file code as batch file code. Thus, instead, you wish to call the REXX code as an application - and NOT simply dump the REXX code into the batch file. You must then also ensure that the REXX code exits properly so that the rest of the startup script is processed properly.




SIDE NOTE 02:
You can usually move firewall related stuff into startup.cmd as well - assuming you do not have other networking configuration stuff that loads afterwards which would change the necessary firewall rules AFTER the firewall is loaded - if that's the case, you can still load the firewall in startup.cmd, then load the new rule set during the WPS start via a script in the Startup FOLDER.




SIDE NOTE 03:
startup.cmd is NOT the startup FOLDER is NOT startup.cmd - the Startup FOLDER is a special WPS object. startup.cmd is a BATCH FILE that gets loaded on boot. MOST of you probably already know this, but every now and then, someone comes to the forum who is not even aware of the startup.cmd batch file - much less the differences between that and the startup folder - so I thought the differences were worth mentioning.




SIDE NOTE 04:
One may wonder why I simply do not call SysSleep in my Apache/MySQL routine - the reason is very simple actually - it is located in one of those DLLs that needs to be loaded first (namely REXXUTIL. Now, I could simply load all the DLLs in that control script - but other things require them as well, thus, other startup apps will still fail unless the server daemon control script happens to finish loading first.




-Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|