We have moved to www.dataGenX.net, Keep Learning with us.

Wednesday, April 03, 2013

DataStage client receives error when compile jobs: Cannot get exclusive access to executable file for job sampleJob - job may be being monitored

Problem :

DataStage user sees the following error in Designer client when attempting to compile a specific job:
Cannot get exclusive access to executable file for job sampleJob - job may be being monitored.

Similar problems may occur in other releases.

Solution :

This message occurs when a job is locked either by a user or a running process. The job locks occur when user is editing job in Designer, or job is running. If the user connection is broken or if the server process terminates unexpectedly, the locks may remain enabled.

Confirm that no other user is editing the job and that the job is not currently running. If you still get the compile error when nobody else is using the job, then you can use the following steps to remove the job locks.

For users of DataStage 8.x, a script has been provided to assist with cleanup of locks. Login to the DataStage server with the DataStage administrator id and run the following script:

This script resides in the ASBServer/bin directory, for example:

If using DataStage 7.5.x, then you can instead use the following steps to cleanup these locks:

  1. Telnet into your Unix machine where DataStage Server is installed and login with DataStage admin id (i.e. "dsadm" or "root").
  2. Change directory to the DataStage home directory. If you are not sure where the home directory is located, check root directory for a .dshome file, i.e.: "cat /.dshome"
  3. Enter ". ./dsenv" (i.e .space./dsenv) to source the dsenv file.
  4. Enter "bin/uvsh".
  5. Enter "LIST.READU EVERY" at the prompt ">" . Check active record locks under "Item Id" column for job name.
  6. Write down the inode number and user number for the lock that is not a valid lock.
  7. Execute the following command:
    "UNLOCK INODE inode# USER user# ALL".
    This will unlock the lock held on this file (inode#) and held by this user (user#) for file locks, group locks and record locks. If you need to see all the locks again, enter:
  8. Type Q to exit.

If the above step does not solve the problem, then another option is to try the following:
  1. Using DataStage Designer client, save the job with a new name, then compile the copy and see if it compiles without error.
  2. If the new copy compiles, then you can manually delete the old job by logging into DataStage Administrator client, select the project, then click on Command button and execute command: DELETE DS_JOBS OldJobName
  3. You can now rename the copy back to original job name.