Well, to be devils advocate you'd better be prepared to counter this
argument:
IBM added numerous functions to indexes in order for them to be able to
replace the 'simple' DDS logical files most commonly found.
For example, let's say you have a PF named IIM. On that IIM file you have
a select/omit logical called IIML01. That selects rows that have an 'IM'
in the IACT column. And it puts a key by item number. And it has a
record format of IIML01R. This can all be done with sql now since they've
added RCDFMT and other functions to an index. Then you can read that
index in RPG RLA or by SQL.
In this case I would strongly recommend that RPG read the indexes. Why?
Because I have added columns to the underlying table and since the
existing indexes only select certain columns and not a 'SELECT *' the
underlying RPG doesn't get record format level check errors.
But in your favor:
CREATE TABLE ROB.ROBM (MYCHAR CHAR (5 ) NOT NULL WITH DEFAULT)
Table ROBM in ROB created but was not journaled.
CREATE INDEX ROB.robmindex ON ROB.ROBM (MYCHAR)
Index ROBMINDEX created in ROB on table ROBM in ROB.
select * from rob.robmindex
ROBMINDEX in ROB not table, view, or physical file.
Message ID . . . . . . : SQL7011 Severity . . . . . . . : 30
Message type . . . . . : Diagnostic
Message . . . . : ROBMINDEX in ROB not table, view, or physical file.
Cause . . . . . : The SQL statement *N cannot be performed on a file
which
is not a table, view, single format logical file, or physical file.
Recovery . . . : Do one of the following:
-- Use a control language (CL) command to do the function.
-- Select the correct table, view, logical, or physical file.
Rob Berendt
midrange.com
