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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
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.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.
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.
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.
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep.