Since all indexes with idxnum > the 'index-num' referenced didn't get checked, the operation will need to be re-run. This is the 'downside' of online utilities, balancing accurate information against time, options are:
1. Add
-NL to IDXCHECK, if any errors are reported, then re-run an offline IDXCHECK against a copy of the online database or more specifically, a limited IDXCHECK (iow: for that specific table.index where the error is raised).
2. Use the "
L (lock tables during check)" IDXCHECK Option, which will cause the check to wait on any other process locking a record or the schema on a given table and take longer to run online as a consequence.
3. Add the
-lkwtmo parameter to IDXCHECK to specify how long you're prepared to wait for a lock, the default is 30 minutes (1800 seconds). While the default of 30 minutes should be more than long enough if not too long, setting it any longer could retard the whole operation. This could highlight an underlying application locking problem, where the question "why was some process locking a record for so long in the first place anyway?" needs to be answered.
For further details of the online IDXCHECK locking protocols, refer to Article:
What are the implications of the online IDXCHECK locking options? 
