× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.