DSXchange

Good to know...thanks for passing that on. As Vincent noted, some of this might be alleviated with Metadata Asset Manager, as the bridge is then often running on a dedicated machine without as many conflicts.

Ernie

perhaps...although it would seem unlikely since these values are just chunks of xml that are passed downstream. To debug something like this I would probably ensure that these are the ONLY data rows going into the job, so that you can ensure that after the first xmlOutput Stage, you have only one ro...

Are you on 8.5, or at 8.7 ? I haven't tested it in awhile, but I recall this working successfully in recent releases. Make sure you do a test with a simple Shared Container [like maybe just a single Transformer], just to make sure it's not an issue with a particular Stage or something odd "insi...

It's hard to say....it sounds like you are doing things correctly with multiple xmlOutput Stages....I will assume that you are first building one repeating node, and then the other, and then in final creation, perhaps passing the initial xml strings via lookup into a single row. Be sure that you onl...

See if the information you are looking for is in a .dsx, especially a .dsx in xml format, which can be parsed if necessary, by DataStage to pull out what you need...

Ernie

...and you do that by clicking on the toolbar "Repository"...then "Metadata Sharing" and then "Create Table Definition from Shared Table" (that will open a dialog box that shows you your FT tables and you can select them).

Ernie

...and by the way, keep in mind that "DataStage TableDefs" have nothing to do with data lineage. They are an artifact of DataStage --- it's the Database Tables that Ray noted above that dictate lineage .....the Host.Database.Schema.Table objects... (these are what are imported via the Conn...

Lineage works exactly as you have outlined it and illustrated it....and tablenames are DEFINITELY in the metadata for the Job and in the Repository after you imported via Connector.... so I'm not sure what you are describing.

Can you outline what problem you are having?

Ernie

The check box is there for Sequence Jobs just as it is for any other, and it cascades that setting to the Jobs that it controls.....

Ernie

That makes sense....sorry I mis-read your original post --- I thought you were trying to import the metadata of OMD xml so you could then also read it using DataStage ....a worthwhile endeavor but I see that isn't what you were doing here. Glad it's working now.

Ernie

It's usually caused by the way that you are reading the file.... are you using an External Source Stage and using a unix list (ls) command to capture the file name and feed that into one of the xml Stages? If not, do some searches thru the forum here, and/or check out some blog posts I have at www.d...

Well....a couple of things to review. ..first, as a general comment, I would recommend that you NOT have OMD collection set at the project level. It is simply too voluminous, and except for very particular applications where you are doing your "own" work with OMD, it is probably not needed...

Are you starting the Job via dsjob at the command line from your central scheduler? If so, add the operational metadata flag to the command line (I don't recall the exact syntax, but it is documented). That is the best way to do selective generation of op metadata.

Ernie

I take that back. Sorry --- the xml that you have pasted up above is not legitimate xml. There needs to be an element name collecting the various attributes for each "name" line. Did you cut and paste this from somwhere or type it in manually? <Employee Place="USA" Status="A...

What everyone is saying here is to just follow the doc and give it a shot...the xml above is actually very straightforward and an excellent one to start with when learning about the various xml stages. Hint --- you'll need a table definition, and for this, the xmlInput Stage will be fine..... and sp...