SQLCODE -601: Object name already exists

What it means

Names must be unique within their type and qualifier. You can't have two tables called PROD.CUSTOMER, two indexes with the same name, or two constraints with the same name on one table. When a statement would create a second object with a name already in use, Db2 rejects it with -601 and changes nothing.

The full message text is long because it covers more than plain names. It also applies to version identifiers, such as adding a routine version that already exists, and to volume serial numbers, such as adding a volume to a storage group that already has it. A RENAME whose target name is taken gets the same code, and so does a name already used by a pending definition change.

IBM's response for this code also covers data sets. For an object whose data sets Db2 manages through a storage group, check that the storage group points at the right ICF catalog (VCATNAME in SYSIBM.SYSSTOGROUP). A data set left behind with the same name may have to be deleted with IDCAMS before the CREATE will work.

For Java archives installed into Db2, the SQLSTATE can be 46002 instead of 42710.

Common causes

• A DDL script is rerun after it partly succeeded, so the objects it already created exist.
• The object was created earlier by someone else, or in an earlier release of the application.
• The statement was qualified differently from what you expected. CURRENT SCHEMA or CURRENT SQLID put the object in a schema where the name is already taken.
• An index or constraint name is reused from another definition.
• ALTER STOGROUP ADD VOLUMES names a volume already in the storage group.
• A data set with the same name is left over from an earlier object.

How to find the problem

1. Take the name and object type from the message.
2. Look the object up in the catalog. Tables, views and aliases are in SYSIBM.SYSTABLES (the TYPE column tells which), indexes in SYSIBM.SYSINDEXES, routines in SYSIBM.SYSROUTINES, sequences in SYSIBM.SYSSEQUENCES, and constraints in SYSIBM.SYSTABCONST and SYSIBM.SYSCHECKS.
3. Check CURRENT SCHEMA and CURRENT SQLID at the time the DDL ran, to see which qualifier was used.
4. For a data set clash, compare VCATNAME in SYSIBM.SYSSTOGROUP with the catalog where the data set lives.

How to fix it

• If the existing object is the one you want, skip the CREATE.
• If it should be replaced, drop it, COMMIT, and create it again. Without the COMMIT the CREATE fails with -679.
• If both objects are needed, choose a different name or qualifier.
• Make DDL scripts safe to rerun by checking the catalog first, or by dropping objects at the start of the script.
• For a leftover data set, have the storage team or DBA confirm it isn't in use, then delete it with IDCAMS.

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.