|
Complicated question. It can. If the commit lock level is *ALL or *CHG, then the record lock can be held by the first activation group until a commit occurs. During that time, the other activation group is unlikely to be able to read the record. It all depends on what you are defining as your transaction boundaries. If you update in the first activation group, commit in the first activation group and then turn control over to the second activation group and that group updates and then commits before returning, you should be able to accomplish your task, but of course, then the updates belong to different transactions. On the STRCMTCTL, you can specify that the commitment level is at the JOB or the ACTIVATION GROUP level. =========================================================== R. Bruce Hoffman, Jr. -- IBM Certified AS/400 Professional System Administrator -- IBM Certified AS/400 Professional Network Administrator "The sum of all human knowledge is a fixed constant. It's the population that keeps growing!" -----Original Message----- From: Klein Ron <ron.klein@brctsg.com> To: 'MIDRANGE-L (E-mail) <MIDRANGE-L@midrange.com> Date: Thursday, March 02, 2000 11:15 AM Subject: Commitment control >In a new application we are developing everything uses commitment control >that possibly can. However, we continue development we have run in to an >interesting question. We have not tried it yet since the specs for the >modules are still being written. I was hoping to find an answer before we >actually try to code the modules to find out if we will run amuck with our >plans or if they are doable. > >One process running in it's our activation group creates a record in a file >under commitment control. Now this process calls another in a different >activation group. The second updates the record created in the first and >also needs commitment control. Will we have any conflicts because of the >journaling or the use of different activation groups? > >TIA >Ron >+--- >| 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 >+--- > +--- | 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 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.