Page 1 of 1

Challange in using dsjob -linkinfo feature

Posted: Tue Sep 12, 2017 8:20 am
by 111111111111111111
I am using one shell script that sequentially uses -lstages, -llinks and -linkinfo option of dsjob command.

The number of links returned by -llinks option are double than what actually is there in the job which is pretty obvious because one link is input for one stage and output for other one. For this I am removing the duplicate link names using my shell script.

But I am stuck on a scenario when a stage name and the link name to that stage name is duplicate in a job. Example:

OracleConnector -- Copy1 -- Link1(LinkName) -- Seq1(StageName)
--Link2(LinkName) -- Copy1 -- Link1(LinkName) -- Seq1(StageName)

In such case Link1 will appear 4 times:
With Copy1 stage,Seq1 Stage, Copy1 Stage(Row2) and Seq1 Stage(Row 2) and my shell script will reduce this set to 1. Is there a way to keep 2 rows at output and store the linkinfo result separately in Unix variable/array?

Posted: Tue Sep 12, 2017 9:27 am
by PaulVL
I find it hard to believe "111111111111111110" user id was taken.

(sorry could not resist).


Perhaps if you describe what you are trying to ultimately achieve, we could recommend a course of action.

doing the -linkinfo method might be a pricey thing to do.

I would prefer a DSODB query for those stats.

Posted: Tue Sep 12, 2017 11:17 am
by 111111111111111111
I am trying to find out the counts on each link of all my jobs in a particular project. I have the job names with me.

Posted: Tue Sep 12, 2017 3:21 pm
by PaulVL
If you have DSODB configured... write a datastage job to query DSODB


Look at page 11 of 19.


https://www.ibm.com/developerworks/data ... b1-pdf.pdf

Posted: Tue Sep 12, 2017 10:25 pm
by 111111111111111111
This is restricted to be used by dsadm user, Is there not a user/developer way to achieve this?

Posted: Wed Sep 13, 2017 6:48 am
by Mike
DSODB is way too valuable a resource to be locked away. All developers should have read access. Take it up with your admin folks.

Mike

Posted: Wed Sep 13, 2017 8:44 am
by PaulVL
I think I know what he is saying. He's saying that dsadm user id has RW access to DSODB tables and as such the password is never handed out to users. This might include not exposing the password via parameter sets either. As an admin I would never expose dsadm to the unwashed masses either.


Simple solution is to get your datastage admin to set up a DSODBRPT (for report) user id to get SELECT access to all of those tables. That way the admin team can set up ONE generic user id and have a parameter sets created in each datastage project for access to that treasure trove of metadata.

Optional solution if to have your DataStage admin have a WISD job run as fsdsadm under a controlled project to initiate that DSODB canned report upon request. When voiced that way... they will opt for the DSODBRPT user id. haha

Posted: Fri Sep 22, 2017 3:28 am
by ray.wurlod
Just a thought. Could it be that -llinks is actually returning "pins"? A pin is the end of a link - the interface between a link and a stage. There are always exactly two pins per link.