DSXchange

Specifically, the Key Change column is set to True (1) when the first record in the "group" is detected, meaning the group has changed. It is False (0) after that as long as it sees the same group value, i.e. it has not changed. So it's not as simple as looking for a "1", I'm afr...

What have you tried?

Did you have any space issues on the disk / partition where the DataStage projects reside? Sounds to me like your repository (the 'legacy' Universe side, not XMETA) could be corrupted as the Director takes a different path through the jobs to get status information than the Designer does to get desi...

Ray would have to supply that, if still applicable.

Substring. Use the substring operators "[]" to take the first three and the rest of the field and concatenate the period between them. Off the top of my head and without any kind of syntax check: Current Diagnosis_Code[1,3] : '.' : Current Diagnosis_Code[4,999] That final size isn't import...

Verify that you used the exact email address noted above.

On successful completion of main job/sequence ... execute a successor job to trap 'user variable' mentioned in your post, convert string from YYYYMMDD to Date format, increment date by 1 (see DateOffsetByDays function) and then convert it back to YYYYMMDD and overwrite the control file. That would ...

As noted, involve support if you haven't already.

So... you aren't trying to do as I mentioned, you are doing exactly that and it (the act of passing in the value) is working just fine. Sounds more like a typical Oracle explain plan problem. I would think it would be helpful to clarify your 'new sql execution plan is being created' issue, provide s...

Unfortunately, there's nothing that Ray or I can do about that. We don't have the power and are (when you get right down to it) users of this site like you and everyone else are. In your efforts to get this corrected, did you email "editor@dsxchange.net"? That's the only avenue that I am a...

DataStage is notorious for stripping single quotes from parameter values, which is why you needed to escape them.

Not sure what combo you think I posted, but your second post of "another way" is exactly what I meant. Those would be the "proper quotes" and the environment variable noted in the IBM document keeps DataStage from stripping them out as it tends to do. Adding the parens to the SQL...

It's the typical upgrade problem we see time after time and which I've already commented on in this thread - you've gotten away with something, taken advantage of a bug / loophole that has been closed. Technically, it never should have worked 'without any issue' in your old environments but it did. ...

Put the proper quotes in the string and then leverage this:

http://www-304.ibm.com/support/docview. ... wg21386517

Short answer? You enclose them in hashes (#) in the SQL:

SELECT X FROM Y WHERE Z = '#JobParameterName#'

If you've tried something like that without success, you'll need to provide details around what you tried and what did (or did not) happen.