cannot open executable job file
Moderators: chulett, rschirm, roy
cannot open executable job file
Hi all!
Can someone tell me how to solve the problem identified by the following error message?
"cannot open executable job file RT_CONFIG1344"
That issue hasn't high priority; any help would be appreciated.
Thanks a lot in advance
Can someone tell me how to solve the problem identified by the following error message?
"cannot open executable job file RT_CONFIG1344"
That issue hasn't high priority; any help would be appreciated.
Thanks a lot in advance
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
This is a strange error message in that RT_CONFIG1344 is not executable; it's a configuration file that describes an executable job! Maybe that's another area where the terminology could stand a little more clarity!
That it can't be opened usually means that it's been removed, that its permissions have been changed (or you're trying to open it as a different user than its creator, and its creator's umask was too tight), or that the internal structure in RT_CONFIG1344 is damaged in some way.
In all cases the easiest way to work around the problem is to export the job in question, then import it into the same project. That way it will get a new job number (and a new RT_CONFIGnnnn, where nnnn is the new job number).
You could, of course, spend time analysing exactly what's wrong and trying to repair that, but it's probably not time well spend unless you have some degree of familiarity with the underlying <<database formerly known as UniVerse>>.
That it can't be opened usually means that it's been removed, that its permissions have been changed (or you're trying to open it as a different user than its creator, and its creator's umask was too tight), or that the internal structure in RT_CONFIG1344 is damaged in some way.
In all cases the easiest way to work around the problem is to export the job in question, then import it into the same project. That way it will get a new job number (and a new RT_CONFIGnnnn, where nnnn is the new job number).
You could, of course, spend time analysing exactly what's wrong and trying to repair that, but it's probably not time well spend unless you have some degree of familiarity with the underlying <<database formerly known as UniVerse>>.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Ensure that your DataStage startup script is using the correct umask value.
If you do not do this, anything created by a an user would be inaccessable by different users.
Go inside your Projects folder, and that particular project, and take a look at how the privs are. If it is something like:
-rwxr-x--- [specific user] dstage [blah blah blah]
Then the issue is your umask. Go to "cat /.dshome" directory, then to the "sample" subdirectory, and take a look at ds.rc script. Near the top, the "#umask 002" should be seen. Set it as "umask 002", or as I prefers "umask 007".
For those who do not know "umask", it is the opposite of "chmod" in its handling of UNIX priveledges. With chmod, you're giving privs. With umask, you're taking away privs. The problem is that UNIX administrators may have set a more restrictive value (047 to produce the type of file privs described above) than what DataStage needs. At a bare minimum, you need 700 privs for a single user environment, 770 for a group environment.
-T.J.
If you do not do this, anything created by a an user would be inaccessable by different users.
Go inside your Projects folder, and that particular project, and take a look at how the privs are. If it is something like:
-rwxr-x--- [specific user] dstage [blah blah blah]
Then the issue is your umask. Go to "cat /.dshome" directory, then to the "sample" subdirectory, and take a look at ds.rc script. Near the top, the "#umask 002" should be seen. Set it as "umask 002", or as I prefers "umask 007".
For those who do not know "umask", it is the opposite of "chmod" in its handling of UNIX priveledges. With chmod, you're giving privs. With umask, you're taking away privs. The problem is that UNIX administrators may have set a more restrictive value (047 to produce the type of file privs described above) than what DataStage needs. At a bare minimum, you need 700 privs for a single user environment, 770 for a group environment.
-T.J.
Developer of DataStage Parallel Engine (Orchestrate).
Well, then at first glance it doesn't appear to be a permissions issue.
Refer back to Ray's post and try the export/import trick. As he said, this would assign it a new Job Number and (hopefully) solve any issues with corrupted information in the job. You may need to delete the job in between the export and the import... not sure.
Refer back to Ray's post and try the export/import trick. As he said, this would assign it a new Job Number and (hopefully) solve any issues with corrupted information in the job. You may need to delete the job in between the export and the import... not sure.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Good...
We are finally arrived at the problem's core.
I try to delete the job and i receive:
Cannot open executable job file RT_CONFIG1344
I try to export the job and i receive:
Cannot open executable job file RT_CONFIG1344
and then appears a window with the abort/skip button and with the following message: "Failed to attach to job..... This job is possibly in use by another user"
I have made a shutdown and a startup of the server. Nothing was changed from that i described while trying to export
We are finally arrived at the problem's core.
I try to delete the job and i receive:
Cannot open executable job file RT_CONFIG1344
I try to export the job and i receive:
Cannot open executable job file RT_CONFIG1344
and then appears a window with the abort/skip button and with the following message: "Failed to attach to job..... This job is possibly in use by another user"
I have made a shutdown and a startup of the server. Nothing was changed from that i described while trying to export
Go to your DS Admin window and execute the command
and look at the output. If you get a message like:
then it means that the internal pointer file ("VOC") does not contain a pointer to this hash file (RT_CONFIG1344) and no matter what you do you can see this file.
Look on this forum for how to get to the command line of your project. You will do something like:
Then, you will have to manually create this file pointer. Do the following:
You should do an export immediately and then reimport the job to clean everything up.
Code: Select all
LIST RT_CONFIG1344
Code: Select all
Retrieve: syntax error. Unexpected sentence without filename. Token was "".
Scanned command was LIST 'RT_CONFIG1344'
Look on this forum for how to get to the command line of your project. You will do something like:
Code: Select all
cd `cat /.dshome`
. ./dsenv
bin/uvsh
logto yourprojectname
Code: Select all
>LIST RT_CONFIG1134
Retrieve: syntax error. Unexpected sentence without filename. Token was "".
Scanned command was LIST 'RT_CONFIG1134'
>ED VOC RT_CONFIG31134 <-- type this in
New record.
----: i
0001= F Ardent DataStage Job File <-- type this in
0002= RT_CONFIG1134 <-- type this in
0003= D_RT_CONFIG <-- type this in
0004= <-- just hit ENTER
Bottom at line 3.
----: FI <-- type this in
"RT_CONFIG1134" filed in file "VOC".
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Your explanation is great.
From the command line of my administrator window i have executed:
LIST RT_CONFIG1344
and i got the message in response
Unable to open "RT_CONFIG1344" file
But, RT_CONFIG1344 is not a file, but a directory as you can see from my previous message.
I would have tried to do everything you suggested me, but i have to stop and wait another little help from you
From the command line of my administrator window i have executed:
LIST RT_CONFIG1344
and i got the message in response
Unable to open "RT_CONFIG1344" file
But, RT_CONFIG1344 is not a file, but a directory as you can see from my previous message.
I would have tried to do everything you suggested me, but i have to stop and wait another little help from you
Okay, so the VOC entry exists. What it is saying is that the VOC entry is pointing to a non-existent hash file.
For a description of hash files and how they look from an OS perspective, read this:
viewtopic.php?t=85364
A Dynamic hash file is really a directory with two binary data files and a hidden ".Type30" file. (See the above url for more explaination.) So, if your VOC entry has a definition for a non-existent hash file (really a directory and two binary files therein), then the problem is with either the:
Now, originally, Ray gave you the absolutely most correct answers and steps to follow, and Teej and Kim and Craig kept coming back to permissions.
Please do the following:
1. Show us the directory path of the project, along with the permission settings on the project (Something like "ls -al /var/opt/datastage/projectsmountpoint"). Kim suggested to confirm that the sticky bits and permissions allow dsadm access to this project.
2. Show us the umask entry in the S99ds.rc script and the last modification date to this script (important for the next step)
You are in a quandry. I hope you have this job checked into version control software somewhere, so that you can easily reclaim the source code. Until you figure out what's going on with this job, you probably will not be able to import the job.
For a description of hash files and how they look from an OS perspective, read this:
viewtopic.php?t=85364
A Dynamic hash file is really a directory with two binary data files and a hidden ".Type30" file. (See the above url for more explaination.) So, if your VOC entry has a definition for a non-existent hash file (really a directory and two binary files therein), then the problem is with either the:
- 1. directory
2. DATA.30 file
30 OVER.30 file
So that the above three exist. They are owned by dsadm, as well as group dsadm. Since you've not been able to resolve the issue, I tried walking thru the internals to make sure nothing was corrupted.That are the permissions set on RT_CONFIG1344:
drwxrwxr-x 2 dsadm dsadm 512 Nov 27 12:36 RT_CONFIG1344
Inside that folder i have:
-rw-rw-r-- 1 dsadm dsadm 0 Nov 27 12:46 DATA.30
-rw-rw-r-- 1 dsadm dsadm 2048 Nov 27 12:36 OVER.30
Now, originally, Ray gave you the absolutely most correct answers and steps to follow, and Teej and Kim and Craig kept coming back to permissions.
Please do the following:
1. Show us the directory path of the project, along with the permission settings on the project (Something like "ls -al /var/opt/datastage/projectsmountpoint"). Kim suggested to confirm that the sticky bits and permissions allow dsadm access to this project.
2. Show us the umask entry in the S99ds.rc script and the last modification date to this script (important for the next step)
You are in a quandry. I hope you have this job checked into version control software somewhere, so that you can easily reclaim the source code. Until you figure out what's going on with this job, you probably will not be able to import the job.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
I still think it's a corrupted hashed file.
In the project environment, where you executed the LIST statement, can you execute this statement, and let us know the result?This will help further diagnosis.
In the project environment, where you executed the LIST statement, can you execute this statement, and let us know the result?
Code: Select all
UVFIXFILE RT_CONFIG1344
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Here you are, kc, the infos you requested:
h3mis279:/app/Ascential/DataStage/interface/RT_CONFIG1344-> ls -al
total 262
drwxrwxr-x 2 dsadm dsadm 512 Nov 27 12:36 .
drwxrwxr-x 4551 dsadm dsadm 118272 Dec 16 17:12 ..
-rw-rw-r-- 1 dsadm dsadm 0 Nov 27 12:36 .Type30
-rw-rw-r-- 1 dsadm dsadm 0 Nov 27 12:46 DATA.30
-rw-rw-r-- 1 dsadm dsadm 2048 Nov 27 12:36 OVER.30
h3mis279:/app/Ascential/DataStage-> ls -l
drwxrwxr-x 4551 dsadm dsadm 118272 Dec 16 16:01 interface
h3mis279:/etc/rc2.d-> ls -l
-r-xr--r-- 2 root other 8986 Sep 4 2002 S99ds.rc
I searched umask command inside the service startup script and i haven't found it.
Anyway, I think you meant to refer to that lines:
------------- Taken from /etc/rc2.d/S99ds.rc -------------
DATER=`date +%y%m%d`.`date +%H%M%S`
SUBFILE1=dstmp.$$.${DATER}A
SUBFILE2=dstmp.$$.${DATER}B
# fixup environment output
chmod 755 ${dshome}/${SUBFILE1}
chmod 755 ${dshome}/${SUBFILE2}
------------- Taken from /app/Ascential/DataStage/DSEngine/dsenv -------------
umask 002
And here is the information requested by ray:
------------- Command output of "UVFIXFILE RT_CONFIG1344" -------------
RT_CONFIG1344/DATA.30 is smaller then uniVerse file header
I see you have a deep knowledge of that software... i'm learning from you some good troubleshooting's actions.
Ty
h3mis279:/app/Ascential/DataStage/interface/RT_CONFIG1344-> ls -al
total 262
drwxrwxr-x 2 dsadm dsadm 512 Nov 27 12:36 .
drwxrwxr-x 4551 dsadm dsadm 118272 Dec 16 17:12 ..
-rw-rw-r-- 1 dsadm dsadm 0 Nov 27 12:36 .Type30
-rw-rw-r-- 1 dsadm dsadm 0 Nov 27 12:46 DATA.30
-rw-rw-r-- 1 dsadm dsadm 2048 Nov 27 12:36 OVER.30
h3mis279:/app/Ascential/DataStage-> ls -l
drwxrwxr-x 4551 dsadm dsadm 118272 Dec 16 16:01 interface
h3mis279:/etc/rc2.d-> ls -l
-r-xr--r-- 2 root other 8986 Sep 4 2002 S99ds.rc
I searched umask command inside the service startup script and i haven't found it.
Anyway, I think you meant to refer to that lines:
------------- Taken from /etc/rc2.d/S99ds.rc -------------
DATER=`date +%y%m%d`.`date +%H%M%S`
SUBFILE1=dstmp.$$.${DATER}A
SUBFILE2=dstmp.$$.${DATER}B
# fixup environment output
chmod 755 ${dshome}/${SUBFILE1}
chmod 755 ${dshome}/${SUBFILE2}
------------- Taken from /app/Ascential/DataStage/DSEngine/dsenv -------------
umask 002
And here is the information requested by ray:
------------- Command output of "UVFIXFILE RT_CONFIG1344" -------------
RT_CONFIG1344/DATA.30 is smaller then uniVerse file header
I see you have a deep knowledge of that software... i'm learning from you some good troubleshooting's actions.
Ty
Last edited by jungle on Tue Dec 16, 2003 10:32 am, edited 2 times in total.
Tell your sysadmin that you CANNOT HAVE UMASK IN THE DSENV file. If you read the S999ds.rc script, you see that it reads the dsenv file and only pulls out statements in the form XYZ=ABC.
This is covered extensively in your installation notes for release 5 on. You must put the umask statement into the S999ds.rc script.
So, your umask setting for one is not being honored. That causes problems exactly like you're describing.
This is covered extensively in your installation notes for release 5 on. You must put the umask statement into the S999ds.rc script.
So, your umask setting for one is not being honored. That causes problems exactly like you're describing.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle