RE: A Question Of Technique

Kelly,

I suppose one big question is, do you need to keep the records accessed via each path separate?

Is so, the rename of the records format + prefix is a good choice. You could also take advantage of
RPG's ability to read and write directly to a data structure.

Normally, however program like you describe are only concerned with one record at a time and don't
care which access path is used to get it. In that case renaming the record format is all you really
need to do. You want the files to share the same buffer, so leave the field names the same. Also,
you could also use the read/write directly to a DS here to.

You say you don't use ILE, which is too bad. Because this is an excellent example of where ILE can
benefit you; instead of having the multi access path logic duplicated in every program. You could
have it in only a single ILE service program.

The service program could have procedures like:
GetItemByItemNumber()
GetItemByItemSubKey1()
GetItemByItemSubKey2()

Though I'd hope you'd give them meaningful names by replacing SubKeyX by whatever that key means to
you.

Possibly an even better way may be to consolidate into a single GetItem() procedure, that takes too
parameters. The first is a "KeyType" and the second is the key. The disadvantage is that such a
procedure is a little harder to use, but the advantage is that you reduce the logic in the calling
programs and make it easier to add new ways to lookup the item to existing programs.

In fact, by softcoding the valid "key types" you could add new lookup methods to your programs without
having to recompile them. Only the service program would need updating.


HTH,
Charles




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kelley
Sent: Tuesday, December 11, 2007 6:21 PM
To: RPG programming on the AS400 / iSeries
Subject: A Question Of Technique


I have a file of items in inventory, surprisingly enough called INMAS. There are 10 logical files
connected to this physical file. The primary method of accessing INMAS is through the item number. The
item number is 10 digits long, however, it is broken into 5 2 digit fields (a long practice in the
industry I'm in). As you might guess, some of the logical files allow access to the data via 1 or more
of these item number subfields. Another way this file is accessed is via a OPC code (UPC code in other
industries).

In a large number of programs, the users have the ability to access inventory items via either the
item number or its OPC code. To support this function, we have the physical file and at least one
logical file described in the program. We have any number of ways for dealing with the duplicate
members and fields this creates.

The methods range from using internally defined files, data structures, and the rename and prefix
options on the file spec.

My question, are there other, better, cleaner ways of dealing with issues like this?

The environment here ranges from RPG /free code with embedded SQL and some subprocedures to S/36 code
written 20 years ago that paint screens using arrays and all the indicators in the book. There is no
ILE really, no modules or service programs.

Kelley