Example: Using a transaction logging file to start an application
This example provides sample code and instructions of how to use a transaction logging file to start an application after an abnormal end.
By using the code examples, you agree to the terms of the Code license and disclaimer information.
A transaction logging file is used to start an application again after a system or job failure when a notify object is not used. A transaction logging file is often used in interactive applications to summarize the effects of a transaction.
For example, in an order entry application, a record is typically written to a transaction logging file for each item ordered. The record contains the item ordered, the quantity, and the price. In an accounts payable application, a record is written to a transaction logging file for each account number that is to receive a charge. This record normally contains such information as the account number, the amount charged, and the vendor.
In many of the applications where a transaction logging file already exists, a workstation user can request information about the last transaction entered. By adding commitment control to the applications in which a transaction logging file already exists, you can:
- Ensure that the database files are updated to a commitment boundary.
- Simplify the starting of the transaction again.
You must be able to uniquely identify the workstation user if you use a transaction logging file for starting applications again under commit control. If unique user profile names are used on the system, that profile name can be placed in a field in the transaction logging record. This field can be used as the key to the file.
The following examples assume that an order inventory file is being used to perform transactions and that a transaction logging file already exists. The program does the following tasks:
- Prompt the workstation user for a quantity and item number.
- Update the quantity in the production master file (PRDMSTP).
- Write a record to the transaction logging file (ISSLOGL).
If the inventory quantity on hand is insufficient, the program rejects the transaction. The workstation user can ask the program where the data entry was interrupted, because the item number, description, quantity, user name, and date are written to the transaction logging file.
DDS for physical file PRDMSTP
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7
1.00 A R PRDMSTR TEXT('Master record')
2.00 A PRODCT 3 COLHDG('Product' 'Number')
3.00 A DESCRP 20 COLHDG('Description')
4.00 A ONHAND 5 0 COLHDG('On Hand' 'Amount')
5.00 A EDTCDE(Z)
6.00 A K PRODCT
DDS for physical file ISSLOGP used by ISSLOGP
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7
1.00 A R ISSLOGR TEXT('Product log record')
2.00 A PRODCT 3 COLHDG('Product' 'Number')
3.00 A DESCRP 20 COLHDG('Description')
4.00 A QTY 3 0 COLHDG('Quantity')
5.00 A EDTCDE(Z)
6.00 A USER 10 COLHDG('User' 'Name')
7.00 A DATE 6 0 EDTCDE(Y)
8.00 A COLHDG('Date')
DDS for logical file ISSLOGL
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 1.00 A LIFO 2.00 A R ISSLOGR PFILE(ISSLOGP) 3.00 A K USER
DDS for display file PRDISSD used in the program
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 ..
1.00 A REF(ISSLOGP)
2.00 A R PROMPT 3.00 A CA03(98 'End of program')
4.00 A CA02(97 'Where am I')
5.00 A 1 20'ISSUES PROCESSING'
6.00 A 3 2'Quantity'
7.00 A QTY R I +1
8.00 A 62 ERRMSG('Not enough +
9.00 A Qty' 62)
10.00 A +6'Product'
11.00 A PRODCT R I +1
12.00 A 61 ERRMSG('No Product +
13.00 A record found' 62)
14.00 A 55 15 2'No Previous record exists'
15.00 A 24 2'CF2 Last transaction'
16.00 A R RESTART 17.00 A 1 20'LAST TRANSACTION +
18.00 A INFORMATION'
19.00 A 5 2'Product'
20.00 A PRODCT R +1
21.00 A 7 2'Description'
22.00 A DESCRP R +1
23.00 A 9 2'Qty'
24.00 A QTY R +1REFFLD(QTY)
This process is outlined in the Program flow.
Program flow
The RPG COMMIT operation code is specified after the PRDMSTP file is updated and the record is written to the transaction logging file. Because each prompt to the operator represents a boundary for a new transaction, the transaction is considered a single Enter transaction.
The user name is passed to the program when it is called. The access path for the transaction logging file is defined in last-in-first-out (LIFO) sequence so the program can easily access the last record entered.
The workstation user can start the program again after a system or job failure by using the same function that identified where data entry was stopped. No additional code needs to be added to the program. If you are currently using a transaction logging file but are not using it to find out where you are, add the user name to the transaction logging file (assuming that user names are unique) and use this approach in the program.
The following example shows the RPG program used. Statements required for commitment control are marked with arrows (==>).
RPG Program
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... .. 7 .. =>1.00 FPRDMSTP UP E K DISK KCOMIT =>2.00 FISSLOGL IF E K DISK KCOMIT 3.00 PRDISSD CP E WORKSTN 4.00 *ENTRY PLIST 5.00 PARM USER 10 6.00 C* 7.00 C* Initialize fields used in Trans Log Rcd 8.00 C* 9.00 C MOVE UDATE DATE 10.00 C* 11.00 C* Basic processing loop 12.00 C* 13.00 C LOOP TAG 14.00 C EXFMTPROMPT 15.00 C 98 GOTO END End of pgm 16.00 C 97 DO Where am I 17.00 C EXSR WHERE 18.00 C GOTO LOOP 19.00 C END 20.00 C PRODCT CHAINPRDMSTR 61 Not found 21.00 C 61 GOTO LOOP 22.00 C ONHAND SUB QTY TEST 50 62 Less than 23.00 C 62 DO Not enough 24.00 C EXCPTRLSMST Release lock 25.00 C GOTO LOOP 26.00 C END 27.00 C* 28.00 C* Update master record and output the Transaction Log Record 29.00 C* 30.00 C Z-ADDTEST ONHAND 31.00 C UPDATPRDMSTR 32.00 C WRITEISSLOGR =>33.00 C COMIT 34.00 C GOTO LOOP 35.00 C* 36.00 C* End of program processing 37.00 C* 38.00 C END TAG 39.00 C SETON LR 40.00 C* 41.00 C* WHERE subroutine for "Where am I" requests 42.00 C* 43.00 C WHERE BEGSR 44.00 C USER CHAINISSLOGL 55 Not found 45.00 C N55 EXFMTRESTART 46.00 C ENDSR 47.00 OPRDMSTR E RLSMST
CL program used to call RPG program PRDISS
SEQNBR *... ... 1 ... ... 2 ... ... 3 ... ... 4 ... ... 5 ... ... 6 ... ... 7 .. 1.00 PGM 2.00 DCL &USER *CHAR LEN(10) 3.00 STRCMTCTL LCKLVL(*CHG) 4.00 RTVJOBA USER(&USER) 5.00 CALL PRDISS PARM(&USER) 6.00 MONMSG MSGID(RPG900l) EXEC(ROLLBACK) 7.00 ENDCMTCTL 8.00 ENDPGM
To use commitment control in this program, a lock level of *CHG is normally specified. The record is locked by the change until a commit operation is run. Note that if there is an insufficient quantity of inventory, the record is explicitly released. (If the record are not explicitly released in the program, it is released when the next record is read for update from the file.)
In this example, there is no additional advantage to using the lock level *ALL. If *ALL is used, a rollback or commit operation must be used to release the record when an insufficient quantity existed.
The previous code is a CL program that calls the RPG program PRDISS. Note the use of STRCMTCTL/ENDCMTCTL commands. The unique user name is retrieved (RTVJOBA command) and passed to the program. The use of the MONMSG command to cause a rollback is described in Example: Use a standard processing program to start an application.
Parent topic:
Scenarios and examples: Commitment control
Related concepts
Example: Using a standard processing program to start an application
Example: Unique notify object for each program