Hashfile Migration
Moderators: chulett, rschirm, roy
-
Sreenivasulu
- Premium Member
- Posts: 892
- Joined: Thu Oct 16, 2003 5:18 am
Hashfile Migration
I want to know, how to migrate the Hashfiles. Can any one suggest me
Hashed files can be migrated. Without more information from you no more detail can be supplied. One version to another? One platform to another? One project to another? With or without data? Back to a previous version? Combination of some of the above?
There are also several posts that searching for "hash file migration" will recover that might help you as well.
There are also several posts that searching for "hash file migration" will recover that might help you as well.
</a>-
Sreenivasulu
- Premium Member
- Posts: 892
- Joined: Thu Oct 16, 2003 5:18 am
Sreenivasulu,
when you create hashed files you have the option of creating them in the project directory or at some path. It has always been recommended to use the path option for hashed files for a number of reasons, the most important being (in my opinion):
(a) your DS project directory remains separate from the data and will (hopefully) not fill up
(b) All project hashed files should/can be put into a known and centralized location. This is good for monitoring status, size and for backups and for migration.
If you put all of your job hashed files into a distinct path then migration is as easy as copying this files & directories to the new machine. If your hashed files are in the project directories then you have a lot more work ahead of you.
Hashed files written to the project directory have 2 components. The first is an entry in the project's VOC file with it's logical DS name. The second component consists of the actual DICTionary file and DATA file (which, for type 30 dynamic files is a directory with 2 actual and one hidden file in it). In order to successfully migrate local hashed files you need to make sure that both components are done.
The easiest way to do this without knowing details of the DataStage internals is to run the jobs in the new environment so that they create the VOC file entries. Then you can copy and overwrite the contents of the D_{YourHashedFileName} and the {YourHashedFileName} from the original machine to the new one. This needs to be done for each hashed file.
It should be clear why using paths for persistent hashed files makes a migration much easier.
If you are staying within the same version of DataStage and both the old and new machines have the same project paths and names then a UNIX level copy of the project directory might work for you; but you need to create the project on the new machine before doing any copying. This approach isn't recommended (or supported) by IBM/Ascential.
when you create hashed files you have the option of creating them in the project directory or at some path. It has always been recommended to use the path option for hashed files for a number of reasons, the most important being (in my opinion):
(a) your DS project directory remains separate from the data and will (hopefully) not fill up
(b) All project hashed files should/can be put into a known and centralized location. This is good for monitoring status, size and for backups and for migration.
If you put all of your job hashed files into a distinct path then migration is as easy as copying this files & directories to the new machine. If your hashed files are in the project directories then you have a lot more work ahead of you.
Hashed files written to the project directory have 2 components. The first is an entry in the project's VOC file with it's logical DS name. The second component consists of the actual DICTionary file and DATA file (which, for type 30 dynamic files is a directory with 2 actual and one hidden file in it). In order to successfully migrate local hashed files you need to make sure that both components are done.
The easiest way to do this without knowing details of the DataStage internals is to run the jobs in the new environment so that they create the VOC file entries. Then you can copy and overwrite the contents of the D_{YourHashedFileName} and the {YourHashedFileName} from the original machine to the new one. This needs to be done for each hashed file.
It should be clear why using paths for persistent hashed files makes a migration much easier.
If you are staying within the same version of DataStage and both the old and new machines have the same project paths and names then a UNIX level copy of the project directory might work for you; but you need to create the project on the new machine before doing any copying. This approach isn't recommended (or supported) by IBM/Ascential.