¿Where is installed the repository?

[hamzaqk]

The respository for version 7 would be file based in the project folder under the path 'Ascential\DataStage\Projects\PROJECT_NAME, with folders names like RT_XXXX etc

[ray.wurlod]

The version 7 repository is stored on the DataStage server in a proprietary database (called DataStage Engine, based on the UniVerse database). It is not DB2, or Oracle, or anything else.

That story changes once you move to version 8.

[J.Calvo]

There isn't any xmeta database?
What client i have to use to access?
Is really a database like oracle, sqlserver etc or is a folder?

The version 7 repository is stored on the DataStage server in a proprietary database (called DataStage Engine, based on the UniVerse database). It is not DB2, or Oracle, or anything else.

That sto ...

[J.Calvo]

One question, in version 7.0 there isn't any respository service running in windows isn't it?

[hamzaqk]

the database name used is called UNIVERSE and you can access it using the universe stage or by issuing commands from the administrator. And no there is no Xmeta in 7. Only V8 onwards.

[chulett]

XMETA is a specific 8.x concept but there is always a 'repository service' that runs regardless of version and you access the DSEngine repository via the Administrator or from a TCL prompt launched via 'dssh'.

[chulett]

Further details really depend on exactly what is meant by a 'migration project' and the tasks around that. Could be all that's needed is a dsx export on the 7 side imported into the 8 side of the house.

[ray.wurlod]

I guess we need to know whether the migration is from version 7 to version 7, or from version 7 to version 8.

In any case, you don't really need to migrate much of the repository - only wanted entries from configuration files such as DSParams and uvodbc.config.

All the rest are created when you import (and, possibly, compile) objects in the new project that were exported from the old.

You can rely on running DataStage jobs to create hashed files, Data Sets and the like. So you really don't need to migrate those either. One exception might be the (contents of the) SDK hashed file SDKSequences.

[vivekgadwal]

One exception might be the (contents of the) SDK hashed file SDKSequences.

...which could be resolved by Creating State files and loading all the Surrogate key values from the tables, if migrating to version 8.

If the migration is to version 7.5.x, then you have to worry about copying those SDK hashed files.

[chulett]

That would be more of a conversion than a migration, IMHO, seeing as how it would involve code changes and a switch to PX jobs.