Cleaning up Hashed Files

[ray.wurlod]

How did you "notice" that a lot of hashed files had already been generated? If you can do that, surely you can obtain a list of them.

You also need to be aware that some hashed files (with names that begin with "DS_" and "RT_") that actually form the DataStage respository.

If you have been diligent saving your hashed file column definitions into the Repository, then you can obtain a list of these from there, either via the documentation tool or from MetaStage.

Deleting the contents of your hashed files can be accomplished using either regular SQL (for example DELETE FROM hashedfilename;) or using the CLEAR.FILE command, perhaps from the Administrator command window.

The command for "dropping" the hashed files depends on how they were created.
Create Command "Drop" Command
CREATE.FILE DELETE.FILE
CREATE TABLE DROP TABLE
mkdbfile rm -r (on Windows, rm.exe ships with DataStage)


Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518

[ray.wurlod]

You may have destroyed your project by deleteing things with names beginning with DS_ or RT_.
Do not delete anything with a name beginning with either "DS_" or "RT_", as these are DataStage repository hashed files.
A number of these exist when the project is created. When a server job is created a new job number is allocated, and some more things are created. These )where xx is the job number) are:
RT_BPxx (BASIC code generated when job is compiled)
RT_BPxx.O (compiled BASIC code)
RT_CONFIGxx (run time configuration information)
RT_LOGxx (job log)
RT_STATUSxx (run time status information for jobs/stages)
DS_TEMPxx (relationships between stages and links)
Server job design information is stored in records in DS_JOBOBJECTS. If you are running DataStage 4.2 or earlier, job design information is stored in DS_JOBxx.
Job numbers, as noted earlier, are stored in DS_JOBS.

Similarly, never delete any file whose name is any of the above preceded by "D_". These files are the "file dictionaries" - in short the metadata - for those hashed files.

There is one more component to hashed files created in an account (which all of the repository hashed files are), and that is an entry in the project's VOC (vocabulary) file. If the hashed file is created in a directory (rather than in an account), then there is no VOC entry.

So, where are these messages coming from? Let's use MyHashedFile as the name of a hashed file for example.

If the message is "file exists in directory", then one of MyHashedFile (the data portion) or D_MyHashedFile (the file dictionary) exists in the UNIX directory, and must be deleted before the hashed file can be created.

If the message is "file exists" or "file entry exists in VOC" then the VOC entry must be deleted before the hashed file can be created. This is properly achieved using the DELETE.FILE command as noted earlier, but could also be achieved via DELETE VOC 'MyHashedFile' (note that all these commands are case sensitive).

Finally, to reiterate, never delete anything with "RT_" or "DS_" as the beginning of its name, or anything thus named preceded with "D_".