I am trying to migrate my jobs from one server to another

[srikanth77]

Hi,

I am trying to migrate the jobs from one server to another, both of them have the same configurations and same version. can i migrate them without using the import and export command.

[raju_chvr]

How exactly are you trying to achieve this without DS export and import?

interesting to know?

[hgalusha]

On unix, you can restore the /dsadm file system from a tape backup and that would effectively do it....but it seems to me the safest method would be a full project export and import.

Hope this helps.

[raju_chvr]

I would suggest the later... full project export and import on the another
machine ...


Happy Holidays !!

[kcbland]

Do not even contemplate copying a project directory and its contents as a means of migration. Archiving a project via a unix backup is valid only as a means of disaster recovery. You should be able to recreate a project from your version control tool's archive. The idea of not using the inherent functionality in the tool for moving design objects in and out is a disaster in waiting.

[raju_chvr]

See there we go ... now we have an authoritative answer to use DS export and import functionality.

[kcbland]

Just to elaborate, the entire project and contents are stored in hundreds of binary data files. It's all or nothing. For example, one single hash file DS_JOBOBJECTS contains the entire job design library for that project. You have no ability to pick pieces and parts from it. In addition, all of the job logs, configuration, status files, etc are contained within the project. Any import/export goes with it. Permissions becomes an issue, as all files have to retain their owner, group, and settings. Furthermore, you have to absolutely have the EXACT same paths on both servers, as internal files have paths hardcoded in them. In addition, licensing may be an issue, because two different servers have different serial numbers. I would imagine there may be some hidden things there. Not to drive the final nail in the coffin, but this approach means that everything, everytime, would be wholesale wiped out and replaced. This means every incremental job change, log purge, setting change, whatever, requires a complete project replacement. NOT GOOD.

[ray.wurlod]

Just to rub it in...

Even if you got everything right from Ken's post, you still have to fix any required entries in the system tables (such as UV.ACCOUNT and the SQL Catalog tables).

Therefore, while technically it can be done - if you know what you're doing at every step - why would you bother, given that export/import looks after everything for you (except automatic creation of hashed files)?

[ray.wurlod]

Export/import does not copy hashed files. After all, these are intended as temporary storage.
If you have copied hashed files such as SDKSequences, you now need to create pointers to them in the VOC file. To do this use the SETFILE command. Search the Forum for details.