This is how I understand PUTOVR –

You use PUTOVR for display records that you might update. That is, your program writes a record to the screen, reads it back in, then writes the record to the screen again. A user probably typed some data or pressed a function key (or just the enter key) in order to give some input to your program. But PUTOVR has a specific use for the updated display record.

Your program checks the data or the keys that were pressed and decides that it needs to write the same record back out to the screen. However, when it writes the record, it only wants to change some attributes of some of the display fields or it wants to change some of the data in some of the display fields. That is, it wants to override attributes (OVRATR) or override data (OVRDTA).

It doesn’t want to send entire screen; it only wants to send whatever small parts of the screen need to be overridden.

So, fields that have OVRATR or OVRDTA enabled will be the only parts of the screen that get sent out of your program to the display. This happens for records that have PUTOVR enabled and only happens for the fields that have OVRATR or OVRDTA enabled at that time.

Since PUTOVR only has any meaning when a record is re-written to the display, it has no effect when the record is first written to the screen.

PUTOVR is primarily for some performance benefit. It can significantly reduce the number of bytes that get sent. Of course, the total number of bytes that are sent for display screens is usually tiny compared to the total number of bytes that get moved around in most systems nowadays; so, PUTOVR probably isn’t as important as it once was.

Tom