RE: A Question Of Technique

Kelly,

You don't "exit" a service program...mainly because you never enter it. <grin>

Instead, the service program contains one or more individual procedures. Those procedures can be
called from outside (or inside :) the service program, ie. From your UI program.

You have two options for returning data from a procedure.
1) In an parameter variable
2) As a returned value.

In either case, the data can be a single variable or a DS.

You'll see many of examples of procedures that output/return the contents of the entire record using a
DS defined from the external file. However, I'd argue against doing it that way. When you need to
change the file, you have to recompile the world. The reality is few program really need the entire
record, mainly the just CRUD programs. The rest only need certain parts of the data in the file.

Another technique is to have Getters/Setters that set/return individual fields. Again, I'd argue
against doing it this way. Mostly because you end up duplicating the business logic related to the
fields. In addition, it's more work when you need data out of more than one field.

Instead, consider having procedures that return the data in a business appropriate way. For instance,
a GetDescriptiveInfo() that returns item#, name, size, and other often used together fields. In
addition, if you've currently got Yes/No type flag fields, don't use a GetFlagFld() type procedure to
return the actual value of the field. Instead, use a IsItemSomething() procedure. This way, if you
ever need to change the business logic behind the decision, you only need to change it in one place.

I've gone so far as to have a GetSimpleList() procedure that takes as input, the number of records at
a time you want and an empty DS of the appropriate size to fill; which I can call from multiple
subfile programs, either 5250 or web based.

HTH,
Charles

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Kelley
Sent: Wednesday, December 12, 2007 9:13 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: A Question Of Technique

Charles,

Thanks for the reply. The answer to your question is no, I just need to
get
at the data via item number or OPC code. As far as ILE goes, I have no
issues with using it, I just don't understand it enough to use it...yet.
It's not clear to me how to "exit" to a service program and return the
entire record from a file (per haps that's not what one does). Is this
done
with a data structure or with some kind of global variable?

Kelley

----- Original Message -----

From: "Wilt, Charles" <WiltC@xxxxxxxxxx>
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
Sent: Wednesday, December 12, 2007 7:12 AM
Subject: 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

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.