DSXchange

I think you're going to need a custom stage for this. My first thought was that you have a horizontal pivot here, but you would need to generate an arbitrary number of columns in the row (based on the value of F1) prior to the Pivot stage. And DataStage doesn't work with an arbitrary number of colum...

The partition number and partition count are also available in the Increment property of the Surrogate Key Generator and Column Generator (and, I believe, the Row Generator) stages.

In theory, at least, you can throw hundreds of servers at it, and make it go faster and faster (until you reach the point where you have more servers than rows, anyway). I'm not aware that anyone has done this yet with the Windows version but it is theoretically possible. Certainly we've set up EE o...

While you're figuring it out, you could make your server job multi-instance and run N instances each processing 1/Nth of the rows. You will, however, need to build a (parameter-driven) mechanism for selecting disjoint subsets of source rows. This will allow you to meet your deadline, albeit as a wor...

Oops, forgot about the NAME column! SELECT @ID, NAME, PATH FROM UV.ACCOUNT; to see what Arnd means. You can probably figure out what you need to do to update or replace your particular entry. If you're bored to death, why not establish your own personal centre of excellence in DataStage documentatio...

If you're on a maintenance/support contract (and they make it very difficult not to be), upgrades come at no charge. It's part of what you're paying for.

Export NullToZero Transform from another project, selecting the "include read-only objects" option. You will then be able to import it into the project from which it has been deleted. It will still be read-only.

But wait!!!

Check out Parameter Manager for DataStage brought to you by the good folks who run this site.

Even if you took them out with UniVerse/SQL you would still need to re-compile. The old object code has the old parameter definitions compiled in.

Stopping the job is the cause of the problem. There's a process still waiting to read data from a named pipe - you've stopped the job, so no data come along the pipe, and the waiting process takes a timeout. If you choose to stop a job in which any form of inter-process communication is occurring, t...

The problem with Martin's solution is that you need the (user-written) GetParm routine. It doesn't ship with DataStage. Someone wrote it at, or for, Martin's site.

If you've been punctilious with maintaining the link between the table definition in the Repository and the Hashed File stages in all jobs (that is, always loading from or saving to the Repository), then you should be able to use Usage Analysis in the Manager to show you the jobs in which that table...

You will need to set that table to auto-commit - that is, one row per transaction. Otherwise the job will abort without having sent a commit statement!

If you hack the repository to make some objects read-only, you will need to ensure that you include read-only objects in the export. To be honest, I'm not sure how (or if it is even possible) to specify that to the dscmdexport command.

It may also be that you lack SELECT privilege on the relevant system tables, the ones that contain the metadata (in DBA talk, definitions of tables, columns and other database objects). Check with your DBA if you have access.