Why would it not be used?

By using a journal, commitment control avoids a requirement to apply updates physically to files until after the instant of commitment is reached. All related uncommitted I/O is done in contiguous entries in the receivers making for good efficiency. Physical table I/O can be handled totally by DB2 after that. SLIC routines can make updates faster than system calls.

Here is some code to play with to see what commitment control can do. (Taken from Vern Hamberg’s test in the midrange.com archives. Modified for more general usage, more specific example, etc.) This creates some test files:

DROP TABLE mylib.filecmt RESTRICT;
CREATE TABLE mylib.filecmt ( field1 INTEGER NOT NULL
                                    CONSTRAINT constraint1 PRIMARY KEY,
                             field2 INTEGER NOT NULL);
DROP TABLE mylib.filejrn RESTRICT;
CREATE TABLE mylib.filejrn ( field1 INTEGER NOT NULL
                                    CONSTRAINT constraint2 PRIMARY KEY,
                             field2 INTEGER NOT NULL);
DROP TABLE mylib.filenone RESTRICT;
CREATE TABLE mylib.filenone ( field1 INTEGER NOT NULL
                                     CONSTRAINT constraint3 PRIMARY KEY,
                              field2 INTEGER NOT NULL);

Create a default QSQJRN journal in mylib before creating the tables. After running the SQL, run ENDJRNPF for the FILENONE table so that two tables are journaled and one is not.

This is basic CL to control the test run:

pgm

   clrpfm    filecmt
   clrpfm    filejrn
   clrpfm    filenone

   strcmtctl lcklvl(*all) cmtscope(*job)
   call      TSTJRNCMT
   endcmtctl

endpgm

The ILE RPG to run the three updates:

     ffilecmt   if a e           k disk    commit prefix(C)
     f                                     rename( filecmt : FILECMTR )
     ffilejrn   if a e           k disk    prefix(J)
     f                                     rename( filejrn : FILEJRNR )
     ffilenone  if a e           k disk    prefix(N)
     f                                     rename( filenone : FILENONER )

     d i               s             10i 0
     d j               s             10i 0
     d k               s             10i 0 inz
     d sTimestamp      s               z
     d eTimestamp      s               z
     d duration        s             15p 6

     dTSTJRNCMT        pr

     dTSTJRNCMT        pi
      /free
       sTimestamp = %timestamp();

       for i = 1 to 100;
          for j = 1 to 1000;
             k += 1;
             cfield1 = k;
             cfield2 = k;
             write filecmtr;
          endfor;
          commit;
       endfor;

       eTimestamp = %timestamp();
       duration = %diff(eTimestamp : sTimestamp : *mseconds) / 1000000;
       dsply ('Commit type: ' + %char(duration) + ' seconds');

       sTimestamp = %timestamp();

       for i = 1 to 100000;
          jfield1 = i;
          jfield2 = i;
          write filejrnr;
       endfor;

       eTimestamp = %timestamp();
       duration = %diff(eTimestamp : sTimestamp : *mseconds) / 1000000;
       dsply ('Journal type: ' + %char(duration) + ' seconds');

       sTimestamp = %timestamp();

       for i = 1 to 100000;
          nfield1 = i;
          nfield2 = i;
          write filenoner;
       endfor;

       eTimestamp = %timestamp();
       duration = %diff(eTimestamp : sTimestamp : *mseconds) / 1000000;
       dsply ('Neither type: ' + %char(duration) + ' seconds');

       *inlr = *on;
      /end-free

The RPG inserts 100000 records into each of the three tables. FILECMT is updated under commitment control, FILEJRN is simply journaled and FILENONE is simply updated.

I ran three tests. Nothing special was done to alter performance — no journal caching, no receivers in a multi-arm dedicated user ASP, etc. The delays that force journal writes synchronously under basic journaling are obvious.

Results:

• DSPLY Commit type: 115.240000 seconds
• DSPLY Journal type: 750.756000 seconds
• DSPLY Neither type: 61.373000 seconds
• DSPLY Commit type: 117.267000 seconds
• DSPLY Journal type: 750.333000 seconds
• DSPLY Neither type: 59.932000 seconds
• DSPLY Commit type: 107.282000 seconds
• DSPLY Journal type: 745.358000 seconds
• DSPLY Neither type: 58.359000 seconds

Performance tuning for journaling could bring the first two types down a bit, but the clear differences won’t disappear. If journaling is important and performance is important, then commitment control becomes more important.

Tom

I guess there won’t be any solution for this now…not until we get V6R1. Anyway, thanks Tom and Philip for your time…

Allan

Your plan is very complicated and complicated systems tend to have higher failure rates.

I agree – I don’t know if this 24×7 concept is prevalent nowadays. What and how much benefit is it to a company? It is indeed a very complicated plan and I am already expecting high failure rates. Or maybe I’m just not that knowledgeable…

Yes, Journaling will take a little more resources. Make sure that the receivers get rolled.

Your plan is very complicated and complicated systems tend to have higher failure rates.
I wish I could propose an alternative. Are you running mirrored systems?
Phil

Journaling can improve performance in a commitment-control environment.

It gets kind of tricky when access paths are also being journaled. For example, if SQL is supplanting DDS, one issue is that the SQL page sizes are much bigger. That can make a big difference in how many bytes get transferred into a journal receiver.

Lots of factors can contribute.

If IBM improved the ENDJRNPF in V6R1, then they should also have a PTF for V5R4, right?

Maybe. It happens. I wouldn’t expect it for this function, but a number of preparatory PTFs related to journaling were released last week. Those didn’t have a descriptions other than “Incremental enhancement” or “Enablement for Future Enhancement”.

I’ve never checked, but it feels like many of these PTFs back to previous releases come at version boundaries. With i6.1 being followed by 7.1, this is a little unusual. Maybe IBM will PTF this backwards.

AFAIK, the more customers ask for it, the greater the chance of it happening. It obviously depends on whether or not it’s even possible without the i6.1 LIC disk functions.

Tom

I mean allocate with exclusive locks (*EXCL)…