Hi!
I have a problem running batch job. As my title says, I have scheduled some jobs and it all has turned to the green status after executing, but after verification, the .bat which was called wasn't executed. So, why does it has turned to ended-ok?
Any idea?
Thanks!
Batch ended-ok even if .bat hasn't run
Here it is:
cls
DEL D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_deferred.LOG
echo Tue 01/12/2010 @ 9:19:00.78 1>D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A6\
70\logs\PSEXEC_deferred.LOG
ag_diag_comm 1>>D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_defer\
red.LOG
c:
rem psexec \\172.21.21.144 -u INTRO\emuser -p Admctrlm08 -d "D:\was\runtime\Sta\
rt_Deferred.bat" /accepteula 2>>D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\lo\
gs\PSEXEC_deferred.LOG
psexec \\172.21.21.144 -d "D:\was\runtime\Start_Deferred.bat" /accepteula 2>>D\
:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_deferred.LOG
echo Tue 01/12/2010 @ 9:19:01.90 -commande deferred exécuté 1>>D:\BATCH_DEPOT\
\Acceptation\TRAITEMENT_Q3A670\logs\Q3A670.log
exit /B
Job Object statistic
====================
Total User CPU Time: 0.188 second
Total Kernel CPU Time: 0.453 second
This Period Total User CPU Time: 0.188 second
This Period Total Kernel CPU Time: 0.453 second
Total Page Fault Count: 8881
Total Processes: 9
Active Processes: 0
Total Terminated Processes: 0
Total peak job memory used: 12.005 mega bytes
-----------
So, our batch call an executable. Do you think that this is the problem? Because when we double click on the .bat, everything's ok.
Thanks again!
cls
DEL D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_deferred.LOG
echo Tue 01/12/2010 @ 9:19:00.78 1>D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A6\
70\logs\PSEXEC_deferred.LOG
ag_diag_comm 1>>D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_defer\
red.LOG
c:
rem psexec \\172.21.21.144 -u INTRO\emuser -p Admctrlm08 -d "D:\was\runtime\Sta\
rt_Deferred.bat" /accepteula 2>>D:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\lo\
gs\PSEXEC_deferred.LOG
psexec \\172.21.21.144 -d "D:\was\runtime\Start_Deferred.bat" /accepteula 2>>D\
:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_deferred.LOG
echo Tue 01/12/2010 @ 9:19:01.90 -commande deferred exécuté 1>>D:\BATCH_DEPOT\
\Acceptation\TRAITEMENT_Q3A670\logs\Q3A670.log
exit /B
Job Object statistic
====================
Total User CPU Time: 0.188 second
Total Kernel CPU Time: 0.453 second
This Period Total User CPU Time: 0.188 second
This Period Total Kernel CPU Time: 0.453 second
Total Page Fault Count: 8881
Total Processes: 9
Active Processes: 0
Total Terminated Processes: 0
Total peak job memory used: 12.005 mega bytes
-----------
So, our batch call an executable. Do you think that this is the problem? Because when we double click on the .bat, everything's ok.
Thanks again!
- nicolas_mulot
- Nouveau
- Posts: 149
- Joined: 07 Jan 2010 12:00
Diablau,
The sysout does exist, so we can assume that the .bat specified in the job did run.
We can imagine that the one which did not execute is actually D:\was\runtime\Start_Deferred.bat.
Whichever the rc of the psexec can be, the subsequent echo and exit /B will always return a RC=0, and the job will always finish OK.
You can verify this by typing any unexisting command in the .bat coded in your job. Despite any insult you could see in the sysout, such as “dqsdgqsj is not recognized as an internal or external command etc..”, the final RC will be 0.
I checked that an exit /B <RC> always returned a COMPSTAT 0 for controlm jobs, whichever the value of <RC> can be. Exit <RC> is preferable, since the value of <RC> will be interpreted as the COMPSTAT for the controlm job.
First, add an echo %ERRORLEVEL% right after your psexec.
If a significant value is displayed, use it as follows:
psexec \\172.21.21.144 -d "D:\was\runtime\Start_Deferred.bat" /accepteula >>D\
:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_deferred.LOG
set PSEXECRC=%ERRORLEVEL%
echo Tue 01/12/2010 @ 9:19:01.90 -commande deferred exécuté >>D:\BATCH_DEPOT\
\Acceptation\TRAITEMENT_Q3A670\logs\Q3A670.log
exit % PSEXECRC%
If no significant value is displayed, there is probably an error message in the psexec log you store. You can then TYPE it in your calling batch, so it appears in the job’s sysout.
From there, you can intercept the event thru ON STMT CODE and force a NOTOK status by DO NOTOK.
Cheers
Nicolas_Mulot
The sysout does exist, so we can assume that the .bat specified in the job did run.
We can imagine that the one which did not execute is actually D:\was\runtime\Start_Deferred.bat.
Whichever the rc of the psexec can be, the subsequent echo and exit /B will always return a RC=0, and the job will always finish OK.
You can verify this by typing any unexisting command in the .bat coded in your job. Despite any insult you could see in the sysout, such as “dqsdgqsj is not recognized as an internal or external command etc..”, the final RC will be 0.
I checked that an exit /B <RC> always returned a COMPSTAT 0 for controlm jobs, whichever the value of <RC> can be. Exit <RC> is preferable, since the value of <RC> will be interpreted as the COMPSTAT for the controlm job.
First, add an echo %ERRORLEVEL% right after your psexec.
If a significant value is displayed, use it as follows:
psexec \\172.21.21.144 -d "D:\was\runtime\Start_Deferred.bat" /accepteula >>D\
:\BATCH_DEPOT\Acceptation\TRAITEMENT_Q3A670\logs\PSEXEC_deferred.LOG
set PSEXECRC=%ERRORLEVEL%
echo Tue 01/12/2010 @ 9:19:01.90 -commande deferred exécuté >>D:\BATCH_DEPOT\
\Acceptation\TRAITEMENT_Q3A670\logs\Q3A670.log
exit % PSEXECRC%
If no significant value is displayed, there is probably an error message in the psexec log you store. You can then TYPE it in your calling batch, so it appears in the job’s sysout.
From there, you can intercept the event thru ON STMT CODE and force a NOTOK status by DO NOTOK.
Cheers
Nicolas_Mulot
Thanks all!
While you were answering me, I've found a solution. Because the executable was run by the agent on another server (without agent), I had to add the service account of my agent in the group admin of the server on which the executable run. That was as simple as this. I'll keep your suggestions anyway, maybe I will need it later.
Thanks again!
While you were answering me, I've found a solution. Because the executable was run by the agent on another server (without agent), I had to add the service account of my agent in the group admin of the server on which the executable run. That was as simple as this. I'll keep your suggestions anyway, maybe I will need it later.
Thanks again!