Think of the result of the outer join as a temporary table. You have some rows in the temp table where A and B had matching INTKEY, and the temp table has column data from both. You may also have rows in the temp table where INTKEY didn't exist in B, so the temp table has all NULLs for the B columns.

Next you apply the WHERE condition to the result, i.e., to the temporary table. For the non-matching records, the B columns are all NULL, so the date test fails.

Instead of testing the date it in the WHERE clause, try putting it in the join conditions:

insert into OUTFILE
    select A.FLD1, A.FLD2, A.FLD3, B.FLD4
    from FILEA A
    left outer join FILE B
      on (A.INTKEY = B.INTKEY AND B.FLD5 between :StartDate and :EndDate)
    where exists(select 1 from CTLFILE C where  A.FLD1 = C.FLD1)

You could also rewrite it using a CTE, which might make it more obvious what is happening:

insert into OUTFILE
    with B as (select INTKEY, FLD4 from FILEB
                 where FLD5 between :StartDate and :EndDate)
    select A.FLD1, A.FLD2, A.FLD3, B.FLD4
    from   FILEA A
    left outer join
           B on (A.INTKEY = B.INTKEY)
    where exists(select 1
                 from   CTLFILE C
                 where  A.FLD1 = C.FLD1)

And, as always, I'd try running the SELECT separately, to make sure you're getting the expected rows, before turning it into an INSERT statement.

Yup - I always run interactive SQL (obviously replacing the substitution variables with literals), until I get the result I'm expecting, and then drop it into embedded SQL (occassionally forgetting to replace the literals with replacement variables - and then wondering why it always does the same thing regardless of program call parameters!!).

Well thanks, that appears to have gotten the desired result.