Re: RCVF - how to do multiple CHAINS in one CL pgm

On 02 Jun 2012 16:03, Vern Hamberg wrote:

I have to ask - maybe it already was - the OP is in a COBOL shop, I
believe - I'm wondering about why this isn't just being done in
COBOL (or RPG for others of us). Dancing around CL for file IO is so
much harder than just using a language made for it.

Asked\suggested already; e.g.
http://archive.midrange.com/midrange-l/201205/msg01292.html

On another tack - as a general rule, I found it can be problematic to
go directly to these system tables, whether in CL like this or in an
HLL. I don't remember if format level checks are done in CL - but one
of these files changed at v7.1, and a program compiled over it at an
earlier release will blow up.

DCLF stores the Record Format Level Identifier, shown in DSPPGMREF, and passes that on the Open effected by the RCVF. Thus the RCVF as open can get a CPF4131 just like an Open with other HLLs. However notice my example uses a user-defined file\format MYDBXREF, rather than directly declaring the system file. Thus there is no concern for level check. And LVLCHK(*NO) is _not_ required in my example. While the OPNQRYF names the publicly available file, that request tells the open to use the RcdFmt defined on the FORMAT() parameter. That Query Record Format is established for the Query ODP [ie. the OPNQRYF is issued] *before* the override TOFILE(QADBXFIL), else the FORMAT() also would have redirected to that system file.

It seems safer to go with embedded SQL. Doing something like RUNSQL
in CL and then jumping through hoops - more work than we like to do,
normally. Of course, Bruce V. has utilities to help with this.

http://archive.midrange.com/midrange-l/201205/msg01288.html

Anyhow, just a fair warning out of my own experience, as well as a
general question.

Because I had already suggested CL is probably not a good choice, I am since, merely describing how one might better enable the CL to do possibly similar work without either the excessive open\close activity that would be required by some other means [using CLOSE or CPYF] that have been suggested, and without deferring to other objects such as another HLL program, utilities [like a QMQRY or RUNSQL], or non-OS features as suggested in even other messages.
http://archive.midrange.com/midrange-l/201205/threads.html

If curious... Use the following DDS source to create a file named MYDBXREF [it has to have a member :-( but can remain empty] to better understand how the CLP in my prior message [quoted below] does what it does, without concern for level checking with typical changes [added fields] to the definitions of QADBXFIL:

//DATA FILE(MYDBXREF) FILETYPE(*SRC)
REF(QSYS/QADBXFIL)
R QDBXREF
DBXFIL R
DBXLIB R
DBXOWN R
DBXATR R
DBXTYP R
DBXTXT R
DBXNFL R
DBXNKF R
DBXUNQ R
DBXSO R
DBXRDL R
K DBXFIL
K DBXLIB
//

Regards, Chuck

On 6/2/2012 5:37 PM, CRPence wrote:

Although there was no followup to better describe the actual
scenario, I will offer the following scenario as an example of
something like what I alluded to in the quoted message:

The desired effect is to retrieve the rows with the following key
values [shown delimited by quotation marks] from the System
Database Cross Reference file QADBXREF, using the Access Path
defined by the Logical File QADBXFIL on the two fields (DBXFIL,
DBXLIB) which are each 10-byte character:

"QCLSRC QGPL "
"QCLSRC PLIB07 "
"QCLSRC C1 "

dclf mydbxfil /* like QADBXFIL; min.: omit unsupported flds */
opnqryf qadbxfil *inp opnid(xfil) format(mydbxfil)
qryslt(' dbxfil *eq "QCLSRC"
*and dbxlib *eq %values("QGPL" "PLIB07" "C1")
')
ovrdbf mydbxfil qadbxfil share(*yes) ovrscope(*calllvl)
loop:
rcvf opnid(*none)
monmsg cpf0864 exec(do)
...
enddo
...
goto loop
...
clof xfil