Cannot Import Jobs to Brand New Project

[nitecryvl]

As dsadm, I created a new project like I have done many times before. After the project has been created, I log into it as one of the users with full developer privileges to start importing jobs.

As soon as I kicked off the import, I would get this error:

Error calling subroutine: DSR_JOB (Action=2); check DataStage is set up correctly in project DWPROD_20101020
(The connection is broken (81002))

I searched the forums for possible solutions, and here's what I have tried so far:
- I made sure the user have access. The user has been granted both CONNECT and DBA on the new project.
- I ran the DS.REINDEX ALL command on the project.
- I couldn't use the Job -> Cleanup Resources option, it is gray out.
- I even deleted a couple old projects just to make sure I didn't max out on the number of projects.

None of these solutions fixed the problem.

This problem only occurs on the new project. If I import the same jobs into an existing project under the same UNIX server, it works just fine.

Any ideas?

[JFR]

Hello,

You could :

- try to create/save a job with the user
- try to import with dsadm
- Is the same user able to work on other projects ?
If it works, it should be a permission issue somewhere.

Be sure the user has +w access to the directory pointed by UVTEMP in $DSHOME/uvconfig

- try to recreate the project as a last resort and if you really think permissions are not the issue.

[ArndW]

login as that user to a shell on the server and "cd" to the project directory and see if a "touch abc" works. I suspect that the user doesn't have create or write access and this is causing your error.

[nitecryvl]

JFR,

Thank you for the suggestions. I tried them and here are the results:

- try to create/save a job with the user
No, the user can't create jobs in the new project.

- try to import with dsadm
Import doesn't work with dsadm either, which should not happen if it is a permission issue.

- Is the same user able to work on other projects ?
Yes. I imported a project from Production into an existing project using the same user. It worked just fine.

- Be sure the user has +w access to the directory pointed by UVTEMP in $DSHOME/uvconfig
Yes, the user has full access to the new project.

- try to recreate the project as a last resort and if you really think permissions are not the issue.
I have tried recreating the project multiple times, same result.

It almost appears as though the create project process in DataStage Administrator did not created the project correctly.

Thanks for your help, I will keep looking for solutions.

[nitecryvl]

login as that user to a shell on the server and "cd" to the project directory and see if a "touch abc" works. I suspect that the user doesn't have create or write access and this is causing your error.

touch works in the new project directory with this user.

[ArndW]

How many files are in the new project?

[nitecryvl]

How many files are in the new project?

Here's list of subdirectories and files under the new project:
&COMO&/
&PH&/
&SAVEDLISTS&/
D_&COMO&*
D_&SAVEDLISTS&*
D_DS_AUDIT*
D_DS_CONTAINERS*
D_DS_DATATYPES*
D_DS_JOB*
D_DS_JOBOBJECTS*
D_DS_JOBS*
D_DS_METADATA*
D_DS_RESENU*
D_DS_ROUTINES*
D_DS_STAGETYPES*
D_DS_TRANSFORMS*
D_DS.GETINFO.DEFAULTS*
D_DSD_BP.O*
D_DSG_BP.O*
D_DSU_BP*
D_DSU_BP.O*
D_EXAMPLE1*
D_RT_CONFIG*
D_RT_LOG*
D_RT_STATUS*
D_VOC*
D_VOCLIB*
DS_AUDIT/
DS_CONTAINERS/
DS_DATATYPES/
DS_JOBOBJECTS/
DS_JOBS/
DS_METADATA/
DS_RESENU/
DS_ROUTINES/
DS_STAGETYPES/
DS_TRANSFORMS/
DS.GETINFO.DEFAULTS/
DSD_BP.O/
DSG_BP.O/
dsinclude/
DSMFParams*
DSMFParamsOS390*
DSParams*
dsr_sched.sh*
dssendmail_template.txt*
DSU_BP/
DSU_BP.O/
EXAMPLE1/
EXAMPLE1.SOURCE/
I_DS_CONTAINERS/
I_DS_DATATYPES/
I_DS_JOBOBJECTS/
I_DS_JOBS/
I_DS_METADATA/
I_DS_ROUTINES/
I_DS_STAGETYPES/
I_DS_TRANSFORMS/
uvodbc.config*
VOC*
VOCLIB*

If I do a wc -l */* in the new project directory, the total file count comes back 23718.

[JFR]

UVTEMP is probably not pointing to the project directory.
Look for UVTEMP in the $DSHOME/uvconfig file.

I don't really see why dsadmin would not be able to import any jobs.

It s too bad you didn't post the user:group in your file list.
As well as the user:group on the directory itself.

Have you tried created a dummy project and try the import again ?

[nitecryvl]

UVTEMP is probably not pointing to the project directory.
Look for UVTEMP in the $DSHOME/uvconfig file.

I don't really see why dsadmin would not be able to import any jobs.

It s too bad you didn't post the user:group in your file list.
As well as the user:group on the directory itself.

Have you tried created a dummy project and try the import again ?

UVTEMP is the $DSHOME/uvconfig file is set as
# UVTEMP - is the name of the directory
# where the server maintains select lists
# and other internal temporary work
# files. This should be a fully
# qualified name of no more than 112
# characters.
UVTEMP /tmp

I checked disk space where /tmp is, there is plenty of room. I also checked the priviliges on /tmp, I have full access.
drwxrwxrwt 9 root sys 31714 Oct 21 11:20 tmp/

All directories under the new project has the privilieges of
drwxrwxr-x 2 dsadm etl

All files under the new project has the privileges of
-rwxrwxr-x 1 dsadm etl

The user that I am using belongs to the etl group.

This project is a dummy project. I am using it as a backup for our production project. I have created 5 other such projects before this happened, and they all worked properly.

That's why this problem is so strange!