CAWA DE: Set Job to Success when Completion Code is 9

[FernandoB Romero]

I have a job which fails with a completion code of "9".

 

     Completion code(if applied): 9

I set an exit code interpretation of 9=Success as shown below:

 

However, the job still fails and sends out alert (since we define a notification for suberror/failure).

In the details of the job, the status indicated is Aborted, Signal 9 as shown below:

 

 

 

 

Is there a way we can prevent this job from failing and set it to success?

[Anon Anon]

Hi Fernando,

 

Are you sure that your script is returning exit code of 9?  It appears that the process was aborted with signal 9 winch is different from exit 9.  I don't believe you can trap SIGKILL (signal 9), and the process would terminate.  Is there a reason why the process is receiving a signal 9?

 

Regards,

Pradeepan Gunabalasingam

[FernandoB Romero]

The email notification indicates a completion code of 9 as shown below:

 

Job M6_SPECIAL of application METASOLVE_REPORTS.1 is in
FAILED state.

Agent name: NH1C4P01

Completion code(if applied): 9

 

We are still checking with the owner of the jobs to see why it is encountering SIGKILL.

[Anon Anon]

Hi Fernando,

 

I did a quick test on my linux box and when I issued the kill -9 for a running process, the exit code was 137.  I am not sure where the exit code of 9 is being picked up from.  It might be the way your email notification is defined.  Since you have defined exit code 9 to be success, it should not trigger the alert.  However, your jobs is in the failed state, therefore it is triggering the alert, which makes me believe the server never received a return code of 9.  One way to check this is to see the AFM message sent back from the agent.  You can find this in the agent's transmitter.log.  If you find the agent did indeed send exit code 9 back to the server, I would recommend that you open a ticket with CA support and attach both the DE server log and the agent logs.

 

[root@gunpr01-I159100 ~]# ./mytest.sh

[root@gunpr01-I159100 ~]# echo $?

0

[root@gunpr01-I159100 ~]# ./mytest.sh

Killed

[root@gunpr01-I159100 ~]# echo $?

137

[root@gunpr01-I159100 ~]#

 

Regards,

Pradeepan Gunabalasingam

[FernandoB Romero]

In the transmitter logs I am able to see the following:

 

06/03/2016 10:00:02.475 EDT-0400 2 TCP/IP Controller Plugin.Transmitter pool thread <Regular:1>.CybTargetHandlerChannel.call[:776] - Message has been sent: 2016

0603 10000241+0400 PRIMARY ******* M6_SPECIAL/METASOLVE_REPORTS.3/MAIN State FAILED Cmpc(9) SetEnd Status(Aborted, Signal 9) JobLogId(2783DE0D9329E9C2D93B18173

361110C54D1FD4D)

 

I actually logged a ticket to CA support and I was told the following:

 

As per agent development, "this is the way the agent behaves. The agent will [make] an OS system call to determine if the process exited normally.  If it exited abnormally, as is the case when a signal is thrown, the code sets the response
to FAILED.  The exit codes are not evaluated to determine success or failure this is only done if the job terminates normally".

[Anon Anon]

Thanks for the update Fernando,

 

We discussed this with our dSeries development team this morning, and the feedback you received from the agent team is accurate.  I was under the assumption that dSeries processed the return code to determine job status, but it turns out dSeries delegates this to the Agent by passing all the return codes it considers success.  It order for a job to be marked successful, the AFM returned by the agent must be marked as success.

 

HTH

Pradeepan Gunabalasingam