Re: managing user indexes (*USRIDX)

Rick, as Chuck points out, you must be talking about data queues - maybe keyed ones. You do mention data queues in your reply.

The commands for user indexes do not have a wait time, either, as data queues do. So it seems user indexes are not to be used for the same kind of processing, where you are waiting on the arrival of a certain set of data before going on.

Just some idle thoughts!

Vern

On 1/8/2013 10:24 AM, Rick.Chevalier@xxxxxxxxxxxxxxx wrote:

Grace,

Multiple programs can access a user index at the same time. The key is how they access it. You can do a 'destructive' read which removes the entries when they are read or you can simply read the entries. Obviously, if entries are removed when read they won't be available for other programs to access.

I don't see why you would want to create unique indexes for each instance (person) of your data. As was previously mentioned, that is going to add a lot of complexity and object manipulation that may unnecessarily negate the performance gain. Why not make each person an entry in the index? The data portion is the same as a record, just place the data elements for each instance into a separate index entry with a unique key. Then just access the instance by the key much like you would with a data file. When reading the index entries use a data structure as the receiver variable. Make it an array DS if you have multiple entries.

As an example, we have an application that does image indexing for us. It reads a list of images to be indexed together as a group from an XML file. It assigns a unique identifier to the group, writes each individual image file name into a user index with the identifier as the key, and places an entry onto a data queue with the identifier and number of images. We then have multiple programs reading from the data queue and retrieving the image file names from the user index associated with the identifier read from the queue. It works well and is very fast. The read is destructive as we don't want the entries to remain in the user index once they are read.

I have been using user indexes for years. I think of them as temporary tables, or work tables, not permanent data stores.

Hope this helps.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of gn pr
Sent: Monday, January 07, 2013 4:08 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: managing user indexes (*USRIDX)

Thanks Eric, I would want to have a deeply understand in this object because
seems very useful.

Alan: I do not want to have multiple index into the user index, I just want to
have replicated data in many user indexes. By example an user index that is
representing a Person struct and it have replicas with the same data: Person (
Name, Age ) --> LIB1/PERSON1.USRIDX Person ( Name, Age ) -->
LIB1/PERSON2.USRIDX

Person ( Name, Age ) --> LIB1/PERSON3.USRIDX

When many requirements arrive at the same time to view if some persons
are registered, I would like to distribute all the requirements in the 3 user
indexes instead of to send all the requirements to just one user index

I imagined that maybe there was a way to manage the access to user
indexes, something like an 'access trigger'.

Another question, in a single user index how is the access? can many
requirements ( programs ) read the object at the same time? ( or is the
program that needs to provide the thread capability )

--- Grace Pahuasi---

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

Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.