Tracking Status of Execute Activity

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
avi21st
Charter Member
Charter Member
Posts: 135
Joined: Thu May 26, 2005 10:21 am
Location: USA

Tracking Status of Execute Activity

Post by avi21st »

Hi

I need to trap the status of execute Activity (shell script in my case) in case of failure and then mail out the status.
Using Datastage Job control can we trap the Status of the Shell and the use DSSendMail to mail the log for that execute Activity.

I think DSGetJobInfo would not get me the information. Could if please suggest what to use in this case?

Any help or tips are most welcome.
Avishek Mukherjee
Data Integration Architect
Chicago, IL, USA.
DSguru2B
Charter Member
Charter Member
Posts: 6854
Joined: Wed Feb 09, 2005 3:44 pm
Location: Houston, TX

Post by DSguru2B »

A simple way is to have another shell to check the result of the first shell. If the result is created or valid meaning that it ran, then with conditions you can just mail out the status.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
avi21st
Charter Member
Charter Member
Posts: 135
Joined: Thu May 26, 2005 10:21 am
Location: USA

Post by avi21st »

DSguru2B wrote:A simple way is to have another shell to check the result of the first shell. If the result is created or valid meaning that it ran, then with conditions you can just mail out the status.

I need it to be handled together with the datastage jobs....

Say I have the Job Sequencer as

Code: Select all

Shell--yes->DS job--yes-->DS job--yes-->Shell --yes-->Email
  !             !             !            !                  
  !             !             !            !                   
  V             V             V            V                     
  ********** S   E  Q U E N C E********************* -----> Email
So I cannot handle Shell and Datastage error seperately.

I need the same email (Job control routine) to handle both success and failure.
Avishek Mukherjee
Data Integration Architect
Chicago, IL, USA.
avi21st
Charter Member
Charter Member
Posts: 135
Joined: Thu May 26, 2005 10:21 am
Location: USA

Post by avi21st »

Hi

Another question:

I saw that we have-

#ExecuteActivityName.$CommandName#
#ExecuteActivityName.$CommandOutput#
#ExecuteActivityName.$ReturnValue#


Can we somehow use them in the job control routine to send out success or failure email.

Say I am using the folowing code to get the current job name from where the routine is called:

Code: Select all

* ----------------------------------------------------------------- 
* Get the  Job name from the called Job
* ----------------------------------------------------------------- 

JobName= DSGetJobInfo(DSJ.ME,DSJ.JOBNAME)

then attach the job:

AttachedJob = DSAttachJob(JobName, DSJ.ERRNONE)

and another to get status:

Status= DSGetJobInfo(AttachedJob,DSJ.JOBSTATUS)

Should I get the Execute Activity name if it calls my job control routine to send out the email. Also should all the DSAttachJob and DSGetJobInfo work for Execute Activity??

Please help :cry:
Avishek Mukherjee
Data Integration Architect
Chicago, IL, USA.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

I need the same email (Job control routine) to handle both success and failure.
Write it as a transform function and invoke it through a Routine activity.

Should I get the Execute Activity name if it calls my job control routine to send out the email?
No. Use separate Notification activities, or provide a hard-coded argument to the routine activity.

Also should all the DSAttachJob and DSGetJobInfo work for Execute Activity??
No. These are intrinsic to the product, and can be invoked only from DataStage BASIC (that is, within a Routine). Execute Command activity invokes an operating system command.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Post Reply