You can indeed create keyed files with OPNQRYF. But that’s not creating the key in RPG, nor does it allow RPG/400 to access a file by key if the program isn’t already written and compiled to process a keyed file.

If an externally-described file is keyed and the program is written to access by key, there doesn’t seem to be any point to the original question unless it’s asking about accessing by key when the program doesn’t already define the file as keyed. OPNQRYF won’t help with that. The point of the question has unfortunately never been made.

Tom

OVRDBF     FILE(QADSPDBR) TOFILE(QTEMP/QADSPDBR) +       
             MBR([member name]) SECURE(*YES) SHARE(*YES)       
OPNQRYF    FILE((QTEMP/QADSPDBR [member name]))               +
           QRYSLT('(WHNO *NE 0)')                       +
           KEYFLD((WHRLI)                               +
                  (WHRFI)                               +
                  (WHRELI)                              +
                  (WHREFI))

FQadspdbr  If   f  372    30aiDisk    keyloc(1)   

D Ddbr          e Ds                  extname(qadspdbr)
D  dbjref       e                     extfld(whjref)   
D  dbsysn       e                     extfld(whsysn)

D                 Ds                
D  qwhf01                 1     20  
D  qwhf02                 1     30

IQadspdbr  ba  02                              
I                                  1  372  ddbr

Csr   qwhf01        SetLl     Qadspdbr                                 
Csr                 Dow       not *in31                                
Csr   qwhf01        ReadE     Qadspdbr                               31
Csr                 If        not *in31                                

Csr                 EndDo

Let me note that even though it can be done, it’s not something I’d likely do again – this was as much an experiment as anything else. But the program, originally written in 1988, does still work.

Yes, an SQL index can be used inside of an RPG or other HLL program. This is because an SQL index is implemented as a logical file, so an application program doesn’t know the difference.

However, an SQL statement cannot refer directly to an index; it needs to refer to the base table or physical file, and then the SQL query engine will choose the index it uses to access the data behind the scenes. So an embedded SQL Select should use the physical file name, while an application program can use either one, depending on what keys it needs.

I learned more on this when one of our important data files exceeded its maximum record count, and we implemented DB2 Multisystem Support as a solution. So we have an SQL index over a multiple membered file, and that index is built over all members/SQL partitions. And our application programs just see one large file with the same keyed access they had before.

But I do agree with the thrust of your comments – what is Ali trying to do?

If, Ali, you want to build a keyed view of your data based on what users enter on a screen – well, this is a good job for embedded SQL. You should not be thinking of creating a logical file ‘on-demand’ for screen displays!

Creating a logical file, or an SQL view, is a matter of analysis and judgement. These things are expected to be permanent, and so you would create a keyed view when that view will make your day-to-day processing faster and less complicated.

Especially if the based-on physical file is large!

There are plenty of methods for speeding up screen programs where the users can make lots of different selections. Some depend on a good stock of logical files with different, useful keys; and others depend on embedded SQL, which is a better way to go than creating logicals just for a particular screen. OPNQRYF is not nowadays a good method.

Ali, we can give you more specific advice if you can tell us WHY you want to create logicals from inside your RPG programs, maybe giving us some examples….?

Regards,

Sloopy

However, I question what the value of creating a dynamic index or logical file really would be, as it would take time to create the index, depending on how many records are in the physical file or table. And would you then be keeping that index, or deleting it once you’re done? Without knowing how your database files are designed, it still sounds like a lot of extra overhead to me.

You’d be better off using embedded SQL to run a Select statement to retrieve the result set you want and then loop through each record for whatever processing you want to do.

Also, you mentioned RPG/400 — I hope you’re not using RPG III to do this? If so, I urge you to use the modern version of the language (RPG IV), which gives much more flexibility and power over what you can do and how you can accomplish it.

I wouldn’t recommend this way of doing this, as it can get quite messy, but here’s an overview of how it works :-

First create a Source File in your QTEMP library, and add a Source Member to it. I would take care of this in a CL program before your RPG. OVRDBF to your Source File & Member.

CRTSRCPF QTEMP/QDDSSRC
ADDPFM QTEMP/QDDSSRC MEMBER
OVRDBF SOURCE QTEMP/QDDSSRC MEMBER
CALL Yourpgm

In Yourpgm you will need the file SOURCE defined for output. Then you write one record for the definition of the record format and one record for the PFILE, followed one record for each of the keys you need in your logical file.

Then from Yourpgm you execute a CRTLF using QCMDEXC :-

CRTLF Yourlib/YourLF QTEMP/QDDSSRC MEMBER

You should now have your logical file with th keys you want.

Regards,

Martin Gilbert.

Can you pls give one example for this statement ‘You *could* create a logical file by writing a DDS source file from your RPG program ?.

I did not get this how to do.

Thanks,
Ali

You *could* create a logical file by writing a DDS source file from your RPG program and calling QCMDEXC to run a CRTLF to build the logical file, then use an OVRDBF to access that file from your program, but I wouldn’t recommend this.

Regards,

Martin Gilbert.