DSXchange

There are usually 13 weeks in a quarter, but it still depends on how you define "week". I can not stress how important it is to get this (business rule) right.

Download EtlStats from Kim Duke's website and let it gather the statistics for you.

Does that user still need to be a developer?

Each job's statistics are kept in a separate table. You could write a routine to check all of these but why re-invent the wheel? Download EtlStats from Kim Duke's website - this will gather the data you require and more, and load it into a database table of your choice.

What's hard about it?
Wait till there are no connected client processes before restarting.

No. Must be 2005.

Craig would be even happier were you to spell his name correctly. It's Craig Hulett. One "L", two "T"s.

The local Repository is still used (in conjunction with XMETA) in version 8.0 so this query will work. As noted, the identifiers in the SQL are case sensitive.

Welcome aboard. You need to detect time zone, because it is not a fact that the difference is always the same; when the USA switches to or from summer time the difference changes. After that it's a simple matter of decomposing your timestamp into its components and performing appropriate arithmetic ...

And does your stage have a reject link to capture rows that the database would not accept? DataStage only sends rows to the database (and if it can send them, it will finish OK); you have to (design) manage detection of failures within the database.

How are your Merge stage properties set?

Where are you going to put weeks 49 through 53? You need to think more carefully about your business rules. How is week #1 in any year defined? Is it necessary that every week has 7 days? (It should be, if you're planning to summarize/aggregate by week.)

Yes you can, albeit inefficiently, by invoking yet another shell. For example (assuming PATH is correctly set)

Stopping dsrpcd will do it even in version 8.x.

Compared to what?

Naturally there is an overhead in making the initial call, but it's negligible and only occurs on the first row (on each node). After that the routine's code is in memory and its entrypoint address is known.