SQLCODE -607: Operation not allowed on this object

What it means

Db2 keeps its own definitions in the catalog and its internal control data in the directory. You can read most of them with SQL, and some catalog changes are allowed, such as updating statistics columns. Many operations are blocked, though. When a statement tries one, Db2 rejects it with -607. The token names the operation or option.

The blocked operations include these.

• CREATE and DROP of objects in the catalog database, DSNDB06.
• LOGGED or NOT LOGGED on a catalog table space.
• Cloning a catalog or directory table.
• ALTER TABLE, ALTER TABLESPACE, DELETE, MERGE, UPDATE and RENAME on directory tables.
• Creating, altering, dropping or renaming indexes on directory tables.
• Using a directory table as a parent table in a foreign key, or as the table a trigger is defined on.
• ALTER TABLESPACE with MOVE TABLE on a catalog or directory table space.
• Changing the owner of most objects owned by SYSIBM or in a schema starting with SYS.

There is one less obvious case. A SELECT from a directory table has to run with UR isolation. If it sits inside a statement where Db2 can't run it as UR, such as a subquery in an UPDATE, you get -607.

Common causes

• A DDL script generated for all objects in the subsystem includes catalog or directory objects.
• Someone tries to clean up history with DELETE against a directory table such as SYSIBM.SYSLGRNX.
• A subquery against a directory table sits inside an UPDATE or DELETE, so Db2 can't read it with UR.
• An ALTER or TRANSFER OWNERSHIP targets an object owned by SYSIBM.
• A period specification is used on a table reference that isn't a table.

How to find the problem

1. Read the operation token in the message.
2. Check the target object. Look at DBNAME in SYSIBM.SYSTABLES or SYSIBM.SYSINDEXES. DSNDB06 is the catalog and DSNDB01 the directory.
3. Look for subqueries that read SYSIBM tables inside data change statements.
4. Check the creator or owner of the object. SYSIBM objects are system objects.

How to fix it

• Remove catalog and directory objects from generated DDL.
• Use the utility built for the job instead of SQL. MODIFY RECOVERY cleans up old recovery history in SYSIBM.SYSCOPY and SYSIBM.SYSLGRNX.
• Read directory data in a separate query with UR isolation, then use the results in your update.
• If an option isn't allowed for the object, drop that option and rerun. If the operation itself isn't allowed, there is no way to run it on that object.

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Db2 for z/OS documentation for your release.