Re: procedures, dftactgrp and cursors staying open

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