There's two view points on this:
One: I just want to convert my DDS to DDL.
Two: I am willing to go the next level to get the best performance.
Here's the difference, IBM created those where clauses on indexes for the
sole purpose of converting DDS to DDL, so, from that perspective, it's
"kosher".
However, a true DBA might balk on that. Before I tell you why, let's
start out with a little example. Let's say your table has three columns:
ActiveRecordCode, CustomerNumber, CustomerName. Your existing DDS logical
file has a key by item number and a record selection for only active
records. Now, you come along with this sql statement:
select * from myTable
where ActiveRecordCode='1'
order by CustomerNumber
It could not use this logical, created via DDS or DDL, as a search index
because it has no key by ActiveRecordCode.
If, however, you created your new index by adding a key to be
ActiveRecordCode and CustomerNumber, then it could. The rub is that all
existing RPG, using RLA, that was hoping you just did a simple DDS to DDL
conversion will now blow because it assumes you only selected active
records and therefore have no need for a key on ActiveRecordCode. Summary,
key fields between logical file and rpg program don't match.
So, are you really ready to convert all your logic to take advantage of an
index that has both the ActiveRecordCode and the CustomerNumber, or do you
just want to simply convert your DDS to DDL?
Think of an old Dilbert cartoon where Dogbert slays the database guru with
"Look! Actual code!".
http://search.dilbert.com/search?w=%22actual+code%22&x=0&y=0
Rob Berendt
midrange.com
