RMODBB job ends with RC=04 - Reason for Deliver "RMODBB17... Record owned by user USERID" message
search cancel

RMODBB job ends with RC=04 - Reason for Deliver "RMODBB17... Record owned by user USERID" message

book

Article ID: 240808

calendar_today

Updated On:

Products

Deliver

Issue/Introduction

We have a batch process (RMOGRW and RMODDB) where we identify invalid DISTIDs and remove them. Occasionally the job receives a RMODBB17 message. The job takes control and removes the DISTID but gets a RC=04.

1. What causes a record to be owned by another user?

2. Is there a way we can identify if a DISTID is in use by another user prior to running our batch process?

Environment

Release : 14.0

Component : Deliver

Cause

Record was selected, but not saved or exited gracefully, leaving an owner lock on that record.

Resolution

Answer 1: Basically what happens is when a user SELECTS something in Deliver that record becomes locked by the owner in anticipation of a possible update. If, for whatever reason, the user who selects the record never exits that record gracefully (walks away from desk, times out, ATTN out, etc...), the record will remain user locked. Hence, the "RMODBB17... Record owned by user 'userid' message. This same lock can also be set by a BATCH job that is updating the database, not just a user.

Answer 2: We don't provide a utility that would show which records are owner locked.

Additional Information

The RMODBB17 message is documented as follows:

RMODBB17
REPORT DESCRIPTOR FOR RECORD nnnnnnn OWNED BY USER xxxxxxxx - VERIFY UPDATE OK

Reason:
The report descriptor record specified ownership by another user. Ownership of the record was taken from the user to do the update.

Action:
Verify that the database was updated correctly.