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



So,

I figured out what is going on here...

It's actually not a bug but a GROUP JOB thing.

My general setup is to have 2 separate ACS sessions and each one runs my
initial program which sets up several group jobs.

The behaviour I was seeing ( lock not being released ) is because most of
the time I was using my attn pgm to switch to another group job to try the
CLRPFM.

What was happening is that the requested "soft" lock release cannot
complete because the group job that has the lock is not the active group
job at that point.

If I run the SQL to get the "soft" lock and then try to clear the file in a
completely different session, the lock gets released.

If I run the SQL to get the "soft" lock then switch to another group job
and try to clear the file, it doesn't clear, but if I interrupt that
attempted clear and switch back to the group job with the lock, then back
again, the clear completes because the group job with the lock was made
active and therefore was able to release the lock.

So, no bug here, just my group jobs tripping me up...



On 17 April 2018 at 17:47, Craig Richards <craig@xxxxxxxxxxxxxxxx> wrote:

Hi Charles,

Thanks for taking the time to reply.

I am using cursors but not for these particular files and I am definitely
closing them.

There are 3 files - here is the insert for the first - not a cursor in
sight...

* Exec SQL Insert into AwdDtl Values( :OL.OrderNumber,*
* :OL.OrderLine,*
* :OL.ProductCode,*
* :OL.ProductName,*
* :OL.ColourName,*
* :OL.ItemID,*
* Char( :OL.DateRequired ),*
* :OL.ReqDateType,*
* :OL.Weight,*
* :OL.Length,*
* :OL.Width,*
* :OL.CustomerRef,*
* :OL.Collection,*
* :OL.SalesValue,*
* :OL.ProductType,*
* :OL.InstallRoom,*
* :OL.BookInRequired,*
* :OL.BookInRef,*
* Char( :OL.BookInRefDate ),*
* :OL.AltOrderRef,*
* :OL.CutComment,*
* :OL.StockCutID,*
* :OL.StockCutAltID,*
* :OL.SendAll*
* ) with NC;*

Running on V7R3M0, not sure about PTF levels.

I agree that it does sound like a hard lock but inserts like above
shouldn't do that should they?

regards,
Craig


On 17 April 2018 at 17:40, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

Craig,

Are you sure you've only got a soft lock?

If your program is explicitly using a cursor, you have to explicitly CLOSE
the cursor.

At that point the Db may only "pseudo-close" the cursor. Thus keeping a
soft lock.

If your program doesn't CLOSE, then your program still has a hard lock.


If the only thing your job is doing is an INSERT...then it should be a
soft
lock. And the ALCOBJ command from another job should have released the
lock.

Assuming you're up to date on PTFs, I've give IBM a call.


Charles


On Tue, Apr 17, 2018 at 10:33 AM, Craig Richards <craig@xxxxxxxxxxxxxxxx>
wrote:

Hi Charles,

Thanks for your reply.

However, that's not what I'm seeing.
I used CLRPFM because I wanted to see if the lock would be released, not
because I particularly wanted to get rid of all of the records in the
file.

Anyway, the lock is not being released after a period of a second, and
not
after several minutes.

I was unaware of the CONFLICT parameter on ALCOBJ which looks quite
interesting.
But it didn't work the way I expected. After I've run the program the
job
has a *SHRRD lock on the file.

I then ( in another job ) tried using ALCOBJ to try to get an *EXCL
lock on
the file, and specified CONFLICT(*RQSRLS)
From the Help Text I assumed that would make a request to the job with
the
lock to release it, but that's not happening.

It's not that I particularly have another process that wants to do
something with the file ( which is now locked )
It's more that I don't want to leave locks laying around if they are
going
to cause potential trouble in my unseen future...

But back to your initial comment "it can be" ... after 1 second or so.

Which in context I take to mean "the lock can be released in another job
after a second or so has passed"

Well, I'm just not seeing that.
Are you certain it is the case for you?

As I mentioned before - my situation is:
SQLRPGLE program in a named not-reclaimed activation group that has
ended
with *INLR after performing several INSERT INTO WITH NC sql statements.

thanks and regards as always,
Craigs


On 17 April 2018 at 16:46, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

It can be...

But the job & the operation must be configured to wait at least 1 sec
or
so
for the lock to be cleared.

You can also issue a ALCOBJ CONFLICT(*RQSRLS) prior to whatever
operation
you're trying.

In the case of CLRPFM, switch to an SQL DELETE is a better option
IMHO.

Charles

On Tue, Apr 17, 2018 at 9:10 AM, Craig Richards <
craig@xxxxxxxxxxxxxxxx>
wrote:

Alan,

I'd never heard this described as "soft lock" before but your
description
fitted with my experience.

I was just testing a program today, which showed that the Operating
System
will only release the "soft lock" if the process that needs to use
the
table for RGZPFM etc is the same job that has the "soft lock".
Is this also your understanding?

Specifically -
I have a program ( running in named Activation Group ) which does a
few
INSERT INTO ... WITH NC statements.

Once the program ends with *INLR, WRKOBJLCK shows locks on the 3
files
I
inserted records into.

I can clear those 3 files in the job that inserted the records, but
not
in
other jobs.

