Verify Migration of Datastage from Test to Prod

[Hemant_Kulkarni]

Hi

We have migrated datastage jobs from Test to Prod Environments (using Datastage Export and Import). However there is a requirement to verify that all the components have been successfully ported to new environment.

We have tried 2 approaches, but both of them have been denied by the testing group as "not acceptable"

The approaches we tried are

1) Manually Count the number of jobs/ routines/table definitions etc : This approach was marked unacceptable due to high scope for human error

2) Export the Migrated Project as .dsx file. Compare the .dsx file (from which the import happened) and the Exported .dsx file, using file comparison tools

This approach was denied as unacceptable due to differences that surface in the Date and Time values.


Is there a way we can verify whether all the components were successfully migrated ?

are there any known list of exceptions (eg: mismatch in date , time values) that can be used while comparing the dsx files

Please suggest

[DS_SUPPORT]

For getting the JobCount, you can use

Code: Select all

Select Count(*) FROM DS_JOBS where NAME NOT LIKE '\\%';
Select NAME FMT'50L' FROM DS_JOBS where NAME NOT LIKE '\\%';

And for routines,

Code: Select all

Select Count(*) FROM DS_ROUTINES where DSRID NOT LIKE '\\%' ;
SELECT DSRID FMT'50L' FROM DS_ROUTINES WHERE  DSRID NOT LIKE '\\%';

And for table Definitions, you can cross check with DS_METADATA, look the dictionary definiton and frame your query.


These queries will return only the counts and wont show you the changes inside the jobs or routines.

Thanks
Anand

[Teej]

The 2nd solution -- tell them to REMOVE/IGNORE the header record from the DSX. This is where the difference in date/time are founded.

If the file were re-saved or modified in any manner, the other dates will change, and is considered as a valid indication of the date differences.

However, if you MUST compare what is on the production with what is on the development (instead of archiving the DSXs used to migrate jobs to production), you can go as far as ensuring the dates are the same using a simple script (such as one that I have created using visual basic scripting, but is not in the public domain.)

It took me approximately 2 days to develop and test it despite not knowing VBS beforehand, so it is definitely a simple task for any decent programmer to do.

[kduke]

DS_AUDIT might help tell you what jobs got loaded. Does not help to know if the correct DSX got loaded. Version Control has an audit file as well. VC also updates the version number of a job.