Re: SQL select seems to be creating a lock on a file

It's not surprising that the SQLRPGLE program keeps a lock on the file,
that's working as designed in order to minimize the time it takes to access
it again.

However, it should not interfere with RPG program opening the file for
update or actually updating it.

Something else is going on. What is the exact message ID you are seeing?

Is the RPG trying to do a shared open? IE. Does the file have SHARE(*YES)
or is the an OVRDBF SHARE(*YES) in play? I'm not even sure an ODP opened
via SQL _can_ be shared with RPG...but if so, I could see that the SQL ODP
would be for read only and I know that when dealing just with native RPG
i/o you can't open a shared file for read in one program first then open it
for update in another.

The only time I've seen problems with the way SQL leaves stuff open is in
job streams that run commands that need exclusive access, such as CLRPFM.

HTH,
Charles


On Tue, Jul 23, 2013 at 1:37 PM, Alan Shore <ashore@xxxxxxxx> wrote:

It's a file lock and the program is ended with option 4 (*immed) from
wrkactjob

Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Mildenberger
Sent: Tuesday, July 23, 2013 1:11 PM
To: Midrange Systems Technical Discussion
Subject: RE: SQL select seems to be creating a lock on a file

Alan,

What type of lock is it waiting on, file or record or ? Do you end the
program running the SQL normally such as exiting a display file program or
how?

Scott


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Shore
Sent: Tuesday, July 23, 2013 10:55 AM
To: Midrange Systems Technical Discussion
Subject: RE: SQL select seems to be creating a lock on a file

Hi Chuck
My "attempting to update FILEA" means that the file is defined as update
on the f-spec The program doesn't time-out (production work, with time
constraints), we have to end the program with the SQL so that the second
program that updates the file can proceed.

Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640


--
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.


Disclaimer: This message contains confidential information and is intended
only for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the
sender immediately by e-mail if you have received this e-mail by mistake
and delete this e-mail from your system. E-mail transmission cannot be
guaranteed to be secure or error-free as information could be intercepted,
corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message, which arise as a result of e-mail
transmission. If verification is required please request a hard-copy
version. Any views or opinions presented are solely those of the author and
do not necessarily represent those of the company.
--
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.