Many applications make use of some kind of background jobs, which leads to the question of how to implement them under A-Shell. Under AMOS, you would typically have launched such jobs from the system INI when the system was booted, but under A-Shell/Windows/UNIX there are a variety of possibilities and considerations, which I'll try to review here:

1. How to launch a background job when the system boots:
Start by coming up with the necessary command line which will start A-Shell and then the program (typically via a startup command file). You can test that from the shell prompt (under UNIX) or from the Start>Run prompt under Windows. Once you have it perfected in interactive mode, to make it invisible, for Windows, add the -z (invisible) or perhaps -zi (system tray) switch to get it off the Task Bar; for UNIX, add code to the end of the command line to redirect the output, i.e. ">out.lst 2>&1" (to redirect both stdout and stderr to the file "out.lst") or ">/dev/null 2>err.lst" (to discard stdout but capture stderr). Under UNIX, you'll probably want to add "-td dumb" to set the terminal driver to "dumb" to eliminate emulation escape sequences from any captured output.

Finally to launch your command at system startup, for Windows create a shortcut with the command line and add it to the Startup folder. For UNIX, add it to rc.local (or the equivalent).

After writing the above, I just discovered that there was is a detailed discussion of launching a background job under UNIX here: http://www.microsabio.net/ubb2/ultimatebb.cgi?ubb=get_topic;f=4;t=000229

2. What if it dies and needs to be re-launched?
I recommend that the first thing your background application does is check to see if it is already running. One simple way to do this is to use the -j switch to force it to use a specific job name. If the job name already exists, the A-Shell launch will fail, so there would be no harm in just re-launching it as often as you like, either manually or automatically. (This assumes that if the job dies, it will close itself down entirely. You can help guarantee that by using the -e startup switch, adding HOST to the end of the command file which starts the app, adding XCALL MIAMEX, MX_EXIT to your error trap, etc.)

Under Windows you can use the System Scheduler (aka "Scheduled Tasks") to force your shortcut to be launched every few minutes, so that if the background job does die, it will automatically get restarted. Same idea under UNIX, except using crontab.

Another possibility is that other jobs in your application can act as watchdogs, such that if they detect the background job is missing, they can relaunch it using XCALL HOSTEX, or, for UNIX, you might prefer XCALL SUBMIT (but use the /NEXT:0-0-0 option to make it run under control of the atd daemon rather than as a child of the job which launched it.) See this thread for a discussion of how to launch an independent task using HOSTEX: http://www.microsabio.net/ubb2/ultimatebb.cgi?ubb=get_topic;f=5;t=000435#000003

3. How can we make the background job detect when a new version is available, and relaunch itself? Thanks to Ken for thinking about this, which resulted in this thread:
http://www.microsabio.net/ubb2/ultimatebb.cgi?ubb=get_topic&f=5&t=000402#000002

4. Do background jobs count as nodes against the license? Yes and no. The first background job does count. Additional jobs do not count until you have as many background jobs as you have licensed nodes, and then they start counting.

5. How to keep track of what background jobs are doing? The time-tested approach is for your background job to maintain a log file and/or status file that you can examine. You may find the SOSPROC: procedure SysLog() to be helpful. Also, keep in mind that if you want to be able to see the latest messages output to a sequential file, you either need to close it after each message (reopening for APPEND prior to each new message) or disable output buffering using MX_NOBUF. You'll also want to make sure when you query the log file that you don't open it in a way that will interfere with the on-going output to it.

Under Windows, if you run your background jobs from the system tray, you'll be able to make them visible by double-clicking on their icons in the system tray. (Although in a multi-user system, you'll have to do this from the PC which launched the job.)