You have a database with 100 files referentially linked by key (account number) and the account number is being altered ?

Then for the duration of the process which alters the account nukmber, all records in the 100 files should be locked by the change process to avoid alteration by any other processes. ?

a sequential locking each record is not the same thing. Or does you commit boundary take this into account?

Did you read the manuals regarding record locks?
a cursory glance into the UDB Programming manual says

Updating database records
The update operation allows you to change an existing database record in a logical or physical file. (The UPDAT statement in the RPG/400 language and the REWRITE statement in the COBOL/400 language are examples of this type operation.) Before you update a database record, the record must first be read and locked. The lock is obtained by specifying the update option on any of the read operations listed under the
“Reading database records using an arrival sequence access path” on page 168 or “Reading database records using a keyed sequence access path” on page 169.
If you issue several read operations with the update option specified, each read operation releases the lock on the previous record before attempting to locate and lock the new record. When you do the update operation, the system assumes that you are updating the currently locked record. Therefore, you do not have to identify the record to be updated on the update operation. After the update operation is done, the
system releases the lock.
Note: The rules for locking are different if your job is running under commitment control. See the Backup and Recovery book for more details.
If the update operation changes a key field in an access path for which immediate maintenance is specified, the access path is updated if the high-level language allows it. (Some high-level languages do not allow changes to the key field in an update operation.)

So the next place to look is the Backup and recovery book.

But the real answer, as stated, is probably to use SQL for such an update.

How are the files defined — MAINT(*IMMED)? Where is the COMMIT in your code? I don’t see any referenced, only rollback.

This would be far better done with SQL than trying to issue an I/O statement for every individual row.

Tom

So your critical READE’s need to be preceeded with
- SETLL
- IF %equals
- READE

or replace them with a CHAIN
Phil

My program has more than 100 loops, and the purpose is to update the OLD_NUMBER with NEW_NUMBER…
So, all LOOP’s just READE with OLD_NUMBER, and UPDATE to NEW_NUMBER.

When READE or READ encounters, my program is facing the RECORD LOCKING problem…. irrespective of the ACCOUNT NUMBER that I have locked.

However instead of READ, when I use CHAIN my code is working fine as expected. But I cannot change all the LOOPS, and all the PROGRAMS now…

1) So, please advise me, if there is any wise way to handle this issue?
2) Why only CHAIN working, Why not READ?

Hope you understood this time.

As I specified before, problem with the first and as well as second READ

No, still you didn’t get what I mean…..! Forget about SETLL, READ every thing.. just see the below points.

I locked Acc3 record belongs to #File1 and I called my program.
- Case 1:
The Acc1 is the KEY under process. After SETLL, when READ encounters, the program says “Acc3 RECORD LOCKED BY XXXX”

#File1 for update
===========
Acc1 X2 Y2
Acc2 X1 Y1…
Acc3 A1 B1…
Acc3 A2 B2….
Acc3 A3 B3….

- Case 2:
Take Acc2 as the key field, and also the same problem.

- Case 3:
Assume Acc3 as the key field, here *PSSR will handle anyway, as the Acc3 record is really locked. So Case 1 and Case 2 were affected?

1) As per my example stated before,
how come the READE has been failed though the key passed is irrelevant to the record that was locked?

2) Why CHAIN is working, Why not READ/READE… any problem with sequential access in case of record locks?

Phil