Problem with VOC after database Migration.

Anupam_M · Post by **Anupam_M** » Sun Oct 29, 2006 11:58 pm

Hi DSGurus,
I am facing this unusual problem. My source and target databases have been migrated from Oracle 9i to Oracle 10g. The datastage jobs used to write/read data from dynamic hash files.However when I run the jobs which are creating these hash files(the files are being deleted every time and recreated) then I get the following error:
"<Filename>" is already in your VOC file as a file definition record.
This as far as I understand is that the synonym is in the VOC already exists and hence the recreation is not getting possible.Prior to the migration this was not a problem.
I have tried to run the job by changing the hash files names and they work fine.
However given the huge number of Hash files that are being created I do not think this is a feasible solution.
Could someone help on this.
Regards,
Anupam

chulett · Post by **chulett** » Mon Oct 30, 2006 6:41 am

Welcome Aboard. :D

How did you accomplish this 'database migration'? Specifically, what changes did you make to your DataStage environment? I ask because the two problems should in no way be related.

Anupam_M · Post by **Anupam_M** » Mon Oct 30, 2006 7:32 am

Hi Craig
Thanks for your reply.There were no specific changes to the Datastage Environment that was carried out. I am not very sure of the process the database migration was conducted.
However there are a few more observations:
1. the hash files are being deleted and recreated evertime the job is run.
So possibly the job is deleting the hash file but not deleting the vocabulary(VOC) entry and hence when it is trying to recreate the has file it is throwing the error.(Just an intrusion)
After the job aborts I try checking out the hash file and it is there and looks quite perfect!!!!!!!
Your futher feedback/suggestions will be of great help :D

chulett · Post by **chulett** » Mon Oct 30, 2006 7:39 am

Hmmm... ok. Don't worry about how the database migration was done, that's a DBA thing and they like to keep that kind of arcane knowledge secret.

Just wanted to see if you did something specific with DataStage as well as part of that. Shouldn't have needed to.

Are there any other messages in the job's log when you have this problem? Anything about a T30FILE setting, perhaps? I've seen this happen when certain uvconfig parameters need to be bumped up from their 'out of the box' settings, but they are generally accompanied by specific messages to that effect.

When the job aborts, have you tried Resetting it from the Director? If so, does it add a new log entry entitled 'From previous run...'?

Anupam_M · Post by **Anupam_M** » Mon Oct 30, 2006 8:14 am

Hi Craig,
This was the toal error message that I got:
DSD.UVOpen rm: Unable to remove directory <Filename>: File exists
Unable to DELETE file "<Filename>".
"LocalRefs" is already in your VOC file as a file definition record.
File name =
File not created.

There was no mention about a a T30FILE setting.
I had already tried resetting the job and running it but it does not give "From previous run.." entry.

ray.wurlod · Post by **ray.wurlod** » Mon Oct 30, 2006 9:20 am

No, this is just DELETE.FILE failing because of entries pre-existing in the VOC file. The only safe course is to create a list of the failures, delete the pertinent entries from the file system and from the VOC. For example, if a hashed file is called MYFILE, then you need three steps, and you can ignore any "not found" errors that may occur.
Possibly easiest is to create the three commands as follows in the Administrator, then select all three and save as a pre-stored procedure called, say, CLEANUP.

Code: Select all

SH -c "rm -rf <<F(VOC,<<I2,HashedFile>>,3),Dict pathname>>"
SH -c "rm -rf <<F(VOC,<<I2,HashedFile>>,2),Data pathname>>"
DELETE VOC "<<I2,HashedFile>>"

For those on Windows servers, replace "SH -c" with "DOS /C" and "rm -rf" with "DEL /S/Q"

chulett · Post by **chulett** » Mon Oct 30, 2006 9:28 am

ray.wurlod wrote:No, this is just DELETE.FILE failing because of entries pre-existing in the VOC file.

Granted, but trying to get to the root cause. Before that, something caused the delete of the VOC record to fail causing this error on subsequent runs... yes?

ray.wurlod · Post by **ray.wurlod** » Mon Oct 30, 2006 2:41 pm

The root cause is that DELETE.FILE does not delete the physical objects if they are referred to by a pathname rather than a simple entryname. This behaviour is documented; either in the UniVerse manuals or by typing HELP DELETE.FILE from the TCL prompt in a telnet session (HELP is blocked from the Administrator client).

So DELETE.FILE deletes the VOC entry but not the data and dictionary portions of the hashed file. My paragraph, posted earlier, deletes all three.

It does, however, require that the VOC pointer exists, so you may wish to include or execute an appropriate SETFILE command beforehand.