RE: Updsrvpgm & file encap. -- RPGNEXT

> 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!

The way I understand it, you have to do the getRec to get the data
stucture populated.  Then every time you want to access a field, you use
the "getter" in an eval, expression, whatever.  Right ?

Basically,

c                   If        GetItemRec( iCo : iPart )       
c                   eval      desc = GetItemDesc              
c                   eval      commodity = GetCommodityCode    
c                   EndIf                                     

Or

c                   If        GetItemRec ( Co : Part ) and 
c                             GetCommodityCode <> 'XXX'

The GetItemRec populates the data structure so the "getters" can be
used.   
-----Original Message-----
From: Joel Cochran [mailto:jrc@xxxxxxxxxx] 
Sent: Friday, September 10, 2004 11:50 AM
To: RPGNext Discussion and Information
Subject: RE: [RPGNext] Updsrvpgm & file encap.


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.

_______________________________________________
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.