Re: ovrdbf SHARE parameter

Exactly - sharing an ODP means that each program gets the current state of that ODP, which includes where the record cursor is pointing to. And I hope Chuck makes sure I said that right, because it IS early here!

A demonstration is simple enough to make - here are 3 programs to show how it works -

CLLE pgm VERN/TESTSHRODP

pgm
ovrdbf qcustcdt share(*yes) ovrscope(*job)
addlible qiws
call vern/shrodp1
rmvlible qiws
dltovr qucstcdt lvl(*job)
endpgm

RPGLE pgm VERN/SHRODP1

fqcustcdt if e disk
Dshrodp2 pr extpgm('VERN/SHRODP2')
/free
read qcustcdt; dsply cusnum; callp shrodp2();
read qcustcdt; dsply cusnum; *inlr = *on; /end-free

RPGLE pgm VERN/SHRODP2

fqcustcdt if e disk
/free read qcustcdt;
dsply cusnum;
*inlr = *on; /end-free
The result displayed on screen is

DSPLY 938472
DSPLY 839283
DSPLY 392859

The first 3 records of QIWS/QCUSTCDT on our system start with these fields

CUSNUM LSTNAM INIT
938,472 SSSchoen G K
839,283 Jones B D
392,859 Vine S S

If you want to change SHRODP2 so that QCUSTCDT is an update file, it will error out as is - you have to OVRDBF SHARE(*NO) first. I did not test that fully.

Vern

David FOXWELL wrote:

-----Message d'origine-----
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Vern Hamberg
Objet : Re: ovrdbf SHARE parameter

David

You do not say what calls RPG2 - if CL1 calls the OVRDBF SHARE(*YES) and then calls RPG1, which opens the file, then RPG1 calls RPG2 which also "opens" the file, RPG2 is using the same ODP as RPG1. Whatever you do in
RPG2 as far as reading a different record, that will change what RPG1 sees when control returns to it.

Vern, are you saying that if RPG1 is reading a file sequentially has read record 1 then calls RPG2 that reads record 2 then returns, RPG1 will then continue with record 3?