A common question is how to launch an A-Shell background process on system boot. Essentially the concept is the same as launching any kind of independent background process, except that we need to insert our command somewhere that will get it executed automatically by the system boot process. Unfortunately, the details of that vary from one Unix platform to another, but to take an example, most Unix distributions have a script /etc/rc.local which gets executed towards the end of the boot process, and which is intended for launching application-level processes like A-Shell.
Although you can put as many entries as you like into /etc/rc.local, I would recommend consolidating all your A-Shell related startup processes into a single script kept in the A-Shell bin directory (we'll call it bgprocs) and then have rc.local execute it. (That way, when you set up a new system, or overwrite your rc.local, it's easy to reconfigure it. For example, you could insert into rc.local something like:
echo "Launching A-Shell background processes..."
/vm/miame/util/bgprocs
(I recommend you create a special subdirectory below the $MIAME directory where you keep your own scripts, nice and separate from A-Shell stuff. In this case we're calling it /vm/miame/util)
Your bgprocs script should reference a separate script for each of the processes you want to launch. This may seem like overkill, but it allows you to execute the individual scripts again later, as needed, to re-launch a background process by itself. So let's say we have two background processes we want to launch:
# launch background process #1
/vm/miame/bin/bgpro1
# launch background process #2
/vm/miame/bin/bgpro2
Finally, each of the individual process launching scripts could look something like this...
echo "Starting Background Processor #1..."
/vm/miame/bin/ashell -n -e -td DUMB -j BGPRO1 -i /vm/miame/miame.ini BGPRO1 >> /vm/miame/dsk0/444123/bgpro1.lst 2>&1 &
Important: Remember to mark all of these scripts as executable (using chmod +x)!
A few notes about the command line in the example above:
-n will eliminate the splash message, which isn't very useful in the background process
-e will cause the job to exit A-Shell if it drops back to the dot. (This is usually helpful for detecting whether the job is running, particularly in conjunction with the -j switch to set the jobname. If it stops running, you could probably just launch your bgprocs script again to restart it.)
-td DUMB will tell it to use the DUMB terminal emulation, which will minimize the amount of escape sequence garbage that will appear in the output log
-j BGPRO1 forces the job to be named BGPRO1 in this case. That is of course optional, but is sometimes helpful for making it easy to spot whether a particular background server job is running.
The BGPRO1 following the ini file spec is the startup command. In order to get your background process running, you'll probably need a command file (here it's cmd:bgpro1.cmd) to log the job to the right location and start the program running.
>> /vm/miame/dsk0/444123/bgpro1.lst causes the output of the process to go into that file (useful for checking what happened later, and to keep it from going somewhere undesirable, like into the mail queue.) I recommend putting the output file in the same ppn where the process runs, although you have to specify it in native notation here.
2>&1 forces the stderr output (file descriptor 2) to go to the same place as descriptor 1 (stdout), so that any error messages coming from the operating system relating to the launch of A-Shell itself will also be captured there.
As for keeping tabs on the background processes, it is recommended that they output their own status information to some kind of text file. The procedure SYSLOG in SOSLIB:[907,12] does a nice job of this, but if you do your own, make sure you add a timestamp to each entry. Also see the function Fn'Sprintf$() in SOSLIB:[907,10] which is very handy for outputting formatted messages and has a simple code for time stamping.
Then you can create a relatively simple utility monitor program that uses SYSTAT/L to get a list of the jobs running (from which it can determine if each of the background jobs is running, either from their jobname or the program name column). So you display a little list, and provide some way to request to see the log for any one of them. (You can use EZTYP, or perhaps TAIL <file> for that.) If the job is not running, you can re-launch it by using xcall HOSTEX,"/vm/miame/util/bgpro#" or something like that.
Example
Here's an example of such a screen that I set up for a customer with several background processors. It just has a one-character INFLD field for each process, where you can enter a code to display the activity log, reset the job, or ESC. Of course you can get much fancier with a GUI screen, perhaps creating a continuous multi-window monitor.
SENSORS - Status and Maintenance of scales & scanners
Program Job Status Action (A=Activity log, R=Reset, ESC=exit)
------- ------ -------- ------------------------------------------
ACOUNT ACOUNT [OK] A
ASCALE ASCALE [OK]
ASCAL2 ASCAL2 [OK]
CMBSCL CMBSCL [OK]
KSCALE KSCALE [OK]
CSCALE CSCALE [OK]
CARCAM CARCAM [OK]
