However, the SQL standard prevents indexes from being referenced on an SQL query. So it would be better to move this derivation to an SQL view and then write your queries against the SQL view. Here's an example SQL view and a sample SELECT statement demonstrating how to query the view.
Create Index mydate_ix on pf1 (date( case when substr(digits(jdatcol),1,2) > '39' then '19' else '20' end concat digits(jdatcol)) )
Another alternative would be changing your physical file definition to change the Julian date column to a real date column. Then, you could create a LF that maps the date column back to it's original form. Existing applications could be changed to use the logical file and not have to be modified to support the date data type. All of your queries would then just reference the date field in the physical file.
Create View myview as (select col1, date( case when substr(digits(jdatcol),1,2) > '39' then '19' else '20' end concat digits(jdatcol)) as datcol, col3 from pf1) SELECT col1 FROM myview where jdatcol >= CURRENT DATE
This was first published in January 2009