Troubleshooting
Problem
DataStage and QualityStage 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.
Cause
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.
Resolving The Problem
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. Job object locks can exist on both the engine tier, and in the xmeta repository.
For users of DataStage 8.x and 9.1, xmeta locks on job objects can be cleaned up using the cleanup_abandoned_locks.sh command in the /opt/IBM/InformationServer/ASBServer/bin directory.
For Information Server 11.x and later, this command is replaced by the xmetaAdmin.sh command. For more details using these commands to unlock job objects in xmeta repository, refer to the following technote:
Unlocking XMETA locks from jobs
Locks can also exist on the DataStage engine tier. Use the following steps to check for and remove engine tier locks.
(NOTE: you can also stop and restart the DataStage engine, which will release all engine tier locks, but not xmeta locks)
- Telnet into your Unix machine where DataStage Server is installed and login with DataStage admin id (i.e. "dsadm" or "root").
- 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"
- Enter ". ./dsenv" (i.e .space./dsenv) to source the dsenv file.
- Enter "bin/uvsh".
- Enter "LIST.READU EVERY" at the prompt ">" . Check active record locks under "Item Id" column for job name.
- Write down the inode number and user number for the lock that is not a valid lock.
- Execute the following commands:
LOGTO UV
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:
"LIST.READU EVERY". - Type Q to exit.
The above combination of actions usually resolves this issue. If the error does still occur, re-check the LIST.READU EVERY output in case there were multiple files associated with the job which were locked. If the error persists, then also check whether there are any orphan dsapi_slave or uvsh processes which were associated with DataStage client sessions or jobs that are no longer active. If so those processes may also need to be killed if they are holding file system locks for any job files.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21397961