RE: SQL update vs RPG/DDS update

From: Gene Burns

We have a situation where multiple users are trying to update a DDS

based

file at the same time. The user that gets the lock and updates the file

can

see the update. The other users do not see the update that the first

user

did to the file. The FRCRATIO is set to *NONE. The system knows that

the

file has been updated by the first user, but the data has not yet been
physically written to the disk. Therefore the other users cannot see

what

changes have been made.

My question is; Would this still happen if the file was an SQL table?

What if this was an SQL update to the DDS file?

I'm not sure what your problem is, Gene, but it is not that dirty records
are being hidden from users due to caching. The beauty of the single level
store is that there is no such thing as a dirty record. When you access a
record, you are accessing address of the virtual memory location where it
resides and that memory is the same for all users.

WRITEs may be deferred and that is controlled by the FRCRATIO. But in all
of my years working with this architecture back to the S/38 days, once a
record is updated everybody sees it.

The ONLY exception is when you throw commitment control in the mix. If you
have commitment control and you haven't yet committed the changes, then the
changes are not yet visible to others. This is by design, and if you are
using commitment control you need to understand your commit boundaries.

Joe