When we do a OPNQRYF in CL we tend to do a OVRDBF with a SHARE (* YES) before that.
Can someone tell me the significance of SHARE (* YES) in this regard.
When we do a OPNQRYF in CL we tend to do a OVRDBF with a SHARE (* YES) before that.
Can someone tell me the significance of SHARE (* YES) in this regard.
OPNQRYF was a very neat feature back in the day, before SQL. ( Introduced in one of the last releases of the System/38. ) The idea was the OPNQRYF command would be used to join tables together, group rows, sort them, define columns as mapped fields. Then call an RPG program where the input file defined in the RPG program had the same name as the FILE or OPNID specified on the OPNQRYF command.
In the case where the OPNQRYF command is joining multiple files, or defining mapped fields, the file in the RPG program is actually an empty file that contains a record format that matches all the fields defined in the OPNQRYF command.
Normally when an RPG program opens a file it searches the library list for the file. But in the case of OPNQRYF that will not work. The file the RPG program was compiled against has no records in it. It is used just to define the record format of the input from OPNQRYF. The OVRDBF command is then used to open the file as SHARED(*YES). Meaning, the RPG program will use the existing OPNQRYF open of the file ( or OPNID ).