Re: RPG and Encapsulation


Matt wrote:
My questions are for those of you who have played around with
encapsulating file access in service programs.

I became interested in encapsulating file access in service programs
not long after I started working in RPG. I read the only article I
could find on using encapsulation at http://www.rpgbeans.com/. I
wasn't thrilled with the method that he uses (sorry, Joel). I think
it neglects one of RPG's strongest features (IMHO): data structures.
As a result, I came up with my own method that utilizes data structures
to pass file fields to and from the service program as opposed to using
dozens of set/get procedures. As much as I hate doing so, I define the
data structure for the file accessed in the prototype of my service
program. If I were to use the LIKEREC keyword, the program which calls
my service program has to specify the file in its file list even if it
doesn't need access the file. I did adopt Joel's naming convention
for my service program procedure names as I usually name the procedures
something like FileName_Procedure. The four procedures I usually have
are:

File_SetKey(parm1, parm2....)
File_Update(FileDs)
File_Add(FileDs)
File_Delete()

FileDs is the file data structure. File_SetKey is a simple procedure
that performs a SETLL on the file (based on the parameters) and returns
*ON if a record was found. File_SetKey needs to be called before other
procedures, such as File_Delete, are called. Of course, additional
procedures are added based on the needs of the individual file or
application.

What do you think of the above strategy? How could it be made better?
I would love to see examples of how other, more experienced RPG
programmers utilize service programs to manage files.

Are you sharing the open of the file for all callers of your
procedures? How do your files get opened and closed? The question
there being what happens when one procedure positions into the file for
one purpose, then another procedure chains into it for another?

I like your naming convention.

I share your discomfort with LIKEREC. My reason is that LIKEREC
reinforces the RPG distinction of input fields from output fields in
the database file buffer. I think that adds unnecessary complications
to RPG code.

-Steve

.

Relevant Pages

  • Re: Parsing XML from RPGLE
    ... It is basically a toolset (say collection of service programs) for RPG ... iSeries for other platforms/languages to call. ... the site for RPG-XML Suite is www.rpg-xml.com; ...
    (comp.sys.ibm.as400.misc)
  • RPG and Encapsulation
    ... I became interested in encapsulating file access in service programs ... I came up with my own method that utilizes data structures ...
    (comp.sys.ibm.as400.misc)