DSXchange

Complex XML can be slow to generate in DataStage. This is where Ken's advice would come in - split up the output file and run the XML half in multiple instances. Perhaps that way nine women can have a baby in one month.

Yes, from what I understand, the entire XML file is loaded into memory to be parsed depending on the methodology used. At least that has been my experience on the Server side of the product, unsure how a 'folder-less' PX implementation would effect things. Perhaps Ernie can shed some light on the go...

Sorry, but you still have not told us what you mean by 'encode' here, that's a pretty generic word. It's not so much about the input - what kind of output are you expecting from the stage?

Do you know what the maximum 'number of installments' would be? That answer could drive the solution from 'use X links' to the technique outlined in the FAQ post on creating many rows from one.

From a private email: Can you give me the sample routine about this scheduling how to implement and how to use it in job sequence. First off, please keep the conversation here in the forum. That way anyone can answer and everyone can benefit from the answer. Second question first. Using something li...

Based on what you've posted, it sure sounds to me like increasing the page file size would be the next thing to try. According to the linked KB article, you may be able to create one greater than 4GB if you are running SP1 with the /PAE switch - otherwise you'll need to create multiple page files.

Again, define what in the heck you mean by 'encode'. Only then can someone help you with the proper 'command line' to accomplish that.

You've got a new problem now and should (technically) start a new topic. However, try leaving the date in internal format, from what I recall that's what the DB2 stage expects.

Nope, the -jobstatus option includes the -wait, no extra charge.

Of course there are ways. Where is your 'bottleneck'? Split the job in two, land the data to a flat file. How long does each half take?

With the -jobstatus option, a return value of 1 is 'success', not zero. An abort would have returned a 3.

Ah... sorry, missed the 'a' in front of the word 'bouncing'. I only jumped in because there have been times in the past where people haven't understood what 'bounce' means in that context, so was trying to be helpful. Silly Wabbit.

Jury will disregard the statement made by the witness.

"Bouncing" = "rebooting" = stopping and then restarting DataStage.

It can optionally send 'stop' requests to other jobs that are still running in the Sequence when you hit the Terminator stage. Then it aborts the Sequence.

Sequencers are also used to terminate links if need be. And you only need a Terminator when you need something terminated - hence the name. Did you read the help for the stage? It aborts the current process and optionally can abort all other running jobs in the Sequence as well.