Are you using embedded SQL or native I/O?
If you are using native I/O and do not explicitly specify COMMIT in the F-Specs, no commitment control is involved.
If you are using embedded SQL and compile with COMMIT *NONE (or have an SET OPTION statement with COMMIT=*NONE) is included, no commitment control is involved.
If no commitment control is involved it does not matter whether commitment control is started or not.
We start commitment control always with the job start program and do not end it before the job's end.
What I'm wondering, what LOCK LEVEL are you using when starting commitment control?
Normally your scenario should work without any problems with Lock Level *CHG.
If you get an error on a read on a input file, I assume you are using a higher level, may be *ALL.
If it is all, you need to perform a commit before you can read a row locked under commitment control, independent from which program or activation group.
Locked is locked until a commit or rollback is performed!
Question is: Do you really need LOCK LEVEL *ALL?
Additionally it depends how you started you commitment control.
If you execute STRCMTCTL with commitment scope *ACTGRP (which is the default), commit and rollback are only performed within the same activation group.
If you execute STRCMTCTL with commitment scope *JOB, commit and rollback work independent of the activation group.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
„Train people well enough so they can leave, treat them well enough so they don't want to.“ (Richard Branson)
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Mittwoch, 6. September 2017 17:50
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Commitment control problem
Darryl,
For all of those programs mentioned, you did not state what kinds of programs they are: CLP, CLLE, RPG, RPGLE, etc., or what activation
group(s) they run in.
You could change DIR716 to run in its own named activation group, e.g.
ACTGRP(DIR716), and that should isolate it from the rest oft he job, since each activation group has its own "commitment control" scoping.
Hope that helps,
Mark S. Waterbury
On 9/6/2017 10:50 AM, a4g atl wrote:
Who can help me with this problem? This may be a question for the RPG
forum but since its commitment control I am starting here.
- INC500 starts commitments control
- Calls INR500
- Calls INR501LRA ( this program does COMMIT or ROLLBACK)
- Calls INR664
- Calls INR651
o Updates D1P710 which fires a trigger calling D1R710T
After the COMMIT, I added a call to D1C716/D1R716. This program does
not need commitment control but the job has commitment control active
Problem:
1. The process is failing as one file D1L07302 is used once in INR651
in update and in D1R716 in read mode only.
2. D1C716 is called from various places which do not use commitment
control
4. When D1R716 executes, it gets a CPF error on D1L07302. Reading up
on the issue, the error message indicates that SHARE(*NO) is required.
I added a OVRDBF with SHARE(*NO) in D1C716 at CALLLVL. This did not
resolve the issue.
An option would be to submit the call to D1C716 to batch but if
there is an easier way in the same job, that would be the preferred solution.
TIA
Darryl Freinkel
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-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
midrange.com