Normally I try to arrange it so that programs are run from a menu
which
will then Reclaim the Named Activation Group to close everything
down
at
the end of the base program, but not everything is run that way.

So this makes me think I might have to consider the programs not
called
that way to close the cursor at *ENDMOD....

Pfft, for some reason I thought the "soft lock" could be released by
ANY
job.

regards,
Craig

On 18 March 2018 at 23:03, Alan Campin <alan0307d@xxxxxxxxx> wrote:

SQL Cursors are always soft closed unless you either have an
error.
The
operating system will maintain a lock on the table and the
ODP(Open
Data
Path) will remind open if possible.

If you use Close Cursor *ENDMOD and the module ends or you use
*ENDACTGRP
and the activation group ends, cursor will be hard closed.

By soft close, what we mean is the cursor is left open and the
lock
is
soft
which means if some process needs to use the table, the operating
system
will release the lock. For example, you wanted to do a RGZPFM.
With a
hard
open, you cannot do this. If the cursor has been closed soft, the
OS
will
release the lock, close the ODP and do the reorg.


On Sun, Mar 18, 2018 at 2:08 PM, Craig Richards <
craig@xxxxxxxxxxxxxxxx>
wrote:

Yes

That’s what I was talking about in the beginning.

On Sun, 18 Mar 2018 at 20:36, Dave <dfx1@xxxxxxxxxxxxxx> wrote:

Maybe the cursor is closed, but with Exec Sql close cursor,
dspjob
shows
a
lock still in place on the table. I think this is normal
behaviour
when
opened in the dftactgrp. With CloSqlCsr, I don't have the
lock at
the
end
of the program.

2018-03-18 18:12 GMT+01:00 Craig Richards <
craig@xxxxxxxxxxxxxxxx
:

CloSqlCsr - as described in this thread is referring to the
way
the
*Module
is created.

Instructing the system to close the SQL cursors for you when
the
module
ends.

I suppose you could say it is a safeguard to make sure that
no
cursors
can
be accidentally be left open once the *module is exited.

If you have taken care to manually close any cursors using
Exec
Sql
close
cursor, then it won't be doing anything for you.


On 18 March 2018 at 16:49, Dave <dfx1@xxxxxxxxxxxxxx>
wrote:

Thanks, the CloSqlCsr is what I needed. Actually, I have
yet
to
be
in
the
situation when having the cursor stay open after the
program
ends
was
worth
more than the potentiel problems it can cause. A thing I'm
still
not
clear
on is, what's the difference between "close cursor" as you
would
do
before
reopening it, for example, and CloSqlCsr?

Craig, RCLRSC will not work and I believe this is
documented
I'm in the dftactgrp which wasn't completely clear in my
op.
I
wanted
to
be
able to compile but still have my program run in the
dftactgrp.
Thanks

2018-03-16 16:18 GMT+01:00 Glenn Gundermann <
glenn.gundermann@xxxxxxxxx
:

Hi Dave,

If you are referring to a SQLRPGLE program, then this is
what I
have
in
mine:

// Set SQL options.
EXEC SQL
SET OPTION
CloSqlCsr = *ENDMOD,
Commit = *NONE,
DatFmt = *ISO,
Naming = *SYS;

It was pointed out on this forum by Birgitta and maybe
others
that
CloSqlCsr = *ENDMOD isn't the most efficient if you call
the
program
repeatedly. Each person's case is different but you can
experiment.

Hope this helps.


Yours truly,

Glenn Gundermann
Email: glenn.gundermann@xxxxxxxxx
Work: (905) 486-1162 x 239
Cell: (416) 317-3144


On 16 March 2018 at 10:07, Dave <dfx1@xxxxxxxxxxxxxx>
wrote:

Hello all,

I’ve arrived at a new company and run into a bit of a
fix.
Hard
to
believe,
but there are no development standards and everyone
seems
to
do
as
he
pleases. Most are still writing new programs in fixed
form
RPG.
As
I’ve
had
to work alone with very little time or coaching, I’ve
done
as I
always
have, preferring sub procedures to subroutines. When I
came
to
compiling
I
got blocked by the error caused by not specifying
dftactgrp(*no),
which
I’d
forgotten about (I’ve been away a long time). To get
round
this, I
specified the value **no, and added actgrp(**caller)
in
the
h-specs.

During testing, when I noticed that my files and
cursors
were
remaining
open (and remembered also this behavior), it suddenly
hit
me
why
up
till
now I’ve only come across dynamic program calls in
this
shop. I
can
get
round the problem of the files, but can’t see a way of
closing
my
cursors.
Can anybody advise me? Should I just convert all my
procedures
to
back
to
routines?

*Thanks *
--
This is the RPG programming on the IBM i (AS/400 and
iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/
mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any
subscription
related
questions.

Help support midrange.com by shopping at amazon.com
with
our
affiliate
link: http://amzn.to/2dEadiD
--
This is the RPG programming on the IBM i (AS/400 and
iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/
mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any
subscription
related
questions.

Help support midrange.com by shopping at amazon.com
with
our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and
iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mai
lman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the
archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with
our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and
iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with
our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: http://amzn.to/2dEadiD
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription
related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our
affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD




As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.