Compilation error with Column Analysis Job

CharlesNagy · Post by **CharlesNagy** » Tue Mar 30, 2010 2:37 am

Hi Guys,

I am getting the following error when attempting to run a column analysis:

Error executing DS job

Could not access job "BaseProfile_ColumnAnalysisTask99859019". Make sure this job is compiled

I notice that this error has appeared in a previous post, but with no resolution. Could anybody help with this?

Thanks

CharlesNagy · Post by **CharlesNagy** » Tue Mar 30, 2010 3:50 am

Further to my last post, I have checked permissions and there are no space issues which would prevent the object code being written out, so I am at a loss....

ray.wurlod · Post by **ray.wurlod** » Tue Mar 30, 2010 4:10 am

Check that you have appropriate permissions (including write) to subdirectories in the ANALYZERPROJECT project.

CharlesNagy · Post by **CharlesNagy** » Tue Mar 30, 2010 5:10 am

Thanks Ray,

However, we have checked permissions and they seem fine, so still at a loss

ray.wurlod · Post by **ray.wurlod** » Tue Mar 30, 2010 12:43 pm

Is the executing user's umask set to 022 and/or is the setguid bit set in the project?

CharlesNagy · Post by **CharlesNagy** » Wed Mar 31, 2010 10:49 am

Thanks Ray for your comments, I will have to get back to you on that.

However I have done some more investigation and tried to create a test job in Designer in the ANALYZERPROJECT.

This was a simple row generator with a peak stage.

I cannot even save the job, it comes back with:

Error while creating job Untitled1
Error on CREATE.FILE command (Creating file "RT_CONFIG10657" as Type 30. mkdbfile: cannot create file RT_CONFIG10657 Unable to create operating system file "RT_CONFIG10657". *** Processing cannot continue. *** )

I think this is the issue, ANALYZER cannot even create the job that it uses to do the connection check with the DB.

chulett · Post by **chulett** » Wed Mar 31, 2010 11:01 am

Assuming that's not a disk space issue, then it would be (as noted) permissions.

CharlesNagy · Post by **CharlesNagy** » Wed Mar 31, 2010 11:12 am

Thanks Craig, we have checked that. There is 16% space left in the directory, and we have been able to create a file in that directory in Unix. I was also able to create a small test file in Universe from Administrator, so I don't think it's permissions.

I'm just wondering if it might be a locking issue. I have done a LIST.READU and it has come up with a few locks on RT_LOG files and RT_CONFIG.

I tried doing an UNLOCK on those users but it appears that the UNLOCK verb has been stripped from the VOC in this project. (It exists in all the other Datastage projects).

Be interested in whether you agree that it might be a locking issue, or am I totally off track?

chulett · Post by **chulett** » Wed Mar 31, 2010 12:08 pm

Permissions.

Who all has this problem? Everyone? Just you?

CharlesNagy · Post by **CharlesNagy** » Wed Mar 31, 2010 2:30 pm

Everyone has the problem. Everything was working on Friday then Monday the issue arose. Nobody can compile anything in Analyzer at the moment.

chulett · Post by **chulett** » Wed Mar 31, 2010 2:39 pm

Interesting. I'll head Ray off at the pass and ask the question that he will - What changed? He would also add - Nothing is not the correct answer.

Sorry if I'm stating the obvious, but have you asked around to see if there was any maintenance work done over the weekend or on Monday morning? Changes made? Patches applied? User profiles touched? Anything? And I don't mean just DataStage specific things of that nature, could be server or O/S level as well. FYI - that "mkdbfile" utility isn't really magic or DataStage specific per se, it just goes out and tries to create plain old operating system directories / files so really should only be adversely affected by space or permissions issues. Assuming there's no hardware / media failures involved - which would generally be more wide reaching and catastrophic.

CharlesNagy · Post by **CharlesNagy** » Wed Mar 31, 2010 3:03 pm

Thanks Craig,

I have asked the question everywhere and with everyone. They all claim that nothing has changed in their neck of the woods.

This is why I am grasping at straws and wondering whether a stray lock might be causing the whole issue. We have raised a PMR with IBM, so are going through the laborious process of checking everything.

ray.wurlod · Post by **ray.wurlod** » Wed Mar 31, 2010 3:37 pm

Information Analyzer jobs don't actually get compiled (they generate osh directly) so this message is a bit of a mystery. It suggests that the osh has not been (is not being) properly generated.

The problem is to find out why, which is why our first thought was inability to write the osh into the RT_SCnnn directory for job number nnn (permissions).

UNLOCK can be put into VOC by using the unlock capabilities of the DS.TOOLS menu. It can also be placed in VOC manually. Or you can LOGTO UV (the Engine account) where the UNLOCK command is always present. But I would not think that locks on RT_LOGnnn (log open in Director) would be at the heart of this.

Here's a thought, though. How many jobs exist in ANALYZERPROJECT? Could you be hitting the operating system limit on the number of subdirectories in your project directory? (How many subdirectories are there in the ANALYZERPROJECT directory?)

chulett · Post by **chulett** » Wed Mar 31, 2010 3:39 pm

Is this AIX? Always forget about that possibility.

ray.wurlod · Post by **ray.wurlod** » Wed Mar 31, 2010 3:42 pm

Solaris also has such a limit. Approximately 32K if memory serves.

DSXchange

Compilation error with Column Analysis Job

Compilation error with Column Analysis Job

Permissions and Space issues have been checked