What it means
Before a program can run any SQL, Db2 checks two things. The first is whether the user may connect to the Db2 subsystem from this environment, such as batch, TSO or CICS. The second is whether the user's authorization ID may execute the plan. If either check fails, the connection, or the first SQL statement, gets -922.
The message has an error type, such as PLAN ACCESS, and a reason code. PLAN ACCESS with reason 00F30034 means the ID isn't authorized to run the plan, which is the case you'll see most. A PLAN ACCESS error can also mean the plan doesn't exist, so check the plan name too.
Connection checks are normally done by RACF, through profiles in the DSNR class. A batch or TSO connection to subsystem DB2P, for example, needs READ access to the profile DB2P.BATCH. A refused connection carries a different error type and reason code from a plan failure, and some attachments report it with their own message as well.
Common causes
- The user ID that runs the job has no EXECUTE privilege on the plan, and neither do its RACF groups.
- The job runs under a different user ID than expected, such as a scheduler ID that was never granted access.
- In CICS, AUTHID or AUTHTYPE on the DB2ENTRY or DB2CONN passes Db2 a different ID from the one that was granted access.
- RACF doesn't permit the user to connect to the subsystem from this environment through the DSNR class profiles.
- The plan was freed and bound again, which drops all EXECUTE grants on it.
How to find the problem
- Read the error type and reason code in the DSNT408I message.
- Work out which ID Db2 checked. In batch it's normally the job's RACF user. In CICS it comes from AUTHID or AUTHTYPE on the DB2ENTRY or DB2CONN.
- Check grants on the plan with
SELECT GRANTEE, EXECUTEAUTH FROM SYSIBM.SYSPLANAUTH WHERE NAME = 'PAYPLAN'. The grant may be to PUBLIC, to a group or to the user. - For a connection failure, ask the security team to check the user's access to the DSNR profiles for the subsystem.
How to fix it
- Grant EXECUTE on the plan, preferably to a RACF group the user belongs to, with
GRANT EXECUTE ON PLAN PAYPLAN TO PAYGRP. - Run the job under the right user ID, or have the scheduler's ID granted access.
- In CICS, correct AUTHID or AUTHTYPE on the DB2ENTRY so Db2 sees an ID that holds the grant.
- For a connection failure, have RACF permit the user or group READ access to the right DSNR profile.
- Change a plan with REBIND, or BIND PLAN with ACTION(REPLACE), rather than FREE and BIND. Existing EXECUTE grants stay in place. Add RETAIN if the bind also changes the plan's owner, or Db2 revokes EXECUTE from the old owner.
What it looks like
PAYRUN01 STEP010 - DSN RUN PROGRAM(PAYCALC) PLAN(PAYPLAN) DSNT408I SQLCODE = -922, ERROR: AUTHORIZATION FAILURE: PLAN ACCESS ERROR. REASON 00F30034 DSNT418I SQLSTATE = 42505 SQLSTATE RETURN CODE