RE: Updsrvpgm & file encap. -- RPGNEXT

On Fri, 2004-09-10 at 20:21, Richard Rothe wrote:
> Can you provide some recommendations about how you go about
> encapsulating file access ?

I create one service program per encapsulated file.  Put the SRVPGM in a
binding directory and the diretory in the H-Specs.  Doing it this way, I
can name the MODULE, the BINDER_SOURCE, and the SRVPGM all the same. 
This makes creating and updating the SRVPGM a snap.  Also, since
encapsulation creates a lot of small procedures, there are going to be a
lot of entries in the binder source as well as a lot of procedures in
the service program.  If you put too many of these files into a single
SRVPGM, then when a program uses that SRVPGM but only needs one file you
will have activated a lot of unnecessary procedures.

> I am trying to create my service programs by application....Purchase
> Orders, Sales Orders, Work Orders, Invoicing, etc.  Some of these
> service programs will use procedures from others.  That's how it's
> supposed to work, right ?

I do SRVPGMs by like procedures (in this case the file is the relative
feature) and BINDING_DIRECTORIES by application.

> The more I do, the more I find myself writing the "RPGBeans" since some
> of the files don't fall into a particular application.  Like, item
> master, customer master, any kind of reference file that has a
> code/descrition, etc.  Most of these use the "getter" logic described by
> Joel in his encapsulation article.  A getRecord, a clearRecord and then
> getField procedures.  Haven't done any "setters" in these because I have
> had the need yet.

A great time to mention that you can create a "read-only" bean by having
getters only.

> I've showed my code to the other programmers here and they complained
> that they had to do a getRecord and then multiple getField evals to get
> the data they wanted.  "We only have to do one chain and all of the data
> is there they way we do things now", is what I'm hearing.  

A little bit more coding sometimes, yes.  It depends on what they really
want.  If they want to add the results to a string, just use the
procedure in the eval statement, there is no need to use the getter and
pull the information into a program variable *every time* you want to
use it.  Embedding the procedure calls into expressions is supposed to
be one of the benefits of ILE!

> I feel like I'm headed in the right direction, but not absolutely sure.
> My biggest confusion right now is determining how to update records in
> the SOA model.

Assuming you are receiving input from some source that has not opened
the bean, you will need to x_getRecord(byKey), x_setFields(), and
x_update().  Unless I'm missing something...

Joel
http://www.rpgnext.com


> 
> 
> -----Original Message-----
> From: Bartell, Aaron L. (TC) [mailto:ALBartell@xxxxxxxxxxxxxx] 
> Sent: Friday, September 10, 2004 3:00 PM
> To: RPGNext Discussion and Information
> Subject: RE: [RPGNext] Updsrvpgm & file encap.
> 
> 
> IMO, stop right where you are at and evaluate ROI.  How much time are
> you spending creating these intimate RPGBeans vs. doing upgrades to
> programs that are using the files directly.  And even if the files are
> using your RPGBeans, depending on how you code them, you will still have
> a decent amount of work to do when a file changes because the RPGBean is
> bound into the other programs.
> 
> I have been where you are at and I see very little to zero application
> to doing file encapsulation at the level that is being suggested in this
> thread.  If you are providing business logic and enforcing rules, then
> you start to build ROI.  But without that you are spending a lot of time
> coding for nothing.
> 
> Aaron Bartell 
> 
> -----Original Message-----
> From: rpgnext-bounces@xxxxxxxxxxxx [mailto:rpgnext-bounces@xxxxxxxxxxxx]
> 
> Sent: Friday, September 10, 2004 2:44 PM
> To: rpgnext@xxxxxxxxxxxx
> Subject: [RPGNext] Updsrvpgm & file encap.
> 
> Howdy Joel,
> 
> This is that other Joel. I've started working on doing the file
> encapsulation and so far I like how it's working, but wow, it's a TON of
> work doing service programs for hundreds of files. I can see the benefit
> once you get it done, so I think I will continue.
> 
> I am having a little problem with the updsrvpgm. If I understand right I
> should be able to make a change to a service program and then all I have
> to do is the updsrvpgm command, but when I try this is doesn't seem to
> take. In order for my changes to activate I have to remove the service
> program from the binding directory and  then put it back, and re-compile
> the program(s) using the service program. Any clues on what I might be
> doing wrong?
> 
> Thanks,
> Joel Schibbelhute
> 
> 
> 
>               
> _______________________________
> Do you Yahoo!?
> Shop for Back-to-School deals on Yahoo! Shopping.
> http://shopping.yahoo.com/backtoschool
> _______________________________________________
> This is the RPGNext Discussion and Information (RPGNext) mailing list To
> post a message email: RPGNext@xxxxxxxxxxxx To subscribe, unsubscribe, or
> change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpgnext
> or email: RPGNext-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives at
> http://archive.midrange.com/rpgnext.
> 
> _______________________________________________
> This is the RPGNext Discussion and Information (RPGNext) mailing list To
> post a message email: RPGNext@xxxxxxxxxxxx To subscribe, unsubscribe, or
> change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpgnext
> or email: RPGNext-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpgnext.
> 
> _______________________________________________
> This is the RPGNext Discussion and Information (RPGNext) mailing list
> To post a message email: RPGNext@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpgnext
> or email: RPGNext-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpgnext.