Subj : HSTART DOES NOT WORK
To   : Mike Powell
From : Peter Knapper
Date : Mon Apr 18 2005 09:46 am

Hi Mike,

 MP> Are there any other ways to call a CMD file from a DOS session?  I cannot
 MP> believe this is so difficult.

Try thinking about the problem another way. It sounds like the issues you are 
fighting are about CONTROL over the BBS operations you are trying to perform. 
Any time you use the START (or HSTART) command, you lose SOME of that 
CONTROL,however YOU CAN use these commands when that control is not so 
critical.

I have never used HSTART, however the way I have done this type of thing is to 
keep CONTROL totally WITHIN a single, continuous, OS/2 CONTROL Process, and use 
that to invoke the OS/2 or DOS CHILD processes as I require them. The second 
important thing I do is to run the CHILD processes INLINE with the CONTROL 
script and NOT via the START command. If START is used, then I ensure that 
event can run totally "standalone" and wont EVER need to return to the invoking 
process, and wont conflict with anything else OTHER than itself. I still have 
to put other controls in place to ensure that command ends before it is run 
again, but that is also easy (see below).

IE: I use ONE MASTER OS/2 process (a .CMD file) that stays running the entire 
time the BBS machine is running. I use a small utlility called SLEEP (or you 
can write that in REXX if you really want) that does exactly that, it allows 
that .CMD file to "go to sleep" for a period of time (I use a 60 second sleep 
period) before it checks the FLAG files for any actions to be performed. That 
OS/2 CONTROL process invokes the OS/2 or DOS tasks that I need to run, and 
those CHILD processes in turn return or signal the CONTROL process how they are 
going by using FLAG (SEMAPHORE) files (using a Virtual Drive of 16KB). Another 
way of doing this is to use a REAL semaphore if you want. This methodology has 
worked fine for me since I first used it in 1992 on OS/2 v2.0, BUT please note 
that 95% of all the CHILD work is performed using explicit CALLS, not START! 

The PRIMARY purpose of this MASTER process is to SERIALIZE all the INDEPENDANT 
actions that are required to be performed to operate the BBS, actions that are 
not USER dependant, so that NONE of them can possibly conflict with anything 
else for resources. The only items that are NOT included in this MASTER process 
are the Mailer and user sessions, they need to be standalone because they react 
to external events, however those processes also include the sharing needs of 
the system operation anyway. If a Mailer or BBS User session requires some 
action performed (EG to IMPORT or toss received mail or EXPORT or scan for 
outbound mail, then the Mailer or user session leaves a FLAG file requesting 
the CONTROL task to perform this. NONE of the background tasks are executed 
except in the processing sequence determined by the CONTROL task!

This methodology does require a bit of careful planning in the MASTER and CHILD 
..CMD (and .BAT) files, but once you get used to the practise, the entire thing 
works extremely well. The only added bits not mentioned so far are CRON events 
that trigger those rare (once per day/week/month) items, but again, those 
invariably run via the FLAG method, IE the CRON event simply sets a FLAG. I can 
pause ALL background BBS processing by simply controlling the one CONTROL 
process. Currently I have about 35+ different FLAG files (actions or events) 
that the MASTER process reacts to.

I am sure what you wish to do can be done, but perhaps you just need to look at 
how it can be done differently from what you are expecting.

Cheers.............pk.


--- Maximus/2 3.01
 * Origin: Another Good Point About OS/2 (3:772/1.10)

.