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



Thanks Eric, I appreciate your comments.

As you may have seen in my reply to Charles, I
plan to change to use COMMIT/ROLLBACK and I do
agree with your recommend for named AG.

If I understand the benefit of CLOSQLCSR(*ENDMOD),
it is useful in a named AG if cursors are not explicitly
closed ?

(cursors are explicitly closed in this case)





-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Monday, February 03, 2014 2:22 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Activation Group design question

I don't understand your concerns with activation groups... I do think the "new" scheme you have devised will not work as expected...

Ok, so for this, I'd definitely use named activation groups, since this is intended to stay resident essentially all day. You don't want to be creating activation groups each time you execute an iteration, so just make all three use the same named AG.

Now, as to why your data is not written to disk as you want, you should explore the sql options for closing the SQL cursor. You might need to use CLOSQLCSR(*ENDMOD)

<snip>
CLOSQLCSR
Specifies when SQL cursors are implicitly closed, SQL prepared statements are implicitly discarded, and LOCK TABLE locks are released. SQL cursors are explicitly closed when you issue the CLOSE, COMMIT, or ROLLBACK (without HOLD) SQL statements. This option will be ignored in REXX. *ENDACTGRP and *ENDMOD are for use by ILE programs and modules, SQL functions, SQL procedures, or SQL triggers. *ENDPGM, *ENDSQL, and *ENDJOB are for use by non-ILE programs.

*ENDACTGRP
SQL cursors are closed, SQL prepared statements are implicitly discarded, and LOCK TABLE locks are released when the activation group ends.

*ENDMOD
SQL cursors are closed and SQL prepared statements are implicitly discarded when the module is exited. LOCK TABLE locks are released when the first SQL program on the call stack ends.

*ENDPGM
SQL cursors are closed and SQL prepared statements are discarded when the program ends. LOCK TABLE locks are released when the first SQL program on the call stack ends.

*ENDSQL
SQL cursors remain open between calls and can be fetched without running another SQL OPEN. One of the programs higher on the call stack must have run at least one SQL statement. SQL cursors are closed, SQL prepared statements are discarded, and LOCK TABLE locks are released when the first SQL program on the call stack ends. If *ENDSQL is specified for a program that is the first SQL program called (the first SQL program on the call stack), the program is treated as if *ENDPGM was specified.

*ENDJOB
SQL cursors remain open between calls and can be fetched without running another SQL OPEN. The programs higher on the call stack do not need to have run SQL statements. SQL cursors are left open, SQL prepared statements are preserved, and LOCK TABLE locks are held when the first SQL program on the call stack ends. SQL cursors are closed, SQL prepared statements are discarded, and LOCK TABLE locks are released when the job ends.

-Eric DeLong

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Gary Thompson
Sent: Monday, February 03, 2014 2:45 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Activation Group design question

I have program clle_1 currently in pilot, and am reviewing activation group design to get correct function with good efficiency.

One concern is file updates made by program sqlrpgle_1 must be read by programs sqlrpgle_2 and sqlrpgle_3.



clle_1 runs as a (almost) never-ending program, meaning it runs in a loop for about 24 hours, ends and re-starts minutes later.

The clle_1 loop has two phases, separated by DLYJOB(75) :


1) Call sqlrpgle_1 to collect pallet item and quantity picked from
a 3rd-party app running on our network and update custom files on our system i. Data from the 3rd-party app is received from IFS directory 3p_1.


Call sqlrpgle_1 to collect pallet load status from the 3rd-party app and update custom files on the i to show pallets confirmed for shipment. Pallet confirmation is received from the same 3rd-party app, but the data is received from IFS directory 3p_2.



DLYJOB(75)


2) Call sqlrpgle_2 to check for customer deliveries where all pallets
are confirmed for shipment (no updates) and call sqlrpgle_3 to load local files with delivery data, print pallet labels and transfer an Advance Ship Notice to the customer.

DLYJOB(75)


My new activation group design:

Leave clle_1 set to *DFTACTGRP

Change sqlrpgle_1 from activation group QILE to *NEW
(to force updates to be "posted", assuming that with a *NEW
activation group, when sqlrpgle_1 returns with LR=*ON, file
updates "take effect" similar to FEOD ?)

Change sqlrpgle_2 from activation group *NEW to *CALLER,
Different than the *NEW activation group created by sqlrpgle_1,
for same reasons mentioned for sqlrpgle_1.

That is a combined total of some 1,400 activation group create/delete steps per day.

All suggestions/comments gratefully welcomed . . .


--
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: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.

--
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: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.


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.