RMODBASE UNLOAD receives "RMODBA15 Security authorization for database updates denied" after applying maintenance

Products

• Deliver

Issue/Introduction

We recently applied maintenance and started receiving the message above during our daily RMODBASE UNLOAD job. Rather than reassembling any exits, I just copied forward the following exits, in their current state, after applying the maintenance to the CVDELOAD library:

MEMBER=RMOATHTB
MEMBER=SARSAM04
MEMBER=SARSTCUX

I'm presuming the RMOATHTB is the one that's tripping us up.  Does that need to be reassembled due to some recent maintenance that we applied?  I didn't see anything in the HOLDDATA to that effect, so I presumed just using what we had previously would have worked.

We've been running the unload job with the same batch userid we've been using for decades.

Environment

Release : 14.0

Cause

The cause of the problem was two fold:

A. The following PTF was applied as part of customers maintenance:

LU09103 - RMODBASE UNLOAD NOT MAKING EXTERNAL SECURITY CHECK

PROBLEM DESCRIPTION:
The user with no access authority for a Deliver database is still able
to perform an RMODBASE UNLOAD command against the database.
 
Solution note:
Internal and external security validation has been added for the
RMODBASE UNLOAD function. If DBASE security requests are prohibited with
internal or external security, the user will not be able to perform an
UNLOAD of the Deliver database. The RMOATHUX user exit as well will be
called with a request type(APLREQ) of LOAD for this function.
 
SYMPTOMS:
The user is able to unload the Deliver database without access.
 
IMPACT:
The user can get Deliver database information despite being restricted
by security.

 

B. The batch userid attached to the RMODBASE UNLOAD job had never been defined to the RMOATHTB table.

 

Resolution

PTF LU09103 closed an existing loop hole regarding Deliver security.

If you applied this PTF, and the USERID's were not previously defined in the RMOATHTB table, then to resolve the problem, you ARE going to have to update, assemble and relink the RMOATHTB table with the necessary database access/update authority for the appropriate  userid's.