Re: *USRIDX -- MIDRANGE-L

Ken,

Below is what the V5R3 API Concepts book says about user indexes.

My interpretation is that problems are likely to occur following an abnormal system end, but not following a normal system end.

"User index considerations

The performance of a user index is much better than that of a database file. However, before using a user index, you must know the functional differences between a user index and a database file.

The contents of a database file are not affected by an abnormal system end. On the other hand, the contents of a user index may become totally unusable if the system ends abnormally. Therefore, you should not use a user index if the information you want to store needs to remain without errors after an abnormal system end.

If your system abnormally ends when you are removing or inserting a user index entry, unpredictable results may occur. If you are inserting or removing a user index entry and you should force the index entry to the disk unit using one of the following:

- A user index created with the immediate update parameter set to 1 (affects performance) - A modify index (MODIDX) MI instruction with the immediate update bit set to 1 - The set access state (SETACST) MI instruction

If you do not force the index entry and the system abnormally ends, your index will probably be damaged.

To determine if your last system power down was normal or abnormal, you can check the system value QABNORMSW.

You will not get an error message if your index is damaged. The definition of your index is usable; it is probably the data in your index that is bad.

You can log changes to a database file in a journal, and you can use the journal to apply or remove those changes later. You can also use the journal to audit who is using the database file. However, the system does not support the journaling of indexes. As a result, user applications should log entries in a journal to keep track of changes to the index, but you cannot update the index using apply and remove journal entry functions. For more information on journaling, see the Journal and Commit APIs.

Indexes support the storage of data that does not need to remain after an abnormal system end. If an abnormal system end does occur, you must use a backup copy of the index that was previously saved or create a new copy of the index."

Mel Rothman
Mel Rothman, Inc.

Graap, Ken wrote:

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
**************************************** Kenneth E. Graap IBM Certified Specialist AS/400e Professional System Administrator NW Natural (Gas Services) keg@xxxxxxxxxxxxx Phone: 503-226-4211 x5537 FAX: 603-849-0591 ****************************************
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.