DSXchange

Yes, as long as you don't have any jobs running while you do so.

I think either Server / Parallel would be more appropriate than here; I just don't think converting .dsx to .xml is a frequently asked question

You APT_CONFIG file tells the runtime engine where to write the scratch data. You will either need to enlarge your scratch disk(s), clean them of old data, or point your nodes to different locations.

How about using Kim Duke's Parameter Navigator ?

Please refer to the InstallShield Knowledge Base page here

None, its just that "P0" means Pin 0, whilst there is no "R0" in the internal structure of the job layout.

Anna,

I took a gander at the document and it does indeed state that a rebuild might be necessary, but that only applies to changes made to the shared memory limits and doesn't apply to ulimits.

No, it won't work that way. DataStage has no way of knowing that a parameter has been encoded and needs decoding prior to use. You might be able to use your own algorithm and decode the parameter within a sequence and then pass the cleartext to a password parameter (which encodes & hides its val...

There is no .dsx to .xml format conversion tool. You could create an empty project and import a .dsx and then export an .xml format to effect the conversion. BTW, the thread doesn't belong in the FAQ forum.

You can also search on OPENSEQ and CREATE

Great work, Roy! All those posts and you have a growing family...

I responded to your other thread. I thought you were talking about encrypting data, not the passwords. Passwords are a special case so that nobody can go through the log files and see cleartext passwords. The algorithm for DS password encryption is not published .

Paddu - delete the 6 objects. Do a COUNT of DS_JOBOBJECTS. Import them again an do another COUNT. Are the values the same? Are you getting any messages during the import? IS your .dsx from a 7.5 and your project in a 7.1 version?

the password type is the only internal encryption that DS does and the algorithm is not published. The main purpose is to obfuscate entries so that passwords cannot easily be seen when looking at log files and entries. Jobs expected a cleartext passswords as input and then encrypt it, so you cannot ...

You've got to give us more than that. What are you doing in your ODBC stage? Do other stages work? Is this a permanent or sporadic error?