We have several legacy CL and RPG/400 programs that use OPNQRYF. It is my understanding that in order to use OPNQRYF, you must use OVRDBF with SHARE = *YES (share open data path). If we do not have OVRDBF SHARE = *YES, the programs will not select any data. Let me know if I am wrong about this.
OVRDBF SHARE = *YES works fine if we run jobs in the same subsystem sequentially. However, we would like to run several jobs concurrently in the same subsystem that uses the same file(s) and OPNQRYF command. However, this has caused report programs running concurrently to have data from the other jobs corrupting the report(s). Again, it is my understanding that if you share the data path, then there is only one record pointer to the file.
Ultimately, we want to modernize our legacy programs and convert them to RPG IV with embedded SQL. If we do this, then it is my understanding that each program with have its own SQL cursor so that data does not get corrupted. Is this true?
Please let me know your thoughts on the topics I have discussed. Any help would be greatly appreciated.
Thanks, Pat
OVRDBF SHARE = *YES works fine if we run jobs in the same subsystem sequentially. However, we would like to run several jobs concurrently in the same subsystem that uses the same file(s) and OPNQRYF command. However, this has caused report programs running concurrently to have data from the other jobs corrupting the report(s). Again, it is my understanding that if you share the data path, then there is only one record pointer to the file.
Ultimately, we want to modernize our legacy programs and convert them to RPG IV with embedded SQL. If we do this, then it is my understanding that each program with have its own SQL cursor so that data does not get corrupted. Is this true?
Please let me know your thoughts on the topics I have discussed. Any help would be greatly appreciated.
Thanks, Pat
Comment