RE: ovrdbf SHARE parameter

After finally understanding what the share(*yes) actually did, I wondered why we'd never had a problem.
Today, I deployed a program ( luckily still in a test environment ) and a coworker came to see if that had something to do with his test program crashing.

We found :

CLP
OPNQRYF (myfile) with kfld changed from 5 to 3 kflds.
call testpgm


testpgm calls mypgm which also uses myfile and the 5 original kflds.


Obviously, the opnqryf must be changed, but how should we have done it?

-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Vern Hamberg
Envoyé : jeudi 4 mars 2010 14:05
À : Midrange Systems Technical Discussion
Objet : 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?

--
This is the Midrange Systems Technical Discussion
(MIDRANGE-L) mailing list To post a message email:
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,
please take a moment to review the archives at
http://archive.midrange.com/midrange-l.