keithdonn
11th April 2002, 23:16
Goal: Running jobs from cron and capturing return codes to perform error handling.
I've been able to capture the job status using the qptool6.1 tool. This is great for determining is a job is in a "free" status and ready to be executed, but it doesn't tell me if my call to execute the job was successful. $BSE/bin/rc.startjob <jobname>
I'm trying to capture return codes from the rc.startjob script, but more importantly from the "ba6.1 ttaad5203m000" command within it. I want to know if my call to execute the job was successful or not. It states in the rc.startjob script that a variable, BSH_JOBOK, will get updated with the characters "OK" if the job was successful, I can't seem to get this to work. I'm not sure if this is what I should even be using.
Any thought?
naabi0
11th April 2002, 23:48
There is a file in the $BSE_TMP called rc.startjoberr that might help.
keithdonn
11th April 2002, 23:58
The contents of the rc.startjoberr file is always:
<
Connecting with bshell...
Connection established.
>
This file really doesn't provide me with a status or return code necessary to tell if the call to execute the BaaN job was successful or not. Thanks for the input.
patvdv
12th April 2002, 08:20
Keith,
If you find the return code in BSH_JOBOK unreliable then I would recommendend checking the job status by executing a SQL query directly on your database from within a shell script or similar. The job history tables (ttaad510-ttaad512) would be the best candidates for this.
In the end the solution may look clumsy but reliable. Unfortunately by default Baan does not provide any good job monitoring/reporting tools.
kimmda1
16th April 2002, 14:07
you could customize an rc.start script to call a particular job daemon, bsp will still be the user but the process will be identified by the daemon name. This will make the tracking of the process via command line much easier. This way you can quickly isolate your process and verify that it is getting time from the cpu's and proper priority for the process. If you have a job with multiple sessions, the session that is currently running will not show up in baan job history, that is one way to determine the current active session of the job.
pjohns
17th April 2002, 10:48
When I took over the admin of the company's Baan system I inherited the following way to run and log jobs from Cron.
1. Cron runs a batch file (example below)
BSE=/baan/bse
BSE_TMP=$BSE/tmp
#BAMODE=1
#DS_SERVER=ba
PATH=$BSE/bin:$PATH:.
export PATH
#export BAMODE DS_SERVER
export BSE BSE_TMP
TERM=vt100
export TERM
BAAN_EXTJOB=1
export BAAN_EXTJOB
$BSE/etc/rc.startjob EDICOM /baan/bse/log/log.edicom
I must admit I'm not sure what some of the lines mean. Perhaps somebody could enlighten me?
2. A log the gets written with the following:-
bpid:27466
sess:tcedi7205m000
sesn:1
info:EDI Communication - 501
comp:501
stim:20020417080500
usti:20020417070500
etim:20020417080500
ueti:20020417070500
ssta:OK
jsta:OK
ericthomas
22nd April 2002, 16:44
bpid:27466 baan process id
sess:tcedi7205m000 Which session
sesn:1 session sequence
info:EDI Communication - 501
comp:501 Company Number
stim:20020417080500 Start Time
usti:20020417070500
etim:20020417080500 End Time
ueti:20020417070500
ssta:OK Session status
jsta:OK Job status
These must be field names from Job Management tables!
keithdonn
23rd April 2002, 21:03
:D
Thanks for the input. I was able to get the logging to work using the BAAN_EXTJOB variable. I export the variable in the profile of the user(s) I need the log information from. Now, if I could just get BaaN to write to the log as soon as I execute the rc.startjob command I would be all set. (there's a couple second lag time depending on system load; nothing I can't work around)