Hello All;

Running Triton 3.1 (port 6.1b.05.01) on a HPUX 11.0 box;

I have logged a case with Baan support on the issue and while they have provided me all the "latest" objects, I am still having problems with the job daemon hanging from time to time. Their last resort answer is "upgrade the porting set".

Typically, I'll get a couple weeks out of the job daemon before it'll hang again. When it does hang, stoping/restarting doesn't always work, and it's likely to die again within a week of restarting it (if it does restart properly).

For example, it died last Friday, I rebooted the server on the weekend, and it died again last night.

At baan's insistance, I have replaced the rc.startjobdm & rc.stopjobdm scripts. rc.stopjobdm never works. I've asked baan to investigate but they haven't been helpfull - "upgrade the porting set"

I have also replaced the objects with the latest (according to baan):

ostpsplopen
ostpsplclose
ostprepdll
ottstpconv
ottaad5203
ottaad5206

I may have loaded others, but off the top of my head I can't remember what. I believe these are the core objects required.

If anyone has any ideas other then "upgrade the porting set", I would greatly appreciate it. When the job daemon dies, it mucks the entire day up since the night jobs (ie DRP/MRP/PRP) take 4 times longer when users are in the system.

*************************

I am also curious about running sessions from the command line (ie: ba6.1 trdrp0212m000).

I wonder if I could invoke sessions like DRP/MRP/PRP from crontab - except I can't find any documentation on how to pass the arguments required to complete the form fields.

I searched the forum yesterday and found there was lots of information on ba6.1 but no examples of passing the form fields.

If anyone could help me with this - I may investigate replacing jobs in the job daemon with sessions manually invoked from the crontab since it's more reliable. (and apparently multithreads better)

Thank you for your help & ideas; anything suggestions is greatly appreciated. If there is information I have neglected to include, please let me know and I'll post it asap.

Thanks again.

Hello,

Is your job daemon hanging/stopping or the session you schedule?

if it is the session is the session running normal out from the job?

Deleting application locks of the job daemon can cause to stop the daemons.



Caner

Caner

Thanks, I neglected to mention:

Yes, the sessions run fine outside of the scheduled job.

It's definately the job daemon hanging - it hangs on various jobs and not always the same job.

Typically the jobs that hang contain sessions that take longer (30mins to 1 hour) to run.

We do not delete the jobdm application lock until we run rc.stopjobdm and it fails.

Thanks again.

We found a lot of problems with running the job scheduler for many jobs. Especially if one crashes. Instead we directly call jobs as unix cron job. This take much better use of OS and they work faster and more reliable.

Below is example cron job and script

In addition we have added customizations that will warn if a job fails and automatically emails. Let me know if you are interested and I will provided


# BAAN - Nightly Finance Jobs
00 19 * * 0-4 /usr/local/bin/db.cron /baan/bse/etc/rc.startjob FIN001 batch
50 5 * * 1-5 /usr/local/bin/db.cron /baan/bse/etc/rc.startjob ACR001 batch

##### DB-SVR BAAN JOBS
# BAAN - PURCHASING REPORTS ETC
30 3 * * 1-5 /usr/local/bin/app.cron /baan/bse/etc/rc.startjob PRP001 batch
40 3 * * 6 /usr/local/bin/app.cron /baan/bse/etc/rc.startjob PRP002 batch
0 5 * * 1-5 /usr/local/bin/app.cron /baan/bse/etc/rc.startjob MRP001 batch
15 5 * * 1-5 /usr/local/bin/app.cron /baan/bse/etc/rc.startjob PUR001 batch
0 1 * * 1-5 /usr/local/bin/app.cron /baan/bse/etc/rc.startjob ILC001 batch
0 1 * * 6 /usr/local/bin/db.cron /baan/bse/etc/rc.startjob INV001 batch
0 22 * * 2,4 /usr/local/bin/db.cron /baan/bse/etc/rc.startjob SLS001 batch

==============================================

#set -xv # uncomment for debug
# rc.startjob, should be located in $BSE/etc
# version 94/06/29 (Erwin Derksen)
# * added setting of TERM to this file
# version 94/04/21 (initial version)
#
# script to start a job in the background
# BAMODE=1 : No output to screen.
# Be sure to define the BSE, BSE_TMP and PATH variable, because when started
# from the crontab these variables often are not defined

BSE=/baan/bse
BSE_TMP=/baan/bse/tmp
export BSE BSE_TMP
PATH=$BSE/bin:$PATH
export PATH

