RPG Program Files in Update Mode
One RPG program P1 opens a file FILE1 in update mode and trailing program P2 opens the same file FILE1 again in update mode. Now P1 updates a particular record (say using CHAIN). Now P2 also want to update the same record (Say using CHAIN). will P2 recieve a new data or old data from File FILE1?
Software/Hardware used:
OS/400
Software/Hardware used:
OS/400
ASKED:
January 27, 2011 12:56 PM
UPDATED:
January 28, 2011 9:54 PM
Answer Wiki:
if both programs CHAIN to the file, are they locking the record?
If so, P2 will not be able to access the record because of the lock by P1.
When you chain to a file that is opened for update, unless you are going to update or release the record in the same cycle, you should chain with locking the record.
This is usually an interactive program where you need to wait for an ENTER key.
On the first chain, you should make a copy of the record.
Then on the enter key, you chain to the record again. Compare what you saved from the first chain and compare it to the second chain. If equal, go ahead and do your update.
If not equal, that means someone else has changed the record while you were waiting for the enter key. You would reject the change and send a message to the user on your DSPF saying someone else has changed the record. They should refresh their screen and try again
To see all answers submitted to the Answer Wiki: View Answer History.
P1 updates a particular record (say using CHAIN). Now P2 also want to update the same record (Say using CHAIN). will P2 recieve a new data or old data from File FILE1?
As long as P1 has completed the update operation, P2 should get the updated record.
I’ve never tried, but it might be possible to cause P2 to get the old record by ensuring separate ODPs, calling P2 before a COMMIT, overriding for sequential blocking so that the record CHAINed to in P2 was already in the P2 buffer due to a prior positioning and possibly other deliberate code structures; but I’d expect it to take almost deliberate actions.
If P1 called P2 before completing the update, then P2 should run into a record lock condition.
Tom
Ye thats what i am also thinking about. P2 will recieve the old record since the ODP’s will not be shared between these two programs unless it is done in CL which calls P1.
You can change the Force Write Ratio to 1
how Force write ratio will help?
Thanks
ODP’s will not be shared between these two programs unless it is done in CL…
That depends on how the file is created. Usually, the default on the create is SHARE(*NO), but that can be changed when the command is run or by running CHGPF SHARE(*YES) or CHGLF SHARE(*YES).
If the already has the SHARE(*YES) attribute, then you’d need to run an override to avoid sharing when it’s unwanted.
Objects should be created with the attributes they should have normally. Overrides should only be used for exceptions.
Tom