Trick with RTNDTA:

In most of our RPG program we would perform the following steps:
1. CHAIN and release the database record without lock.
2. Move the appropriate database fields to the screen fields.
3. Display the screen.
4. Read the screen looking for changes and, if changes had been made, then we would CHAIN again to the database record.
5. Move the appropriate screen fields to the database fields.
6. Finally, update the record.

This process can be made easier with the DDS keyword Return Data (RTNDTA). This keyword can eliminate the need to create separate variable names in display files used for database file updates. The display file can reference the database fields instead. No need to worry about field attributes matching between the database file and the display file. We don't have to code any MOVEs or Z-ADDs, and the program size is smaller as there are not as many variables.
Here's how it's done.
DDS coding:
Place the RTNDTA keyword at the record level on the appropriate record of the display file. Use the database field names and reference the database file. This will bring the database fields into the display file automatically when you retrieve the database record.
RPG coding:
1. CHAIN and release the database record.
2. Display the screen.
3. Read the screen looking for changes and, if changes have been made, CHAIN again to the database record.
4. Reread the display format using the READ operation. This is what makes this technique work. Since we CHAINed again to the database record, the internal representation of the display file record is overlaid and any changes to the display record are lost. But by reading the display record again (with the RTNDTA keyword), you can retrieve the original values of the screen.
5. Update the database record.
Although this is not a mind-boggling, high-glam tip, I found it to be quite helpful.