# It turned out that the TERM variable could be unset when running in a cron
TERM=vt100 ;export TERM

# If you want to use several companies you can create several users for e.g.
# root who probably is running this script. If so, copy this script and use
# the next line to define the USER variable (<root100> is just an example).
#USER=<root100> ;export USER
#NN 2/20/01 Set user to second parameter
USER=$2 ;export USER

if [ $# -lt 2 ];then


echo "Usage : rc.startjob <jobname> <baanuser>"
exit 1
fi
if [ $1 = "-U" -o $1 = "-u" ];then
echo "Usage : rc.startjob <jobname> [jobok_file]"
exit 1
fi

#jobok_file contains the characters "OK" if the job was successful !
#If jobok_file is not specified, then output is written to $BSE/tmp/job

BAMODE=1 ;export BAMODE
DS_SERVER=ba ;export DS_SERVER
BSH_JOB=$1 ;export BSH_JOB

#Always write to $BSE/tmp/job
#if [ $# -gt 1 ];then
# BSH_JOBOK=$2 ;export BSH_JOBOK
# echo $BSH_JOBOK
#fi

ba6.1 ttaad5203m000 2>${BSE_TMP}/rc.startjoberr

Seach for more information about jobs in the tools section.
Defenetely using cron to schedule Baan jobs is way more reliable that the jobdaemon.
- Disable the jobdaemon
- Keep your existing Baan job setup as normally but set the period to a smaller value than the jobdaemon schedule (you can even set it to 1 minute)
- Then setup the rc.startjob (or similar like mentioned in the previous reply) and set them in the cron of the job user.

The cron will do the same as the jobdaemon, the rest is the same as previoulsy, just have to remember to keep that period small than the old schedule.

Ok:

I checked my rc.startjob script to find it was the same minus the USER temp variable (so I added it)

I also picked a quick simple job to test with and changed the period to "1 minute".

I stopped the job daemon and tried invoking the script from the command line. (to test prior to adding it to the crontab)

It seemingly did not work.
The $BSE_TMP/rc.startjoberr reads:

Connecting with bshell...
Connection established.

The job did not run according to history (ttaad5511m000).
I have tried invoking it with the job both "In Queue" and "Free".

Any ideas of what I might be doing wrong?

nneilitz - I'd like to see your db.cron & app.cron scripts and any other information you might have to add.

thanks

yes,

sorry about that. We run in a service guard environment and these are just a crude way of letting me keep the crontabs in sync between the two server. they really just run the /baan/bse/etc/rc.startjob script

SYSTEM=`hostname`
APPSVR=`cmviewcl -p app-pkg |tail -1 | awk -F " " '{print$5}'`
DBSVR=`cmviewcl -p svr-pkg |tail -1 | awk -F " " '{print$5}'`
if [ "$DBSVR" = "$SYSTEM" ]
then
echo "DB"
$1 $2 $3 $4 $5 $6 $7 $8 $9 $10
fi

What status does the job show in the system, if it is waiting then you will need to cancel and set the next execution date / time before current date and time. Also make sure jobs are marked "periodically" with one minute as previously suggested. Status should be "free"

Also...

No job waiting after execution.

Note, you probably are close, I get the same message in rc.startjoberr when the job runs

nneilitz;

The status of the job was 'Free'. It hadn't executed yet.
As I said, the 'Period' was set to "1 Minute" and 'Periodical' was set to "Yes". The job daemon is deactivated.

I received that message however the job does not seem to run or appear as if it had looking in job history.

If the job daemon was active, and I called rc.startjob, the job would activate and then go to status "Waiting" when it was complete. I couldn't get it to run otherwise.

Maybe I'm missing something here; Ideas?

What about Automatic Repeat?

You can run ttaad5203m000 from the main menu (this is what the job does". If job is "waiting", the execution date/time is after current date and time. Cancel the job and set next date/time before current date and time

Ok;

I realize calling rc.startjob is the same as running the session ttaad5203m000. I also knew that that's how the job daemon invoked a job. My problem isn't with this.

According to what I've caught off this thread, the steps for running a job from the command line or a cron job are as following:

1. Deactivate the job daemon completly.
2. Set desired job as "Free" with Periodical = "Yes" and Period = "1 Minute".
3. Start the job - by calling rc.startjob or running ttaad5203m000.

When I was piloting this, I found that trying to start the job, it would appear like it should work, but then the job doesn't seem to execute (I can't see it as "Running" when looking at the job), and there's no history of it running in ttaad5511m000.

Trying to invoke the job by calling "rc.startjob XMLOUT" appears as if it is working, however, looking at $BSE/log/log.startjob, the last entry is:

+++031804091115 Job: XMLOUT root
Job XMLOUT does not exist
+++031804091115 Job: XMLOUT root

Now - the problem is, there IS a job in ttaad5100m000 called "XMLOUT":

ttaad5100m000 single-occ (1) Form 1-1
-------------------------------------------------
Maintain Job Data Comp : 100
-------------------------------------------------
Job : XMLOUT
Description : XML OUTPUT FOR NAUTILUS
User : rmarles
Creation Date : 03-10-00

Periodical : Yes
Automatic Repeat : Yes
Calendar :
Period : 1 Minutes
Finish Date :

Next Execution Date : 03-18-04 09:51
Maximum Duration : 00:00
Last Execution Date : 03-18-04 05:51
Status : Free

Choice: .
-------------------------------------------------

so - I guess, since it's obvious I'm missing something, what is it?

Now that the job daemon is de-activated, if I goto ttaad5203m000 and pull up the specific job, it runs, goes to waiting and runs again on it's own after a minute.

Thanks.

Finally, some progress;

This is what I've found. I set "Automatic Repeat" to no.
ttaad5203m000 then executes the job and returns it to "Free".

As *myself* (or our job user jobdm), I was then able to invoke rc.startjob xmlout; It ran as if I had called ttaad5203m000 from within a bshell.

When I change to superuser and try to invoke the job (since cron invokes jobs as superuser), the job does not run.

Checking the log file /triton/bse/log/log.startjob I see:

+++031804105948 Job: XMLOUT root
Job XMLOUT does not exist
+++031804105948 Job: XMLOUT root

So I tried changing the USER variable in the rc.startjob script to the jobdm user (same permissions as myself).

Again, as superuser calling rc.startjob xmlout, job again doesn't run, no message in /triton/bse/log/log.startjob this time, but checking /triton/bse/tmp/rc.startjoberr:

Connecting with bshell...
Connection established.
ba6.1: Not authorized to run as user 'jobdm'
Error [main ]: Can't connect to bshell

Ideas?

Thanks.

Sweet;

Success!

Since the root user can't invoke the job using rc.startjob for whatever wierd reason, I created a crontab for the jobdm user (which could).

It seems to be working from the cron scheduler now.

I have moved over all my jobs and will begin watching to ensure everything transitioned smoothly. (They've already started running)

On another note, I created a document explaining my actions so that the others in my team who create jobs will know how to make new jobs now. If someone is trying to get this working, please contact me and I can pass the document over.

One more cron related command (probably a stupid one)

One of my jobs was set to run every 4 hours instead of on the minute/hour/day. Any ideas of how to set up a revolving cronjob?

Thanks for all your help.

0 0,4,8,12,16,20 * * *

As the beginning of line should do it (minutes,hours,
day of month, month,weekdays).

* is all values
comma for multiple values
dash to run all values in between
(i.e. 0-5 in last column would = sunday thru friday. )

I forgot to mention that you should setup a su - <jobuser> ... if you use a root crontab or, best, use the <jobuser> crontab to trigger the jobs.

Regarding MC/SG clusters I build a /etc/cmcluster/run_if_local.ksh with parameters <package> <script> to run scripts only if the package is running and locally. chmod 755 on it to be usable by all and setup the same entries on all nodes crontabs, thus, when the package switches, all works without manual intervention. Like that you avoid making [most of] your scripts cluster aware.

Thanks all for the feedback;

Everything has been running smooth since I made the changeover on Thursday.

Some jobs have been performing even better (less time).

Thanks again.

Hi,

It will be nice if you can share document prepared by you.

Send me an email message or a private message with your email address and i'll send the document.

Hi , I have unix script for to run a JOB of exchange schema which will import the data into ERP LN Tables but i dont know how to link these unix scripts to that job. Anybody could help for this as i am not aware of this shell scripting and LN also?

Hi i saw your post. I was trying to create new job. I created in LN(Infor10.5).
In windows scheduler also i created task and added bat file. In scheduler task history it's showing task completed. But IN LN status is always free. Can u please help how to run job?

can you pls share the Document as we are facing similar issue.Unable to trigger the jobs via crontab

Hi,
can you please share the Document pls.
we are facing similar Kind of issue where our baan IV jobs are not getting triggered via crontab.
This is my personal email id -
nikkijhs1992@gmail.com

Thanks in Advance.