UNIX for Advanced & Expert Users

Hello,

i was wondering if you could assist me in the following situation:

i am trying to queue a group execution commands (same command but different parameters) submited from an openVMS system to a Unix system (HP UX). The commands should run in sequence; the next starts after prev finish and only one running at a time. The commands are submitted from openVMS server in random order at any time. Notes: openVMS has queue functionality however is not an option in this case due to other reasons

So far the only option i see is writing a solution from scratch. generally speaking, this solution will involve copying the command as they come in from the openVms server into a file and having another process check this file for the next command insuring the commands are executed in FIFO order. the process will check the file continously or within specified constraint

this said, i was wondering if there are any unix commands that can do similar function or could help in this case?

How does VMS "submit" the "job" to the UNIX server?

the jobs are invoked using ssh sessions.

i was looking into command such as mkfifo however they only seralize the processes. ie it does not gaurantee one process will start after the prev finishes. i can only have process running at a time.

Is each job submitted via it's own ssh process?

yes. each is submited usinging its own ssh sessions. some of these jobs take 3 hours to complete which causes ssh session to timeout. Increasing the timeout period is not an option in this case. at the same time the rest of the job should be submitted provided nothing is running on the hpux server and this is basically the delima. i personally perfer the load and logic is moved to the hpux and the only role of the openvms server is just submitting jobs instead of waiting for the ssh session to complete.

I waited a few days to let others give a try at this. Here are some possibilities:

1. Use batch which comes along with at. If atd is not running, ask your sysadmin about this. I've access to the Linux version which might be completely different than the AIX version.

With batch you give it the commands from standard input. It queues the commands to run (by atd) when the system load average is below a threshold (specified by atrun or atd).

Cons: Your jobs might not affect load, so this might be useless. A job might suddenly become IO bound, fooling atd to run the next program.

2. SGE - Sun Grid Engine. It's a full-featured batch submission engine, but it might be overly complex for this kind of application. On the other hand, it's relatively easy to set up.

3. Custom queue:

Instead of the command actually doing the work, override it with a shell function that outputs the command and parameters to a FIFO. Here's the gist of this:

Code:

umask 077
mkdir -p $HOME/var/run
mkfifo $HOME/var/jobq

Now create a cronjob (to run every minute) to read the queue and execute the next command, as long as the previous is not still running:

Code:

* * * * *  $HOME/bin/batch_execute.sh

in $HOME/bin, you can create the script:

Code:

#!/bin/sh

# If another job is running, exit immediately
test -f $HOME/var/run/jobq.lock && exit 0

# lock the queue (exit with 256 on failure)
touch $HOME/var/run/jobq.lock || exit 256

# read the queue
read job < $HOME/var/run/jobq

# run the program
eval $job

# remember job's exit status
status=$?

# remove the lock when done
rm -f $HOME/var/run/jobq.lock || exit 257

# exit with job's exit status
exit $status

There is a big problem with this scheme, however: the writers will block until the reader is available. So the job submitter must go into the background until the reader is available. Here's such a job-submitter.

Code:

#!/bin/sh
# submit.sh
echo $* > $HOME/var/run/jobq &

Prefix all your jobs with this "submit" script (which should be in your PATH or hard-coded as something like $HOME/bin/submit.sh).

I haven't tested this, and there maybe some problems. But give it a try.