“I’m sure I entered it, but it isn’t there.”
That problem appeared in an AS/400 application we had been using for a long time.
I had developed it for entering basic information, such as names, for ten people at a time.
Two people entered the information independently. The application compared their entries and stored matching information in the production database. This was not one person typing everything twice.
That verification step was part of the everyday work.
Initially, responsibility for the input was divided among staff. Under that workflow, separate groups of records did not create conflicts with one another.
Later, the workflow changed, and the work was brought together.
By then, the application had been running for about thirty years. (Laughs.)
The last few people in one group of ten could overlap with the first few in another group. When I investigated, that overlap turned out to be the problem.
There are two separate checks to keep in mind here: comparing the two people’s entries, and checking whether another job has changed a record.
An application can run for years before a change in how people use it brings a previously hidden issue to the surface.
Keeping Up with the People Doing the Typing
For other processing at the time, I used pessimistic locking: acquire a lock first and make competing updates wait.
For this application, though, the speed of the reception staff mattered too. I did not want a tool designed to enter ten people’s information at once to keep those staff waiting.
So I introduced optimistic locking into this application.
I saved the information from the initial database read in an array. At update time, the program checked each of the ten people’s records to see whether another job had changed it.
If this conflict check found no change, the program proceeded with that record’s update.
If another job had changed it, the program skipped updating that record from the current job and displayed a message on the screen.
One conflicting record should not make the work entered for everyone else go to waste.
How Much Work Should Someone Have to Repeat?
The name “optimistic locking” might sound rather carefree.
What I did in this application was check for changes at update time and withhold the update for a record where a conflict was detected. The entries for records without conflicts could still be used.
“Someone else was working on one of these people, so please do all ten again” would be a frustrating response for the person doing the typing.
I wanted to protect both the data and the work people had already done—including the effort of two people entering and verifying the information.
I also use optimistic locking in another project today. But sharing the same principle does not mean using exactly the same implementation. How often records are likely to overlap, and how quickly people enter information, matter to that choice.
If I had applied that other project’s approach to the application in this story, I think I would have heard a chorus from reception:
“It’s so slooow!”
That is my imagined reaction, based on knowing how fast those staff could type. It is not a complaint I am claiming they actually made.
Make as much use as possible of the work people have already done.
I do not want the people using my applications to experience frustrations I would dislike myself. That way of thinking has become a habit.
Where should we check for a conflict? Which updates should proceed? Which part needs someone’s attention again?
For me, those decisions about concurrency control start with picturing the person working at the screen.
Sources and scope
This account is based primarily on my recollections shared on November 1, 2026, about an AS/400 application I developed in the past. The approximate thirty-year period is also from memory. No incident resolution or user dialogue has been invented.
The steps describe the design approach, not reconstructed source code or a complete implementation guide. The exact information compared, and the locking details between checking and updating, are outside this account.
For background, IBM Documentation describes an SQL approach to optimistic locking that includes the originally retrieved values in the update conditions. That reference explains a related concept; it does not establish that my historical implementation used SQL.
IBM Documentation: Select a stringent level of commitment control, IBM i 7.4