cannot open executable job file

jungle · Post by **jungle** » Tue Dec 09, 2003 6:27 am

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

ray.wurlod · Post by **ray.wurlod** » Tue Dec 09, 2003 6:35 am

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>>.

Teej · Post by **Teej** » Tue Dec 09, 2003 7:18 am

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.

kduke · Post by **kduke** » Tue Dec 09, 2003 8:57 am

TJ

Just one thing to add. The group id needs to be set so anyone in the group can delete the files created by another user. You can do this with chmod.

chmod -R 4770 ProjectDir

jungle · Post by **jungle** » Sat Dec 13, 2003 5:55 am

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

Do you think there is something wrong about that?
Thanks guys

chulett · Post by **chulett** » Sat Dec 13, 2003 8:53 am

Depends...

What user or users get the error and what group(s) do they belong to?

jungle · Post by **jungle** » Sat Dec 13, 2003 9:39 am

Sorry, i forgot to tell that thing.

The user that got error is "dsadm" and it belongs to "dsadm" group

chulett · Post by **chulett** » Sat Dec 13, 2003 9:57 am

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.

jungle · Post by **jungle** » Sat Dec 13, 2003 10:10 am

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

kcbland · Post by **kcbland** » Sat Dec 13, 2003 10:43 am

Go to your DS Admin window and execute the command

Code: Select all

LIST RT_CONFIG1344

and look at the output. If you get a message like:

Code: Select all

Retrieve: syntax error.  Unexpected sentence without filename.  Token was "".
          Scanned command was LIST 'RT_CONFIG1344'

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:

Code: Select all

cd `cat /.dshome`
. ./dsenv
bin/uvsh
logto yourprojectname

Then, you will have to manually create this file pointer. Do the following:

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".

You should do an export immediately and then reimport the job to clean everything up.

jungle · Post by **jungle** » Sat Dec 13, 2003 11:56 am

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

kcbland · Post by **kcbland** » Sat Dec 13, 2003 1:28 pm

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:

1. directory
2. DATA.30 file
30 OVER.30 file

You posted:

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

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.

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.

ray.wurlod · Post by **ray.wurlod** » Sun Dec 14, 2003 3:38 pm

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?

Code: Select all

UVFIXFILE RT_CONFIG1344

This will help further diagnosis.

jungle · Post by **jungle** » Tue Dec 16, 2003 10:22 am

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

kcbland · Post by **kcbland** » Tue Dec 16, 2003 10:31 am

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.