<p>It's my understanding that nulls are not indexable in DB2, so assuming we have a huge table (Sales) with a date column (sold_on) which is normally a date, but is occasionally (10% of the time) null.</p>

<p>Furthermore, let's assume that it's a legacy application that we can't change, so those nulls are staying there and mean something (let's say sales that were returned).</p>

<p>We can make the following query fast by putting an index on the sold_on and total columns</p>

<pre><code>Select * from Sales 
where 
Sales.sold_on between date1 and date2
and Sales.total = 9.99
</code></pre>

<p>But an index won't make this query any faster:</p>

<pre><code>Select * from Sales 
where 
Sales.sold_on is null
and Sales.total = 9.99
</code></pre>

<p>Because the indexing is done on the value.</p>

<p>Can I index nulls?  Maybe by changing the index type?  Indexing the indicator column?</p>

I'm no DB2 expert, but if 10% of your values are null, I don't think an index on that column alone will ever help your query.  10% is too many to bother using an index for -- it'll just do a table scan.  If you were talking about 2-3%, I think it would actually use your index.
Think about how many records are on a page/block -- say 20.  The reason to use an index is to avoid fetching pages you don't need.  The odds that a given page will contain 0 records that are null is (90%)^20, or 12%.  Those aren't good odds -- you're going to need 88% of your pages to be fetched anyway, using the index isn't very helpful.
If, however, your select clause only included a few columns (and not *) -- say just salesid, you could probably get it to use an index on (sold_on,salesid), as the read of the data page wouldn't be needed -- all the data would be in the index.