DSXchange

We have a very odd scenario here that I cannot figure out and hope that someone here might solve it for us or point us in the correct direction. We've finally narrowed down the issue and think it has to do with mount points. We've installed DS on a new AIX machine and have created several projects at the same time with the same attributes in the Administrator. All the projects in a specific path show the same odd problems - although jobs can be imported and compiled with a normal userid or the dsadmin only the dsadmin user can actually run jobs; the other userid ends up doing nothing when trying to run a job in the Administrator or using dsjob. Looking at the log file shows the error message "Project not found"'; but the user can go to the project using TCL and issue normal commands.

The same series of steps for a directory in another mount point show no problem with non-admin users! The mount options for both are the same and we've even gone so far as to chmod 777 everything as well as to chown and chgrp all the files and subdirectories to no avail.

It took much of the day to narrow down the cause and now we can install the projects in directories that "work" but the root problem still escapes us. Does anyone have any ideas on what might be the explanation for this or any suggestions on narrowing down the cause? We've turned on tracing and I've actually gone through the P-code as far as possible to see what might be happening "under the covers" but haven't found anything. I thought that the &PH& error message of "Project not found" might help me isolate the problem, but it isn't in the SYS.MESSAGE file and I've searched the Pcode programs for that string without luck.

What error codes are you getting? Grab the Intercall manual from the UniVerse web site - it has the most comprehensive list of connectivity error codes.

I have a vague recollection that you can't install DataStage on symbolic links - are there any symbolic links involved?

There are no error codes. Even with tracing enabled there are no error codes, the &PH& entry contains the 1-liner "Project not found", but as that use I can look at UV.ACCOUNT and have put in a test program to call up DSR_PROJECT as well and that returns a valid value.
If the job has a status of "compiled" and an empty log and you click on "run" and enter your parameter values then ... the status remains compiled and the log is empty. Routines can be compiled/tested but a job won't run (or reset). The mount fs type and parameters are the same for the mount point that works as for that which doesn't. Another DS engine on the same machine has projects that work on other paths but has one on the same mount point that won't function either. I've re-installed DS twice now to make sure that isn't the cause. So far in the past 3 days we've installed somewhere around 10 instances on several LPARs all with the same install parameters and this one location (for project directories) is the only one causing problems; yet nothing is visibly different. The mount points are all on a very large IBM SAN, but as the non-admin user I can create/change/delete files at UNIX level as well as from TCL.

I would guess it is ACLs. What are the user groups? Make sure and do id at the AIX level to see what is the default group. Make sure the default group is the same as dsadm. I am not sure on AIX if you can force all files in a directory to owned by the same group with

chmod -R g+s ProjectDir

Permissions should be rwxrws--- on all files in a project. I would also make sure

umask 002

is in dsenv and uv.rc.

Thanks Kim.
We did check to make sure that no ACLs were set, the umask is set to 002 as well, and the groups are aligned, we even did chmod 777/chown/chgrp to all files/directories yesterday as well. Access rights are identical between the project in a "good" mount point and the "bad" one. I'll force-set the sticky bit (which I didn't test) to see if that makes a difference. Perhaps it does have something to do with the "hidden" attributes for the drives in the SAN configuration.

The problem is now solved. It seems that the user(s) who couldn't run jobs in the "bad" path didn't have the group "system" in their group list. Once that was added the user(s) could run jobs. There still isn't a difference visible that would account for why they could run jobs on projects in other paths, but at least now the problem has been resolved.

Needing "x" permission to a directory higher up the pathname?

To use any directory in a pathname one requires at least "x" permission to that directory. To search a directory (for example if there are wildcards in intermediate directories in the pathname) also requires "r" permission.