title: CURRENT_TIMESTAMP not always populating
body: <p>This is DB2 for i running at release 7.3.</p>
  
  <p>I'm currently evaluating what we need to do to convert our DDS-defined physical and logical files to DDL-defined tables and views. As part of my testing I've come across an unusual finding. Given a table with a column defined as a <code>TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP</code>, sometimes that value populates correctly when new rows are written from an RPGLE program - but most of the time it does not. SQL <code>INSERT</code>s seem to consistently work fine.</p>
  
  <p>Here's the source:</p>
  
  <p>QDDLSRC/SOT</p>
  
  <pre><code>CREATE OR REPLACE TABLE SOT (                                               
    ID   BIGINT        GENERATED ALWAYS AS IDENTITY (START WITH 1),           
    DESC CHAR(20)      NOT NULL DEFAULT '',                                   
    CTS  TIMESTAMP     NOT NULL DEFAULT CURRENT_TIMESTAMP,                    
    UTS  TIMESTAMP     NOT NULL FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP,
    PRIMARY KEY(ID)                                                            
  ) RCDFMT SOTR;                                                              
  </code></pre>
  
  <p>And to compile it:</p>
  
  <pre><code>RUNSQLSTM SRCFILE(MYLIB/QDDLSRC) SRCMBR(SOT) DFTRDBCOL(MYLIB)
  </code></pre>
  
  <p>Here's the source for a plain old RPGLE program that does a <code>WRITE</code>:</p>
  
  <p>QRPGLESRC/SOT1 (Plain old RPGLE code)</p>
  
  <pre><code>  CTL-OPT Optimize(*full);
    CTL-OPT Option(*nodebugio : *noshowcpy : *nounref : *srcstmt);
    CTL-OPT Dftactgrp(*no) Actgrp('QILE');
    CTL-OPT Bnddir('QC2LE');
    CTL-OPT Alwnull(*USRCTL);
  //-----------------------------
    DCL-F sot disk(*ext) usage(*input : *output : *update) keyed;
  //-----------------------------
    DCL-PR sot1 EXTPGM;
    END-PR sot1;
  
    DCL-PI sot1;
    END-PI;
  //-----------------------------
    *INLR = *ON;
  
    desc = 'RPGLE I 1';
    WRITE sotr;
  
    CHAIN (1) sot;
    IF %FOUND(sot);
      desc = 'RPGLE U 1';
      UPDATE sotr;
    ENDIF;
  
    desc = 'RPGLE I 2';
    WRITE sotr;
  //-----------------------------
  </code></pre>
  
  <p>And here's the source for an SQLRPGLE program that does an INSERT - this seems to work just fine.</p>
  
  <p>QRPGLESRC/SOT2 (SQLRPGLE code)</p>
  
  <pre><code>  CTL-OPT Optimize(*full);
    CTL-OPT Option(*nodebugio : *noshowcpy : *nounref : *srcstmt);
    CTL-OPT Dftactgrp(*no) Actgrp('QILE');
    CTL-OPT Alwnull(*USRCTL);
  //-----------------------------
    DCL-PR sot2 EXTPGM;
    END-PR sot2;
  
    DCL-PI sot2;
    END-PI;
  //-----------------------------
    EXEC SQL
      INSERT INTO sot (desc)
      VALUES('SQLRPGLE I 1');
  
    EXEC SQL
      INSERT INTO sot (desc)
      VALUES('SQLRPGLE I 2');
  
    EXEC SQL
      UPDATE sot
      SET desc = 'SQLRPGLE U 1'
      WHERE id=5;
  
    *INLR = *ON;
  //-----------------------------
  </code></pre>
  
  <p>And finally, here's how I'm testing. First I <code>INSERT</code> a couple of records via <code>STRSQL</code>:</p>
  
  <pre><code>INSERT INTO sot        
  (desc) VALUES('SQL I 1')
  
  INSERT INTO sot        
  (desc) VALUES('SQL I 2')
  </code></pre>
  
  <p>Then execute SOT1 (the plain old RPGLE program):  <code>CALL SOT1</code></p>
  
  <p>Then execute SOT2 (the SQLRPGLE program):  <code>CALL SOT2</code></p>
  
  <p>Then view results (this is from WRKQRY):</p>
  
  <pre><code>Line   ....+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8....+....9....+...10..
  
                              ID   DESC                  CTS                         UTS                      
  
  000001                       1   RPGLE U 1             2018-04-18-16.05.13.520198  2018-04-18-16.05.26.275153
  
  000002                       2   SQL I 2               2018-04-18-16.05.19.670653  2018-04-18-16.05.19.670653
  
  000003                       3   RPGLE I 1             0001-01-01-00.00.00.000000  2018-04-18-16.05.26.274977
  
  000004                       4   RPGLE I 2             2018-04-18-16.05.13.520198  2018-04-18-16.05.26.275196
  
  000005                       5   SQLRPGLE U 1          2018-04-18-16.05.29.244307  2018-04-18-16.05.29.253463
  
  000006                       6   SQLRPGLE I 2          2018-04-18-16.05.29.248723  2018-04-18-16.05.29.248723
  
  ****** ********  End of report  ********
  </code></pre>
  
  <p>Notice that row 3 has an incorrect timestamp value in column <code>CTS</code>. Yet row 4 has the expected timestamp value in <code>CTS</code>.</p>
  
  <p>Any ideas on why this is happening inconsistently?</p>