Using asynchronous option in Run statements

eddiej

New Member
I'm trying to execute a series of programs from a main program that will run and not wait for the previous program to finish before the next one starts. From what I can tell, using the asynchronous option in Progress is the way to do this. So far nothing has worked. I keep getting errors complaining about needing to use the "on server" and "in proc-handle" options. The programs I'm running are external, but not on a remote server.

Any suggestions?

-Ed
 

jongpau

Member
Hi,

You can only run programs asynchronously on an appServer. Progress does not do multi-threading so you would not be able to do this within a single Progress session (so what you are trying to do now is not possible). Remember, when you do ansync runs on an appServer each running program will run on a separate appServer instance -- this can get nasty when you have limited appServer connections available.

Paul
 

RKR

Member
Hi,

You can only run programs asynchronously on an appServer. Progress does not do multi-threading so you would not be able to do this within a single Progress session (so what you are trying to do now is not possible). Remember, when you do ansync runs on an appServer each running program will run on a separate appServer instance -- this can get nasty when you have limited appServer connections available.

Paul

If you want to execute a program asynchronous from your session and you do not want, or do not have an appServer you could also consider to start a new Progress (batch) session that can execute the program you wish to run. This can be done using os-command with the no-wait and silent options. This can become a problem also when you have limited DB connections and the other problem is that without using sockets it will be hard to have the 2 sessions communicate with each other.
 

eddiej

New Member
The intent was to actually run this directly on our db server (UNIX HP-UX). The main calling program would be launched throught the UNIX scheduling utility (chron). Correct me if I'm wrong but it sounds like this really isn't an option.
 

TomBascom

Curmudgeon
You can run lots of things from cron. Including Progress procedures. But it sounds like you aren't familiar with UNIX and you're perhaps a bit confused about how to set it up?

The main calling program is at the root of a session. A Progress session is single threaded -- so if you need multiple asynchronous threads you will need multiple sessions. One way to get those is via app servers which is where the 4GL ASYNCHRONOUS keyword comes in. But that probably isn't really what you want and it probably doesn't really work the way that you might expect -- for instance, the app server session remains single threaded.

If you really need asynchronous processes you basically have to start a session for each one. That isn't terribly hard. It just means that you need to shell out and run "mbpro" or the equivalent and provide it with an appropriate -p startup procedure and, perhaps, some -param parameters. These can be started from cron or from an ordinary interactive session it doesn't really matter.
 

eddiej

New Member
Tom, I've actually done several things with UNIX, but not a lot with cron.

I agree, setting up multiple sessions is pretty easy to do. I was hoping to be able to do this with one session via the asynchronous option and not have to start multiple sessions. For what we are trying to do it would have made things easier.

Thanks for the feedback,

-Ed
 
Use the backbone of ADM(1) method.

Run ProgramName PERSISTENT ProHdl.

By running the program in a perstitent manor Prowin will allocate it's own memory resource, assigning the process a handle will enable you to access it's methods and refer to it.
 

sphipp

Member
Crontab is fine for scheduled jobs. We put them in script files and call them from crontab (crontab -e to edit them).

However, if you want to run a job while you are running another one in Unix, you could use the "at" command with os-command no-wait. This means that the spawned session is not connected with your session at all and killing off your own session will not affect the new one.

I'm not sure if a simple os-command mbpro will survive a kill -9 on the original process (I've never tried it), but using "at" will ensure that it will.

However, with Unix, the spawned command will be non-interactive. If you use os-command under Windows to set off a new session, the session is on screen and can be interactive. If you use character on unix, however, I don't think you can spawn a separate interactive session.

But, it's fine for things like printing reports or labels while you are doing something else. So, if you had a program that neded to print 150 labels and the label printer behaves like a dog and can only accept 10 labels at a time without falling over (Unrealistic? Not on one of my jobs) then you could use "at" to kick off the label print program in a separate session while your main program continued on its merry way, rather than having to wait for 10 seconds after each batch of 10 labels.
 
Top