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


  • Subject: Triggers, Activation groups, lock levels, and QZDASOINIT
  • From: Scott.Lindstrom@xxxxxxxxxx
  • Date: Thu, 15 Mar 2001 14:04:16 -0600


I am trying to get a handle on how exactly commitment control will operate
on trigger programs initiated by inserts to AS/400 tables via an ODBC
connection.  The remote system (Powerbuilder apps on a PC, I believe)
connect to the AS/400 and cause QZDASOINIT jobs to start.  I see their
commitment control status is:

Job:           QZDASOINIT          User:           QUSER

Commitment definition . . . . . . :      *DFTACTGRP
Activation group  . . . . . . . . :       2
Default lock level  . . . . . . . :      *CS

We have database triggers defined on some of the files that these jobs will
insert records to.  If I understand correctly, the trigger programs will
run inside these jobs.  Based on all the research I have done, we have set
the RPGLE programs to run DFTACTGRP(*NO) ACTGRP(*CALLER).

Based on how these QZDASOINIT jobs run, should we be starting commitment
control using CMTSCOPE(*JOB) or (*ACTGRP)?  I'm not really looking for
'our' work to run any different than the work done by the program on the
'other side'.

It seems I'd like to run our triggers as lock level *CHG, but the
QZDASOINIT job runs *CS.  Is this a problem?

The remote task is also inserting records into an Oracle database on a Unix
platform in addition to inserting records into the AS/400 tables.  Am I
correct that an AS/400 trigger program abnormally terminating, or issuing a
ROLLBACK, or a communication failure will cause an automatic rollback to
occur on *both* systems back to their last commit point?  Therefore, the
programmers on the 'other side' need to be very careful on what they commit
and when to their own database in case we have a failure on our side.

Any experiences/insight (either thru the list or privately) would be
greatly appreciated.

Scott Lindstrom
Zenith Electronics
scott.lindstrom@zenith.com






+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.