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

Hi Charles
My investigation is also showing "working as designed".
However, this is where the plot thickens.
This has been happening Friday and Monday night ONLY.
Never happened before (in literally years) - now I am finding that the second program has been starting later and later, so that this situation for the 2 programs is now encroaching on each other.
Basically - it's a timing issue.
A good night's sleep and all of today just wasted.
My apologies to everyone for wasting their time.
My problem is trying to work out why program 2 is so late in being started these past 2 nights

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 Charles Wilt
Sent: Tuesday, July 23, 2013 2:14 PM
To: Midrange Systems Technical Discussion
Subject: 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.

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