JOB LOGS

[synsog]

how to see the job logs in datastage other than datastage director.

[ray.wurlod]

Why?

That's what the Director client is for.

[chulett]

To what end? What are you planning on doing with this information?

[daignault]

You can use the dsjob command to capture the log information. You will find that syntax elseware.

There are times when developers do not have access to the production system, thus the log files, due to security concerns. At that point the director can't be used.

I would suggest having an after job routine dump the logs to a temporary file and EMail them out at the developer without access the the production machine.

Cheers,

Ray D

[ray.wurlod]

Gosh, does that mean you can use dsjob when you can't access the production system with Director? How does dsjob access the production system that's different?

[FranklinE]

My limitation is that the people who see job statuses are not trained in DataStage, let alone given logon authority to Director in production. Without going into the details, on balance I agree with that even after spending three years on a one-week-of-four support rotation, with jobs running at all hours of day and night.

Ray D's suggestion is exactly where I'm going. On any job with fatal errors in the DS logging, I'll use dsjob to extract the messages and write them to the /var/Logs text file. That, with sufficient documentation for the operator, will make it clear who is to be called next. If I had a dollar for every time I was called at 2am for a DB2, Oracle, z/OS or Unix issue... they don't need a DS developer to tell them to call the DBA or OS support guys.

I almost forgot to answer the access question: we run the batch processes under application ids, not human user ids. It works out rather nicely, actually.