RE: *USRIDX PMR 12409,550 -- MIDRANGE-L

This is all very interesting ... The IBM Support Line Technical Document,
Document Number: 18653736 seems to be taking the stability issue of a *USIDX
a little further than is necessary. It looks like the only time you really
need to worry is when the system experiences an "abnormal end", not a
"normal IPL"....

Kenneth 

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Mel Rothman
Sent: Tuesday, August 24, 2004 11:20 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: *USRIDX


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.
> 
> 


--
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.