DSXchange

I vaguely recall similar issues posted and patches or fix packs solving similar problems on version 9.1. Have you looked on Fix Central and checked with Support?

Try using the User Variables stage.

You could directly load the MDM database tables with database connector stages, however it is not recommended (likely due to the complexity of relationships, triggers, and how easy it would be to make mistakes and lose integrity in MDM). As I understand it, the approach you are using is the recommen...

None that I am aware of...

The MDM Connector stage was first introduced in DataStage 11.3 and is limited to reading and writing to MDM Standard Edition.

There was an update in this topic about unlimited users in version 11.3. The IBM license information documents for 11.3 appear to confirm that, as there is no mention of Authorized User (AU) licensing.

The operations database stores UTC timestamps, regardless of the time zone of the engine. This is documented on developerWorks; possibly elsewhere too. Do you see correctly converted times in the browser? When you log into the console, on the main dashboard, look at when the engine started. Does it ...

Specific searches on this question have come up empty. Thank you for the tip, Ray. On 11.3.1, the LIST DICT UV.ACCOUNT command reports PERMISSIONS as field number 13. I tried a LIST UV.ACCOUNT EVAL "@RECORD<13>" AS ABC command. It lists the project names in the first column and the second ...

Perhaps it is "unofficial" IBM documentation.

Do you have your credentials file permissions set to 600?

The value you found must be incorrect.

Login or su - to the db2inst1 user then run command:

set | grep -i db2

Compare each value in the dsenv file to the output from the command above.

After updating dsenv accordingly, restart the DataStage engine.

You may also want to try leaving the db2 instance value blank.

The amount of silence so far may indicate it's time for a small enhancement request.

Mine works fine by having only the user and password in the authfile, and by calling with only the domain argument, and excluding the server argument. When I add the server option into the call, then it produces the same error you reported. Just to confirm, have you tried excluding the server argume...

Not everyone can read your mind. Your original question was quite vague. Adding an example later helps a bit, later...

I think you would have to very carefully implement some fancy shell scripting to modify the .odbc.ini file.