OPNQRYF of non keyed file creating key fields used in RPG.

[Guest.Visitor]

You would need to define a file with the keys. You can use cpyfrmqryf after the opnqry to load that file which can be in qtemp if you like, with an override to that file in the CLP. The RPG program would name the keyed file.

[Jerry L. Birch]

OPNQRYF of non keyed file creating key fields used in RPG.

So I would have to create the DDS for a new file keyed the same as key field selections in the OPNQRYF statement and then copy to it. Would an OVRDBF from the non-keyed file in the OPNQRYF statement to the newly created file work right after the OPNQRYF statement and before the RPG program with the new file name put in the RPG program? I will probably just use a logical over the file. I was trying to get away from that because I am working with Turnover change management software in a SOX environment with multi member files. No matter what file creation specs you use, with multi member files, Turnover always defaults the new file member to the file name and you have to work around it by sending post run commands on your form to delete the first member and then add the correct members. Its a pain because you can't work with the production environment if you have problems! And I thought OPNQRYF might give me a way around the hassle. I do appreciate your help on this though. Let me know any other thoughts. Best Regards, Jerry L. Birch

[Guest.Visitor]

OPNQRYF of non keyed file creating key fields used in RPG.

What I would do is this: Define filea in dds with the keys Name that file in the RPG F spec Opnqryf the non-keyd file keyflds neeeded Cpyfrmqryf to qtemp/filea Clof Ovrdbf filea to qtemp/filea Call rpgpgm Using this approach one has to define a file, just not populate it in the production library.

[Guest.Visitor]

OPNQRYF of non keyed file creating key fields used in RPG.

Instead of taking the time and the resources to by using CPYFRMQRYF, try using the FORMAT parm on the OPNQRYF command. This parm allows you to define a different format. Have a look here IBM OPNQRYF format HTH

[DaleB63]

OPNQRYF of non keyed file creating key fields used in RPG.

In TurnOver you can override the create command, and specify MBR(*NONE). When you compile for the first time, type your 36 as normal, and press [F4]. Then specify the extra parameters on the command prompt. TurnOver will remember this for all future compiles. It also prompts you every time you compile, asking if you want to use the previous command (with overrides), or the default. There might be a way to turn this prompting off, though I can't say I've ever really looked to see if that's possible. Anyway, the file you create is just a dummy file, with necessary fields and keys; it's only needed for compiling. Doesn't really matter if it's a PF or an LF for this purpose, though it's probably easier if it's an LF. The CL with the OPNQRYF opens the actual file, but the open identifier is the name of the dummy file. The RPG uses the name of the dummy file.

[Jerry L. Birch]

OPNQRYF of non keyed file creating key fields used in RPG.

How can a file created from an OPNQRYF statement over a non-keyed file, selecting key fields, be used in a RPGIV program with the same file name and "reade" opcodes used to read the file by the selected keys? Or does the file name have to be changed to any keyed logical of the file and an OVRDBF of the non-keyed file to the keyed logical used in the CL after the OPNQRYF statement?

[Jerry L. Birch]

OPNQRYF of non keyed file creating key fields used in RPG.

Sorry for the late reply, was on vacation. Yes I tried the overrides previously but not the MBR(*NONE). I'm pretty sure it would be the same result because I've spent a lot of time on the phone with Turnover Tech support. I think the problem is that the new logical is based on a multimember physical file. According to the tech support rep it was a problem for them and with a multimember physical file, no matter what overrides are keyed, Turnover disregards them and builds the logical with a member name of the filename. Also, it only happens when you promote to the level 4 (production environment). In a SOX environment, that's the point where you can't touch it anymore to correct it and it becomes a big hassle to correct. The workaround she proposed was to allow it to build the new logical with form post-run commands to delete that member just created and add the actual members desired with ADDLFM commands. I found a logical I could use already in production and finished the project before vacation. Thanks anyway for the help.