DSXchange

Also wanted to say that if you've got time for some reading, then it would behoove you to hit Ray's site http://www.raywurlod.com/ and download the XML Best Practices document hosted there. It's old and uses Server jobs to illustrate the lessons but the techniques are all sound and just as valid tod...

So it's ok to perform a simple column add, the issue is when columns in the stream need to be transformed. Ah... been too long.

I never had a chance to use it.

If you don't get any bites here, best to ask those questions of your official support provider if you haven't already.

syang@collaborative.com wrote:I am currently using the transformer stage to add an update field.

Ray or whomever - doesn't this rule out the use of RCP?

Being new I'd suggest you stick with the XML Input stage, this rather than the fancy new XML 'Composer' stage - save that one for when you get more experience under your belt. XML Input is pretty straight-forward. And what the xsd's metadata will get you are what is known as the XPath Expressions, w...

Just to clarify the challenge here - you've never handled XML in DataStage before or you've never done anything with XML before? At a very high level, the job design is basically: External Source stage to pass in the filename to process XML stage to read the file and parse the input into records NZ ...

Sure... assuming it's actually a space. And I thought using the colon as the delimiter would be more illustrative of the function's use.

I wouldn't have suggested it if it wasn't in Server jobs, they were my bread and butter for many years.

Investigate the Field() function which can extract fields from a delimited string. Tell it you have a ":" delimited string and you want the fourth field and all fields after that. I'd rather you do this on your own rather than simply hand off the syntax as it's a better learning experience...

Ideally... should... I agree. However, there's only two things that error means and like I said I'm sure the job is compiled. :wink: Double-check that you are indeed passing in unique at run time Invocation ID values. The fact that later you can run it successfully without any changes / intervention...

Typically "not a runnable job" means the job is already running. It can also mean it is not compiled but that would not be the case here.

Not sure that one job would be any more 'optimal' than two since the loads need to be done in a serial fashion, one after the other. I would think Eric's suggestion could still work as long as the input order is maintained.

Can there be more than two rows? Regardless, seems like an Aggregator with MIN(STRT_DT) and MAX(END_DT) should get you what you want.

Unfortunately, with so little information posted there's not much anyone here can do for you. You either need another set of eyes or to enlist support for help.

Ah... you failed to mention the fact that you were writing your target files back into the source directory.