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
Verify Migration of Datastage from Test to Prod
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 50
- Joined: Tue Jan 02, 2007 1:40 am
-
- Premium Member
- Posts: 232
- Joined: Fri Aug 04, 2006 1:20 am
- Location: Bangalore
For getting the JobCount, you can use
And for routines,
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
Code: Select all
Select Count(*) FROM DS_JOBS where NAME NOT LIKE '\\%';
Select NAME FMT'50L' FROM DS_JOBS where NAME NOT LIKE '\\%';
Code: Select all
Select Count(*) FROM DS_ROUTINES where DSRID NOT LIKE '\\%' ;
SELECT DSRID FMT'50L' FROM DS_ROUTINES WHERE DSRID NOT LIKE '\\%';
These queries will return only the counts and wont show you the changes inside the jobs or routines.
Thanks
Anand
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.
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.