Job access by other and cant unlock

[narasimha]

I was curious to see if DSguru2B had a magical way(which he does sometimes). I guess it was a typo huh?

[DSguru2B]

No. It wont tell who unlocked. Just tells you who initiated the thread.

[kumar_s]

The whole window shows, what job been used by which PID (Users). Once the lock is cleared, there wont be any entry there.

[narasimha]

Cool, looks like everybody is on the same page now.

[chulett]

Took ya long enough.

[DSguru2B]

It was the darn typo on my end. Meant to say "Who locked it" but instead said, "who unlocked it"

[ray.wurlod]

The only way to capture the identity of the user of the UNLOCK command would be to wrap the command in an auditing routine. This technique is not covered in any of the DataStage documentation.

Is anyone really interested? After all, once the lock is unlocked, they're off and running again. If it's done properly, no-one releases a lock unless it's owned by a process that has become defunct, and therefore could neither release the lock nor commit any further updates to the Repository.

[DSguru2B]

Hmm, interesting. So that means if an audit routine can look upon the UNLOCK command. It can look upon other commands too, right? Just for educational purposes, how would you do that.

[ArndW]

That isn't the way it would work. Since "UNLOCK" is a VOC command, the way that this could be audited would be by changing the contents of the original "UNLOCK" to call a program that would perform some sort of audit trail writing and then issue the actual UNLOCK command from there. This would be the same for whatever command you would wish to audit.

So the auditing wouldn't really be monitoring any commands but the original commands are substituted with some code that does auditing.

[DSguru2B]

Ok. Now i see. That's pretty straight forward. So basically instead of UNLOCK, i will have myUNLOCK which will perform the UNLOCK command and also take some audit details. Hmm, thanks ArndW.