Hi,
Actual problem statement:
I need to do a QC check on our DEV project before migrating to TST. In particular, I need to know which jobs have hard coded physical paths or database connection strings (eg. db instance, username, password). All of these job parameters should be "$PROJDEF". Our business process only allows migration via Datastage Version Control, not export/import of a DSX file.
Related problem statement:
So my quick and dirty approach is to export the project to a DSX file, search on BEGIN DSSUBRECORD, note the jobs with hard coded parameters, and fix them in the Designer UI.
However, we have HUNDREDS of development jobs in the project. We've moved them all to their own (sub)containers.
It would be nice to exclude them from the export, i.e export all jobs in containers FOO, BAR, and BLAH, but exclude jobs in container TESTING.
So, is this possible? It doesn't appear so from the DataStage Manager Export UI.
[Note: so I opened the full DSX file in TextPad, and started searching on BEGIN DSSUBRECORD. This will be way too painful for the actual problem definition. So, if anyone has written a job or script, or can at least suggest a better approach, that would be great.]
Regards,
Scott
Exporting selected containers from a project?
Moderators: chulett, rschirm, roy
Exporting selected containers from a project?
Some people are the Michael Jordan's of Datastage. I'm more like Muggsy Bogues
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
It's only possible via a query (or several) against DS_JOBOBJECTS. There's nothing in the version 7 UI that can help you, and not even the Advanced Find facility in version 8 will help.
You might begin with something like:
You might begin with something like:
Code: Select all
SELECT OBJNAME, OLETYPE, NAME FROM DS_JOBOBJECTS WHERE EVAL "@RECORD" LIKE '%/%' AND EVAL "@RECORD" NOT LIKE '%//%';
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.