Hi,

I've got a challenge, how do I start a job from the shell at a random time?

Some background info:
I want to start an "EDI direct network communication"-job for a specific network at a time which is not known. Because we have lots of different EDI-networks (more than 10), I build a loopscript which is suppose to:
- startup the DNC for a specific network,
- wait until the semaphore-file command.fil is created,
- sent the outgoing messages to the other site,
- collects the incomming messages from the other site,
- deletes the semaphone-file command.fil,
- wait until the job is done,
- startup the DNC for the next network,
- etc etc

This script is suppose to run always, but as the networks loop I don't know in advance at which time which network is suppose to run DNC. As another matter, DNC can only run one at a time. Otherwise you will get EDI-SESSION-LOCKS.

Is there a ways to startup a job at a time which is not known in advance with the fact that there must be only one job active at the same time?

Thanks for all your input!

Marco

Hi there,

I usually start Baan jobs with a shell script that calls this job (BSH_JOB=[jobname];export BSH_JOB;ba6.1 ttaad5203m000).
Your basic problem is to recognize whether job1 has finished before you can call job2 etc.
You could add two steps to each of your Baan jobs:
First you call a shell script that creates a control file "jobx_running".
Last step in job1 will be another shell script that erases this control file.
Create one shell script for each job that starts this job.
Now you can have a "master"-shell script like:

call shell-script to start job1
while [ -e job1_running ]
do
sleep 60
done
call shell-script to start job2
while [ -e job2_running ]
do
sleep 60
done
.
.
call shell-script to start lastjob

Not elegant, but I hope you get the idea, don't have much time atm.

hth

Norbert

Your basic problem is to recognize whether job1 has finished before you can call job2 etc.

Are you sure? I believe that running your method works synchronous while running "sh $BSE/etc/rc.startjob [JOB]" works
asynchronous (in background).

That's why I usually use the method you mention.

Günther

The problem I am facing is not that I cannot determine when a job is finished. BaaN creates a semaphore-file for this.

My main problem is to start the job on a time which is not known in advance. An example:
- The job is scheduled to be run at 10:00.
- The script that triggers the job (rc.startjob) runs in a loop at 9:23, 9:48, 10:02.

At the first trigger (at 9:23) the job starts waiting for until 10:00. My script can't wait, because there are more (appr. 10) other jobs to trigger, so it abandons the wait at 9:24 and triggers the next job. The same happens at 9:48 and finally at 10:02 the job has run, but perhaps other jobs have ran at 10:00 also, which causes EDI-LOCKS.

I want to run a job from a script without scheduling the job. I want to just run a job, now! :) Without having to wait for the scheduled time to arrive.

Thanks for your ideas!

Marco.

We are using an update from the unix shell on the job table to ensure the correct status; could you also do something like that (status + date)?

Günther

We are using an update from the unix shell on the job table to ensure the correct status; could you also do something like that (status + date)?

Günther

Wow!

This is indeed my missing link! I can change the next run date/time and status in the job table from the script, trigger the job, wait for it to end and go about the next job.

Sounds very good. Do you have the syntax of the command to update the jobtable? Or any hints where to find this?

Thanks!

Marco

Hmmh. As I see you are using BISAM. But why don' t you create a baan session that does an update on ttaad500.edte / stim / jsta (in your current company or company 0)? Simply call that session "ba6.1 [your session]" before "ba6.1 ttaad5203m000".

Günther

Hi All,

When you want to start a job now, without having to know in advance at what time the job you can use the UNIX-script below.

Thanks Günther for your ideas while making this script.

-----------------
# Schedule the EDI-job to run NOW!
echo "2006-09-29 10:57:46.729" > $SCRIPTDIR/tttaad500${EDICOMP}.S
echo "#\$!pre-dump!\$#00037cv" >> $SCRIPTDIR/tttaad500${EDICOMP}.S
echo "$EDIJOB|Direct Network Comm ${EDICOMP}|01012006|1|1|1|2|`date -u '+%m%d%Y'`|`date -u '+%H%M'`|0|01012006|0000|$EDIUSER|1|00000000|0||" >> $SCRIPTDIR/tttaad500${EDICOMP}.S
bdbpost6.1 -R -t"|" -D$SCRIPTDIR -Itttaad500${EDICOMP}.S -c${EDICOMP} -t"|"
rm -f $SCRIPTDIR/tttaad500${EDICOMP}.S
# Trigger the job
su $EDIUSER -c /baan/bse/etc/rc.startjob $EDIJOB
----------------

Some remarks:
${EDICOMP} = in which company should the job run.
${EDIUSER} = with which user should the job run.
${EDIJOB} = the exact (unique) name of the job to be run.

First I create a tttaad500....S file with the correct date/time when the job should run, which is NOW!
Then I su to the user which should run the job, and trigger the job.

After this a loop is waiting for the semaphore-file (command.fil) to appear, after which the transfer of EDI-messages is engaged. The semaphore-file is deleted after that and the next network is processed.

Thanks again, my boss will be pleased with you all! Have a nice weekend!

Marco

Maybe I am missing something but if you define the job in Baan as periodical with period of 1 minute and you keep the status to free than you can kickoff the job out of a script every minute?

In 5c you define the job as being started by an external scheduler (which means you can not define the period anymore) and by this I am able to run my jobs as often as I like.

Regards,
Han

Maybe I am missing something but if you define the job in Baan as periodical with period of 1 minute and you keep the status to free than you can kickoff the job out of a script every minute?

In 5c you define the job as being started by an external scheduler (which means you can not define the period anymore) and by this I am able to run my jobs as often as I like.

Regards,
Han

Han,

Sometimes the job starts AFTER the minute. So, you schedule a job at 10:00 with an interval of 1 minute. The first time the script runs at 10:00. The job gets started en rescheduled at 10:01. The next time the script runs it MAY be 10:02, so after the rescheduling time, but the next time after that the script MAY run at 10:03.

The time when the script runs, is not predefined.

Thanks for your input!

Marco

Hi all,

perhaps I didn't make myself clear enough.
If a job has status 'free', you can start it as I wrote in my posting above, regardless of the value of the field 'nect execution time'.
As we faced a lot of trouble controlling the execution of jobs via Baans job daemon (if the start time is in the past, it won't be started any more for example), we changed the logic to calling each job via a unix script.
All that I suggested was to have one script starting other scripts one after another once the predecessor has finished. This should work without any manipulation of the start dates in ttaad500.
But as your solution works, it's fine anyway :-)

regards

Norbert

Hi all,

perhaps I didn't make myself clear enough.
If a job has status 'free', you can start it as I wrote in my posting above, regardless of the value of the field 'nect execution time'.
As we faced a lot of trouble controlling the execution of jobs via Baans job daemon (if the start time is in the past, it won't be started any more for example), we changed the logic to calling each job via a unix script.
All that I suggested was to have one script starting other scripts one after another once the predecessor has finished. This should work without any manipulation of the start dates in ttaad500.
But as your solution works, it's fine anyway :-)

regards

Norbert

Yep,

You're right! When a job has the status free and the scheduled time is in the past, you can just start the job with the rc.startjob-script without having to "hack" into the ttaad500. And as this script will be running in an critical environment, I don't like to hack into it.

I will change my script and make sure that at first the schedule of the job is in the past.

Thanks!
Marco