CPF5009: Duplicate record key in member

What it means

CPF5009 has the text "Duplicate record key in member" followed by the member name. It is a diagnostic message with severity 10. It doesn't stop anything by itself. Its job is to explain the failure that comes next, which is usually the notify message CPF5026, duplicate key not allowed.

The detail is in the second-level text. Press F1 on the message and it gives the member number, record number and record format of the record the program tried to write or update. It also gives the record that already has the same key. When the record number of the failing record is zero, the duplicate came from an output operation, a new record that was never stored. A non-zero number points to an update that would have changed the key of an existing record.

The member named isn't always the file the program opened. A physical file can have several logical files and SQL indexes built over it. If any of them requires unique keys, a write to the physical file fails when it would break that rule. CPF5009 then names the member of the unique logical file or index, which can be a file the program never refers to.

Common causes

• The program wrote a new record with a key that is already in the file, for example an order number that was handed out twice.
• An update changed a key field to a value another record already has.
• A logical file with UNIQUE in its DDS, or a unique SQL index or constraint, is built over the physical file and uses a different key from the one the program reads by.
• A load or conversion program ran twice, or ran against a file that wasn't cleared first.
• A trigger program on the file writes to another file, and that write breaks a unique key there.

How to find the problem

1. Run DSPJOBLOG, put the cursor on CPF5009 and press F1. Note the member and library named, and the two record numbers.
2. If the member named isn't the file the program opens, run DSPDBR FILE(ACCTLIB/ORDHDR) on the physical file to list the logical files over it, then DSPFD FILE(ACCTLIB/ORDHDRL3) TYPE(*ACCPTH) to see its keys and whether they must be unique.
3. Look at the existing record with SQL using its record number, for example SELECT * FROM ACCTLIB.ORDHDR WHERE RRN(ORDHDR) = 1376.
4. Compare its key with the key the program was writing. The program's variables in a dump or in debug show the new value.

How to fix it

• Use a key that isn't taken. If keys come from a counter, check that the counter wasn't reset or restored to an old value.
• If the record already exists and should be changed, update it instead of writing a new one.
• If the unique rule is wrong for the business, change the logical file, index or constraint. Do this as a design change, because other programs may rely on the rule.
• For a rerun of a load, clear the target first or make the load skip records that already exist.
• Have the program handle the error. RPG returns status 01021 and COBOL returns status 22, so the program can report the record and carry on.

What it looks like

Duplicate record key in member ORDHDRL3.
Duplicate key not allowed for member ORDHDRL3.

DSPMSGD MSGID(CPF5009) MSGF(QSYS/QCPFMSG)

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 documentation for your IBM i release.