DSXchange

[sigh]

See point (b) above. Then (a). Then (c).

a) This stuff isn't all that hard to figure out on your own, give it a little more effort before posting. Please.

b) The letter in front of the 'params' option is an 'l' for 'List', not a 1 as you've shown you are using.

c) That command won't get you what you want.

Interesting... I would think those two would be functionally equivalent. And a Custom trigger expects a full expression, not just 'one side' of it. Oh, I see. All you've got in the Expression is DSJS.RUNOK which is a '1' and so equates to TRUE. In other words, you've created an Unconditional trigger...

Spanish for 'what'. And 'they' use question marks at each end (the first one upside-down) to make a phrase a question.

Much like saying Huh?

1) Ditch the Sequencer stages, they're not needed unless more is going on in your job than you are telling us. 2) What is your Trigger coming out of the first Routine Activity? I'm guess it's a 'OK' trigger - routines that do not return a zero are considered to have failed so your job does not move ...

Wsn't going to mention that, figured someone else would. Just wanted to get the syntax straightened out.

-useid does not mean userid but something else entirely that escapes me at the moment.

Yes, it sure could be and that would be why I asked you to check it. Had you 'customized' your dsenv file for 7.5.1A?

What operating system are you running, by the way?

Check your dsenv file, upgrading can set it back to its 'default' or out of the box configuration. If you'd made special changes, like for the various optional plug-in modules or to include 32bit libraries before 64bit ones, you'll need to make them again.

That looks suspiciously like Oracle syntax... and it sounds like DB2 has no idea what it means. You need to find the DB2 equivalent.

Welcome. :D

The same table name? Nope. Different? Yes. Your message indicates that at least one table was 'busy' - in use by someone - and so could not be loaded.

Just to throw more chum in the water, there's no need for User Status or to check the returned value separately in a downstream activity. You can do it directly in the triggers from the Routine Activity stage as there is a trigger type specifically for checking Return values. If there's something wr...

What are you talking about?

I guess this isn't about phantoms in your log after all, but zombie or orphaned processes in the database. [sigh] Happens all the time, depending on the nature of the abort or stop. Make your DBA earn their crust of bread today - they need to kill them.

If the job aborts or otherwise ends abby-normal, it will typically log phantoms. I wouldn't worry about those - unless they are the cause of the abort, then worry. Server jobs should never log phantoms or warnings of any kind. IMHO. But I see this is marked as PX... In any case, post the phantoms yo...

You mean other than buying the Java PACK?

We've used shell scripts to invoke Java processes. Land the data, invoke, pick up the results. To do it directly in a job (as in row by row, in a derivation) requires the pack, as far as I know.