DataStage dsjob command fails to open job and then reports error -1004.
Problem(Abstract)
The DataStage dsjob command reports error for a specific job, even if only requesting job info:
dsjob -jobinfo projectname jobname
ERROR: Failed to open job
Status code = -1004
Resolving the problem
There are 2 primary causes for this error:
- DataStage engine not using default port 31538 in which case the dsjob command requires -server parameter with hostname:port , for example:
dsjob -server myhost:31539 -jobinfo projectname jobname - Permission problem with files in the project directory that prevent the user who ran dsjob command from opening some job files.
Confirm that the DataStage engine is using the default port and if not update the dsjob command to specify the actual port.
If that does not resolve the issue, or if the problem only occurs for specific jobs in a project rather than all jobs, then check the project directory to confirm that all files and directories have the same correct group id and permissions, i.e. dstage group with rwx permission for group.
Most DataStage files (including those in the project directories) are setup initially with ownerid of dsadm and group id of dstage. All DataStage users should be member of group dstage and all files in project directory should have rwx permission for group. If a user tries to run a job for which they do not have read and write access to the files for that job, then the reported error in this technote occurs.
When a user with a different default group than dstage (or whatever group name your site uses as the default DataStage group) creates a job in project directory, the new file is created with that users default group, which could be a group that other users are not a member of. A different user trying to run that job would then fail unless the files also have full public permission or the new user was also in the new group.
If you see files in project directory with different group ids, this is likely the cause of error. In this situation, you could change the group id with a chgroup command (if you use a recursive chgroup command, be sure it is only done for the Project directories and NOT for the InformationServer directory tree).
To avoid further issues with files containing incorrect group, you could give all users the same default group of dstage. Or you could use the setguid command on project directory to set the group id bit. When this bit is turned on for a directory, all files added to that directory will inherit the group id of the directory rather than the default group id of the user creating the file.
Thus if you go to the InformationServer/Server/Projects directory and issue command "ls -l" to list directory, you may see something like this:
drwxrwxr-x 97 dsadm dstage 8192 Mar 11 2013 Project1
drwxrwxr-x 599 dsadm dstage 110592 Dec 27 2013 Project2
If you change the directory permission to instead be "drwxrwsr-x" (the s in group permission is the setguid bit) then that will enforce group id for future updates within that directory. If you want to add the setgid bit to a directory under Projects, you can do it like this:
chmod g+s Project1
then do "ls -l" to confirm group permission now shows up as rws instead of rwx.