DSXchange

If you have autopurge set for this job, try turning it off and seeing if the error goes away.

Do you have a timeout set from your administrator? Do the remote developers login directly or do they go through an application such as Citrix?

All the stages you have will continue to work. Overall you should be able to export the jobs at V5 and import them at V8. At some point server job parameters changed in that they could no longer be modified; so if you do that you might have some recoding to do. If you have a "standard" ins...

So the DataStage log states that the job ran successfully, but the file which is created in the job does not exist. Have you checked the DS log for messages of any kind (perhaps some warnings)? How does your job create this log?

Dave - good point with the attribute to select which process, I had forgotten all about and have never changed it. The default wait period for the deadlock daemon is 900; but setting it to a lower value shouldn't impact performance. Perhaps some middle value, such as 300; this would mean that the lo...

Craig - if you print out the post and hold the sheet of paper to the top of your head, you should be able to use digital osmosis and _know_ what the error message is. I, on the other, hand am going to have to wait for a description of the error message from basu.ds.

A badly written system will be slow - regardless of what platform and what tool is being used. Ray, myself and several others here occasionally get hired to sites with "performance" issues. Analyzing the causes and finding viable solutions (meaning that they satisfy cost, cost & implem...

DataStage PX jobs don't just start one PID, they start very many. It can be a challenge to track down the correct master PID, particularly on busy systems and would always recommend to activate the deadlock daemon and let DS take care of cleanup. Have you used the Director "cleanup resources&qu...

Are you talking about the DataStage "log" file that you can browse in the director, or some other file?

This is impossible to do from the information provided, it is somewhat like me stating "My car usually starts in the morning, but today it didn't. What is my problem?".

Look into the DataStage log for that run of the job - what do you see?

Using the @INROWNUM and @OUTROWNUM variables in a transform stage will give you the numbers you need, you just need to put the transform in the correct link position. If you are using a multiple node configuration then you would also need to cater for the node number.

What sort of a checklist are you trying to put together - if you could list a couple of items, then I am sure others here will assist in adding other items. I'm afraid I'm still rather at a loss as to what exactly you are looking for.

I'm not quite sure of all you are asking; but performance issues are seldom, if ever, solved by merely changing versions.

Long PID numbers are frequently truncated when displayed in DataStage. Do a "ps -ef | grep {YourPID}" and you will probably find the process. Do not do a kill -9, just a normal kill. Better yet, have your admin enable the deadlock daemon.

If you want to add 12 hours to a timestamp then use the TimestampFromSecondsSince function.