Software/Hardware used:
as400
I am calling this pgm from command prompt...
You might run a STRCMTCTL LCKLVL(*CHG) command before calling your program. After the program ends, run a COMMIT or a ROLLBACK command depending on whether the program ended properly or failed. And finally, run ENDCMTCTL to stop commitment control.
You might create a basic CL program to wrap the new commands around a CALL to your program.
You might also recreate your program with parameters that specify commitment control or SET OPTIONS for commitment control in the embedded SQL.
You can handle commitment control outside your program or have it be built into it. It could depend on what the overall commitment control environment is on your system.
Note that commitment control requires journaled files. I haven't tried it, but you might use the STRCMTCTL DFTJRN() parameter to assign a journal temporarily.
Tom
There are a few possible choices depending on the structure of the job. Starting point might be a description of any existing commitment control.
Is commitment control already in use in this system? Is it active when this program is called?
Next, how is this program called?
What calls this program? Is it called by some program or module that you can change? And is this a *PGM or is it a *MODULE or *SRVPGM?
Finally, how was this program compiled?
What was used for the COMMIT() parameter on the compile command? If you run DSPPGM against this program and take option 5=’Display’ against the module, what shows for ‘Commitment control’ in the “DB2 UDB for i5/OS module attributes:” section?
Tom
Tom, I am calling this pgm from command prompt and this is *PGM object .Commitment control is *none
If you want to “isolate” these statements as a transaction, you could test this
specify a commitment level on the compilation command
specify a different activation group for the program
add rollback/commit statements