This section describes how to use commitment control to process file operations as a group. With commitment control, you ensure one of two outcomes for the file operations:
In this way, you process a group of operations as a unit.
To use commitment control, you do the following:
Note: Commitment control applies only to database files.
Starting and Ending Commitment Control
The CL command STRCMTCTL notifies the system that you want to start commitment control.
The LCKLVL(Lock Level) parameter allows you to select the level at which records are locked under commitment control. See “Commitment Control Locks” and the CL Programming manual for further details on lock levels.
You can make commitment control conditional, in the sense that the decision whether to process a file under commitment control is made at run time. For further information, see “Specifying Conditional Commitment Control”.
When you complete a group of changes with a COMMIT operation, you can specify a label to identify the end of the group. In the event of an abnormal job end, this identification label is written to a file, message queue, or data area so that you know which group of changes is the last group to be completed successfully. You specify this file, message queue, or data area on the STRCMTCTL command.
Before you call any program that processes files specified for commitment control, issue the STRCMTCTL command. If you call a program that opens a file specified for commitment control before you issue the STRCMTCTL command, the opening of the file will fail.
The CL command ENDCMTCTL notifies the system that your activation group or job has finished processing files under commitment control.
Commitment Control Locks
On the STRCMTCTL command, you specify a level of locking, either LCKLVL(*ALL), LCKLVL(*CHG), or LCKLVL(*CS). When your program is operating under commitment control and has processed an input or output operation on a record in a file under commitment control, the record is locked by commitment control as follows:
The COMMIT and ROLBK operations release the locks on the records. The UNLOCK operation will not release records locked using commitment control.
The number of entries that can be locked under commitment control before the COMMIT or ROLBK operations are required may be limited. For more information, see the Backup and Recovery manual.
Note: The SETLL and SETGT operations will lock a record in the same cases where a read operation (not for update) would lock a record for commitment control.
Commitment Control Scoping
When commitment control is started by using the STRCMTCTL command, the system creates a commitment definition. A commitment definition contains information pertaining to the resources being changed under commitment control within that job. Each commitment definition is known only to the job that issued the STRCMTCTL command and is ended when you issue the ENDCMTCTL command.
The scope for commitment definition indicates which programs within the job use that commitment definition. A commitment definition can be scoped at the activation group level or at the job level.
The default scope for a commitment definition is to the activation group of the program issuing the STRCMTCTL command, that is, at the activation group level. Only programs that run within that activation group will use that commitment definition. OPM programs will use the *DFTACTGRP commitment definition. ILE programs will use the activation group they are associated with.
You specify the scope for a commitment definition on the commitment scope (CMTSCOPE) parameter of the STRCMTCTL command.
Specifying Files for Commitment Control
To indicate that a DISK file is to run under commitment control, enter the keyword COMMIT in the keyword field of the file description specification.
When a program specifies commitment control for a file, the specification applies only to the input and output operations made by this program for this file. Commitment control does not apply to operations other than input and output operations. It does not apply to files that do not have commitment control specified in the program doing the input or output operation.
When more than one program accesses a file as a shared file, all or none of the programs must specify the file to be under commitment control.
Using the COMMIT Operation
The COMMIT operation tells the system that you have completed a group of changes to the files under commitment control. The ROLBK operation eliminates the current group of changes to the files under commitment control. For information on how to specify these operation codes and what each operation does, see the WebSphere Development Studio: ILE RPG Reference.
If the system fails, it implicitly issues a ROLBK operation. You can check the identity of the last successfully completed group of changes using the label you specify in factor 1 of the COMMIT operation code, and the notify-object you specify on the STRCMTCTL command.
At the end of an activation group or job, or when you issue the ENDCMTCTL command, the OS/400 system issues an implicit ROLBK, which eliminates any changes since the last ROLBK or COMMIT operation that you issued. To ensure that all your file operations have effect, issue a COMMIT operation before ending an activation group or job operating under commitment control.
The OPEN operation permits input and output operations to be made to a file and the CLOSE operation stops input and output operations from being made to a file. However, the OPEN and CLOSE operations do not affect the COMMIT and ROLBK operations. A COMMIT or ROLBK operation affects a file, even after the file has been closed. For example, your program may include the following steps:
The changes made at step 3 are rolled back by the ROLBK operation at step 5, even though the file has been closed at step 4. The ROLBK operation could be issued from another program in the same activation group or job.
A program does not have to operate all its files under commitment control, and to do so may adversely affect performance. The COMMIT and ROLBK operations have no effect on files that are not under commitment control.
Note: When multiple devices are attached to an application program, and commitment control is in effect for the files this program uses, the COMMIT or ROLBK operations continue to work on a file basis and not by device. The database may be updated with partially completed COMMIT blocks or changes that other users have completed may be eliminated. It is your responsibility to ensure this does not happen.
Example of Using Commitment Control
This example illustrates the specifications and CL commands required for a program to operate under commitment control.
To prepare for using commitment control, you issue the following CL commands:
In your program, you specify COMMIT for the file MASTER and the file TRANS:
Example of Using Commitment Control
To operate your program (named REVISE) under commitment control, you issue the commands:
Specifying Conditional Commitment Control
You can write a program so that the decision to open a file under commitment control is made at run time. By implementing conditional commitment control, you can avoid writing and maintaining two versions of the same program: one which operates under commitment control, and one which does not.
The COMMIT keyword has an optional parameter which allows you to specify conditional commitment control. You enter the COMMIT keyword in the keyword section of the file description specifications for the file(s) in question. The ILE RPG compiler implicitly defines a one-byte character field with the same name as the one specified as the parameter. If the parameter is set to ’1’, the file will run under commitment control.
The COMMIT keyword parameter must be set prior to opening the file. You can set the parameter by passing in a value when you call the program or by explicitly setting it to ’1’ in the program.
For shared opens, if the file in question is already open, the COMMIT keyword parameter has no effect, even if it is set to ’1’.
This is an example showing conditional commitment control.
Example of Using Conditional Commitment Control
Commitment Control in the Program Cycle
Commitment control is intended for full procedural files, where the input and output is under your control. Do not use commitment control with primary and secondary files, where input and output is under the control of the RPG program cycle. The following are some of the reasons for this recommendation:
IBM - RPG Related Interview Questions
|IBM-ILE Interview Questions||IBM Informix Interview Questions|
|IBM DB2 Interview Questions||SQL Database Interview Questions|
|IBM AIX Interview Questions||SQL Interview Questions|
|AS400 Interview Questions||DB2 SQL Programming Interview Questions|
|IBM Integration Bus Interview Questions||Synopsys Interview Questions|
|Rpgle Interview Questions|
Ibm - Rpg Tutorial
Overview Of The Rpg Iv Programming Language
Rpg Programming In Ile
Program Creation Strategies
Creating An Application Using Multiple Procedures
Using Source Files
Creating A Program With The Crtbndrpg Command
Creating A Program With The Crtrpgmod And Crtpgm
Creating A Service Program
Running A Program
Calling Programs And Procedures
Rpg And The Ebusiness World
Obtaining A Dump
General File Considerations
Accessing Database Files
Accessing Externally Attached Devices
Using Workstn Files
Example Of An Interactive Application
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.