DB2 Index Hell - 140 Million rows

Hi, I have spent all day coming up with an index strategy to this problem. We have a table of about 140 million rows - each row has a CREATE_TS and STATUS. The STATUS is NULL initially but it will change as we process records. There are about 4 different statuses.

I want to be able to get to documents based on timestamp and status. Here are the 4 scenarios. All queries are run with OPTIMIZE FOR 1000 ROWS
1. WHERE STATUS IS NULL ORDER BY CREATED_TS ASC
2. WHERE STATUS IS NULL AND CREATED_TS > timestamp(...) ORDER BY CREATED_TS ASC
3. WHERE STATUS = 'XXX' AND CREATED_TS < timestamp(...) ORDER BY CREATED_TS ASC
4. WHERE STATUS = 'XXX' AND CREATED_TS < timestamp(...) AND CREATED_TS > timestamp(...) ORDER BY CREATED_TS ASC


Attempt 1: Composite Index (STATUS, CREATED_TS)
DB2 refused to use this index atleast initially (maybe because STATUS column has low cardinality?)

Attempt 2: Composite Index (CREATED_TS, STATUS)
This index is being user by all queries - Query 1 performs well, Query 3 performs very slow even though there are no rows returned. Is this because it is sorting by CREATED_TS and then scanning all the rows until it found the records with a particular STATUS? I feel like this can get worse once the statuses change and we are looking for a particular STATUS.

Attempt 3: Two separate indexes one on STATUS and one on CREATED_TS
Surprisingly, Query 1 took forever to return.

Any suggestions appreciated.
Thanks