DSXchange

You don't "store" it, the next job can pick up the $CommandOutput variable from the Execute Command stage for example.

wahi80 wrote:I think the above code works properly in 7.5, but fails in 8.0

If that's the case then you need to involve support. That would be a bug that they'd need to fix. (or may already have fixed)

Curious what aspect you don't understand... the solution posted is extremely complete.

No, that wouldn't be needed.

You haven't done what before, updated a record using sql? This is simple sql we're talking about here so no need for a procedure. Something else to understand is if you don't have indexes over the field(s) in your where clause, each update will be a full table scan and thus not all that speedy. Howe...

Either a Routine Activity or Execute Command stage can 'cat/type' that file and capture the output. It can then be passed to any downstream job as a job parameter.

As noted, they are not supported so no gaurantees of success. I'd suggest you contact your official support provider, see if they have any ideas. And, of course, post back anything you find.

Each Sequence stage has a 'Logging Text' property. Use that to leave clues about which stages are actually getting executed.

Not Windows v. UNIX but NLS related I'd wager. What's different between the two environment, NLS-wise?

Hard to say, that is one of the many places where you do need to enclose parameter names in pound/hash signs. Rather than type the parameter into the shared container by hand, does it work properly if you use the 'Insert Parameter' option? And we are talking about passing job parameters into the sha...

Get yourself some real job control, something that will allow you to define dependancies and will keep as many jobs running simultaneously as possible. Something like... oh, I don't know... our Ken Bland's Job Control Utilities that he gives away free from his website.

kirankota79 wrote:Is there a way that i can do this without messing other columns.

How would you do this through Toad / SQL Plus and 'normal' sql? That's the same way you do it with DataStage.

Don't confuse 'key columns' with indexes, they are not equivalent. A table doesn't need a primary key in order to be updated via sql, nor does it need one for DataStage. The 'key' column attribute just marks which column(s) should be used in the 'where' clause of the update DML.

The 'event' was it reporting back that it had started, meaning it didn't... at least not fast enough. And it would have nothing to do with Invocation ids. This is a resource problem. Search the forums for "timed out waiting for an event" and you'll find many conversations on this much loved topic.

I'd be curious exactly what 'using UNIX scripts for scheduling the jobs' means. Does that mean you have a script setup for every job, series of jobs, logical groups of jobs, what? Are you leveraging Sequence jobs anywhere or for any portion of this? UNIX and JAVA are not scheduling tools. Director j...