RE: *USRIDX

["Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Looks like problem only applies in case of abnormal termination and can
probably be avoided to a degree by ensuring certain parameters are set
correctly (i.e. force write to disk on each new entry/update).

Here are couple of links worth reading.

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/info/apis/conIn
dexCons.htm

http://www-912.ibm.com/a_dir/as4ptf.nsf/b1cd508fa850028686256c2300702726/90b
4f66e89ce86c686256cd1004ce8db?OpenDocument&Highlight=0,User,index

In your case, there is still another question.  Let's say you do establish a
pre-IPL routine to save this index before the IPL and then restore it after
the IPL.  What if there is an abnormal termination and your pre-IPL routine
doesn't get a chance to execute?  You're stuck with "old" save of the object
which may or may not be up to date.
This behavior may be OK for non-critical data, but I'd prefer DB file with
unique key for critical data.

Hope that helps.

Elvis

-----Original Message-----
Subject: *USRIDX

I've been told that there is no guarantee that an OS/400 *USRIDX object can
"survive" a system IPL without being damaged in some way? Is anyone else
aware of this limitation? I find it hard to believe that a permanent OS/400
object can't survive an IPL!

IBM Support Line Technical Document 
Document Number: 18653736 
____________________________________________________________ 

Functional Area: Host Servers 
Subfunctional Area: Database Server 
Sub-Subfunctional Area: General 

...... <a bunch of stuff deleted....

How it All Works 

Though the configuration itself is done through Operations Navigator, the
routing information is stored in a user index on the AS/400e or iSeries 400
server, QUSRSYS/QYSMSVRE. Unfortunately, this is not a very stable object
and it is not guaranteed that it will make it through an IPL undamaged. For
this reason, it is recommended that you save this object and restore it
during each IPL in order to guarantee its continued functionality. 

Kenneth