DSXchange

It's an "open beta" - that means available for all IBM Information Server customers. But you've missed much of it.

You don't need Ereplace() to split. Field() function alone will suffice.

Learn patience. I typically don't respond to posts at 4am my time. DSXchange is an all-volunteer site whose members post as and when they can. If you need one hour response, sign up with your official support provider for priority service (and good luck finding one who'll agree to a one hour SLA!) ...

This stage has a block property. It can deliver a block of N keys from the state file at a time. These are held in memory by the process and consumed as needed. The next time the list gets exhausted the SKGen stage goes back to the state file and retrieves another block.

The problem occurred in your network ("communication link"), not in DataStage. Have your network administrator investigate.

In Version 8.1 in the Real Time folder you get the MQ Connector. The MQ Series stage is still present. The MQ Read stage is in the Transactional folder. There is no Unit of Work stage.

There's no legal way to do this. If you export the job you will be able to find the encrypted password, then you can search DSXchange for a naughty algorithm that would allow you to decrypt it. By the time you've done that "they" may have changed the password. Change the job design to use ...

EOTCOUNT is not the same as rowcount.

This is a great opportunity to use some of the server engine (formerly UniVerse) capability to treat a directory as a table. You can build a query that returns the file names in your range. Begin by calculating the end dates of the range. A Routine activity is probably the easiest way to do this. Yo...

This is a server job. Don't know why this behaviour would have changed between version 7 and 8. I think you need to involve your official support provider - there may be a patch to address this issue.

kumar_s wrote:The trick is, you ll have to find the list of statements that has to be executed in ETL box and the ones that has be executed in DB box for better performance.

Ah, that sounds like the "balanced optimization" feature coming in the next version!

Welcome aboard. The rule of thumb is that the IADB needs to be three to four times the size of the volume of data being profiled. While this is all "permanently" stored you can clean it out once no longer required. Analysis results are stored in the common metadata repository (XMETA). In c...

No-one has all that in their head. Luckily it's all documented on the IBM web site "Fix Central".

... or even a Modify stage.

I guess it's because it didn't add anything new. NullToValue() was already mentioned in my answer.