Exit code issue - Testing upgrade from 3.4.25b - 3.6.5

Hey there,

We're looking at upgrading, and have installed the new version as required. All batch jobs are being processed correctly, but are logging errors within event log even when exiting successfully.

All of the jobs in our queue use an exit code of 1, and the application is set to recognise this as successful, but when the job completes 24x7 logs an event log error. The only way around this we've found is to change the exit codes of each individual job to 0 and the successful exit code.

Can you offer any advice on how to resolve this outside of the solution above? With the number of jobs in question this isn't a viable solution.

Please post relevant fragment of your schedule.log file so we can see what's being logged during job runs.

17/12/2009 12:55:02.421 0 168 0 ClsCapChk.I3 Job started.
17/12/2009 12:55:17.656 1 168 0 ClsCapChk.I3 Process finished with exit code 1
17/12/2009 12:55:17.718 0 168 0 ClsCapChk.I3 Job finished.
17/12/2009 12:55:17.921 2 168 0 ClsCapChk.I3 Process finished with exit code 1
17/12/2009 12:55:18.000 1 168 0 ClsCapChk.I3 Job has been disabled!

And job "ClsCapChk.I3" has exit code condition check enabled and 1 is set as the successful exit code. Is that correct?

And in that situation the scheduler ignores 1 as the successful exit code and still disables the job as if it failed. However if you set the successful exit code condition to 0, the scheduler ignored job exit code 1 and threats this job as successful. Did I get it correctly?

Additional questions, does this job run any notification actions on successful completion? on error? If yes, are they processed successfully? Is the job currently set to run detached? If yes, does setting the job mode to non-detached fixes that behavior?

If you set the successful exit code condition to 0, 24x7 treats this job as failed and disables the job.

Jobs are 'Detached'. Running them 'Attached' seems to resolve the issue. Can you help me understand why this is the case?

Last edited by JWUser on Thu Dec 17, 2009 5:18 pm; edited 1 time in total

I'm unable to explain this effect. I suspect this could be a job database file conversion bug. You now know what to do to fix the job running - please change these jobs to non-detached.

Before you fix them, please make a copy of your job database file as it is right now, and send it to support. We will try to reproduce the described issue, possible run this code in a debugger and find out the reason.

Making this change will require a large amount of regression testing due to the fact the issue is present in all jobs.

Is there a quicker way of modifying the job database than going through the GUI?

One thing to note: this issue was apparent when creating new jobs, so it may not be caused by job DB corruption etc.

Sure. If you want to change this property for every job, you can write a few lines JAL script job getting the job list and modifying DETACHED property of every job. See "JobList" and "JobModify" topics in the on-line help. Click the Examples button to copy and paste the code.

You can also make an external VBScript macro or Excel macro or other macro that can use 24x7 COM interface to do the same thing from outside.

I believe that this is a bug with the latest version of 24x7 and has nothing to do with our OATIS.DAT job database. In fact I tried the following tests using the OATIS.DAT database and a new job database and got the same results.

If I create a job as follows:

Name: Test
Job: Run program or Document File

Command Line: cmd /C "exit 1"
Run In: C:\
Successful Exit Code: 1
Detached: Yes

This job will always exit with an exit code of 1 but 1 is set as a successful exit code so this will be OK and the job should not be disabled.

Running this job does give the Warning and Error “Test: Process finished with exit code 1” in the event log and it the job gets disabled.

The only way I can get it to behave as needed is to produce an exit code of 0 and set the job to expect 0 as a successful exit code.

This would indicate that it is not an issue with the .dat we are using (this was created in a new job database).

I had this issue escalated to the development. We are looking into this.

Can I please get an update on the status of this issue?

A fix for this issue is being currently tested.. It should be available in the next maintenance release, for which an ETA is not known at this time.
The fix can be also provided to you by the end of the week as a private build. Please let us know if you want it.

An intermediary build would be much appreciated so we can add it into our testing schedule. Do you think there's a chance that your next MR will be public by mid March?

	Quote:
	Do you think there's a chance that your next MR will be public by mid March?

There is a very good chance it will be available sooner.

I'll have private build arranged for you tomorrow with a fix for exit code handling in detached program type jobs.

Excellent, thanks for that. Is much appreciated.