UUNMSR, UNDESC, UUOMCD

EA      Each          EA
CS      Case          CA
BX      Box           CA
SP      Shelf Pack    PK

Instead of loading the file into a multiple occurrence data structure, use an array. Then you could use a lookup function on the array to find the particular element you need.

---

Thanks for the reply. Maybe I am misunderstanding something here, but I thought that an array was made up of single elements. ie. an array of 10 two character codes. This would be fine for validation, but would not allow me to store the other two fields. Am I missing something here?

---

Yes. You missed the possibility to have other arrays contain the info you need!

For instance, you have the array with your unit of measure and find your user's input e.g. in element 2.

Then, you can access another array with your descriptions with index 2, and so on.

You can load the arrays at program initialization time from a file to avoid hardcoding (manually or by means of a prerun-time array [you'll find this in the RPG reference]), or, which is slightly more complicated, but also a common method, first lookup your array, and if you do not find it there, chain to a file. If you find it there, you can put it into the array(s). But I do not think that there is much performance won.

The AS/400 doesn't really access the hard disks every time to get records, OS/400 will move the stuff to the main storage, but you do not have to care about that.

A more difficult method, but performing very good, is the use of an user index, but that's not quite a point to start for a beginner.

Hope this helps!

---

Thanks for the reply. I hadn't thought of breaking the data up like that...I was thinking about working with the entire record as a whole from the file.

---

Yes. Alternate arrays are supported. This lets you define 2 arrays that are related. The first array would be your unit of measure. The second array would be a composite field of the description and X12 unit of measure. Use a data structure to split the second array into its subfields.

Normally I would just load the arrays in ordered sequence at initialization time and do a lookup for each record when the new lookup is differant from the prior lookup. This approach saves 1 disk I/O request per output record and minimizes the number of times lookup is actually executed.

I/O is much slower than lookup. Lookup is slower than reusing the prior values.

---

You don't need to use MO Arrays. You can define arrays in data structures, and even sort with them. For example:

DDS
D UOMArray  34DIM(100)
D  UOMKey    2          OVERLAY(UOMArray)
D  UOMDesc  30OVERLAY(UOMArray:3)
D  UOMCode    2OVERLAY(UOMArray:33)

Now, you load the fields by saying UOMKey(index) = xxx, UOMDesc(index) = xxx, and UOMCode(index) = xxx

This way you have all your fields together. If you wish to sort the arrays and keep the indecies intact, simply sort by the subfield of your choice. For example

 * sort by Description
C                SORTA          UOMDesc
 * sort by Code
C                SORTA          UOMCode

Alternating arrays, who needs em! This is the best array technique I have learned in years.

---

Thanks for the reply. You make some very valid points, especially about not doing the lookup if the last one is for the same code. Since 95% of my items are coded with the same code this should eliminate any performance problems.

I had already thought of this after my original post, but in the back of my mind I thought I remembered reading about something that was ideal to this scenario.

---

For a table of this size/complexity (not!), maybe you could just use SETOBJACC to load it into a small memory pool. Then, ignore thoughts of performance degradation. Other than that, if loading into an array doesn't suit your taste, I wouldn't even think twice about the performance aspect unless you're already hitting a performance curve -- in which case you've got other bigger problems.

---

If you only need to see if the entry made exists in your file you can do a SETLL using an indicator in the = position. This technique uses less overhead because no data is brought into the buffer at any time.

Also if you are using a CHAIN and the key value does not change from the previous CHAIN, the values still remain in the buffer. This is also less overhead than if the value changes and a read( disk)/write( buffer) actually occurs. It may be the same overhead or less than checking for a changed value in your program before chaining.

---

Just to test the performance hit, I wrote a small program to read the entire article file (88000 records) sequentially. On our model 620, this took 1.5 CPU secs. After adding a chain to our Unit of Measure file the program took 7.1 CPU secs. This shows that a chain takes a significant amouont of time (relatively). If you have a large AS/400 and/or a small article file, you probably won't bother if the job takes 5-10 secs. longer to execute.

If you do care, the methods suggested by others (array lookup or chain with array caching), will work fine. If you're using ILE you may write a function that checks the UOM code using SETLL (which requires less CPU than a chain), and functions to retrieve each of the corresponding UOM attributes. These routines may well use arrays, caching, or simply hardcoded data (since they're only specified in one source member, you can move them to a file later if you want to).

---

you make a wrong assumption here. If we talk I/O operations, CPU time is not a concern. The question is runtime. For each sync I/O, the cpu timeslice is ended and the job (after completing the I/o) will have to compete for a new timeslice again.

---

Database I/O is what the AS/400 is designed for. I can't imagine that a simple read to a code table can impact performance in a perceptible manner.

Certainly, the coding simplicity of a simple chain is much more desirable than the complexity of other approaches (arrays or data-structures). In many cases simplicity of code is much more desirable than the marginal improvement in response time a caching algorithm would give.

However, one thing you should do in whatever design you choose: don't do the lookup if the last lookup was for the same code. This technique alone can save a good percentage of necessary I/O.

---