Walter47 | Nov 2 2007 3:41PM GMT
My first guess is that something has precedence. An ovrmsg msgid (PFxxxx) would do it.
There are only two rational alternatives. First, stop locking records while batch processes are running. Second, change the batch processes so that they handle the locks — retry until the lock clears, send messages to someone who will take action or have the batch job end the offending job.
Maybe simplest is to have the batch jobs allocate its files with an appropriate locking level, e.g., *EXCLRD. Other processes could still inquire, but none would get update locks. The batch process would know at the start if other processes already had potential for interference.
By issuing ALCOBJ at the start, very little change (if any) would be needed internal to the batch process. The allocation could be made in a wrapper that was entirely outside existing batch programming.
But a real answer requires an understanding of what is meant by “proficient” in your question. It also requires knowing something about your batch process.