Re: procedures, dftactgrp and cursors staying open

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