Two versions of Jobs repository?

[mouthou]

Hi,

Is there a separate objects repository for Designer and Director? The job which is deleted from Director is showing in Designer but clicking on it gives a message as 'job not found in repository'. How can it be out of sync? I refreshed and re-logged. Still the same.

Recently there was a job hung and showing as 'Running' in Director but the job failed in Desginer as the links were showing red. Also I couldnt find any process using DS.TOOLS. Being choiceless (I reset the status of the job) and I tried re-compiling. I couldnt since it said job is monitored and there is exclusive access.

Now even worse.. Since I needed that job in useable state, I copied it and deleted the original job from DS_JOBS using DELETE command. The job got deleted but showing in Designer. I am in big soup now. The original job is gone and I can't rename the copied job either. Is it a bug in 8.X version.

Any idea/reference to know about this issue and how to bring the jobs in sync everywhere?

Thanks

[ray.wurlod]

I suspect one is using the local project repository and the other is using the unified, or common, metadata repository. How are ORLogging and RTLogging set in the project's DSParams file?

[ArndW]

There is just one repository system, but at Version 8 and above you have both hashed files and the XMETA repository contents to keep in synch. Since you have used an undocumented method to force delete a job, you might have caused damage to your project which cannot be easily fixed.

Can you try to fix the repository from DS.TOOLS (you will need to make 100% sure that all DataStage users are logged out of the system before trying this)?

[chulett]

Your mistake was going 'under the covers' to delete things, do not do that on your own. While you could do that if you knew what you were doing in earlier versions where there was a single repository, nowadays there are (technically) two and you compounded your original 'out of sync' error by doing so.

Contact your official support provider for help rectifying this.

[asorrell]

There is a manual clean-up process you can get from your official support provider. It involves three steps,

1) Deleting specific job entries from your Project's VOC file
2) Deleting the specific supporting files from the UNIX level
3) Using a "Wrapper" shell script to locate and delete entries from the database repository.

I'm not posting the exact steps because it is dangerous to do unsupervised. You'll need to contact support to get the wrapper script anyway.

Note: At the end of this, the job will be gone gone gone! This doesn't make the job usable, it removes it. So if you can save it under a new name temporarily do so, or you'll be going to your backups to reclaim a copy.

[mouthou]

No Ray. There is local project repository. We are working on a remote login mode with 15 different virtual machines. It is not possible to have the local version created on all 15 machines.

Thanks

[mouthou]

Thanks for your suggestion, asorrell. But this seems to be a lengthy procedure and risky one too for a single job delete. Contacting support is not an option.

[chulett]

Not sure why he asked about 'one and the other', but you misunderstood Ray's response. Regardless, might still be helpful to answer his question. Or not.

[divesh]

re-index of the project might help.

[ray.wurlod]

I meant local to the project, on the Engine tier, versus common in the Repository tier. Where the clients are located is irrelevant.