RE: Subprocedure Question

Isa,

The binding directory is only used at compile time.  It doesn't really matter 
how many entries are in it.

Note that when deciding between service program/modules modules are bound in at 
compile time whereas service programs are activated and bound during run-time.  
The activation requirement for service programs means there is a performance 
impact.  Nothing you usually need be concerned about.  But if you've got a 
program that uses 100s of files and thus 100s of service programs, you might 
see a difference.

In addition, while I normally have one file == one service program as I begin 
moving slowly toward externalizing I/O, you may want to consider sets of files 
in a single service program.  For instance, if a most programs that need FileA 
also need FileB, FileC, FileD, and FileE, then it might make sense to bind all 
five file modules into a single service program.  Concrete example would be an 
ORDERS service program made up of the ORDHDR, ORDDTL, and ORDNOTE file I/O 
modules

Make sense?

One thing I think is important to keep in mind when trying to externalize file 
I/O is that if the procedures are simply GetRecord() or GetField(), you not 
doing much for yourself except creating extra work.  Instead, you want to 
incorporate the business logic into the file I/O procedures.

For example:

/free
  CUSTOMER_OpenRecord(myCustNbr);
  if (CUSTOMER_GetStatus() <> 'A');
    // customer not active error
  endif;
/end-free

vs.

/free
  if CUSTOMER_IsActive(myCustNbr);
    // customer not active error
  endif;
/end-free


My rule of thumb is that the only reason to call a "Getter" procedure is to 
display the value on screen or print it on a report.  Similarly, for "Setters" 
you don't want something like this:

/free
  CUSTOMER_OpenRecord(myCustNbr);
  CUSTOMER_SetStatus('X');
  CUSTOMER_UpdateRecord();
/end-free

instead, try this:
/free
  CUSTOMER_Inactivate(myCustNbr);
/end-free

Note that CUSTOMER_SetStatus() should be being called by CUSTOMER_Inactivate();


HTH,




Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Wall, Isa (ED)
> Sent: Thursday, September 01, 2005 10:55 AM
> To: RPG programming on the AS400 / iSeries
> Subject: RE: Subprocedure Question
> 
> 
> Paul,
> 
> Thank you for your prompt response.  I have a question on performance.
> If I have all my modules in one binding directory would that affect
> performance?  I am picturing a program that only needs one 
> file and yet
> I have attached a binding directory with thousands of modules to the
> program.  Is that a problem?
> 
> I thought of separating the subprocedures to one module for each file
> and logicals.  The only benefit I can see is that my modules would be
> smaller, which will be a cleaner way of doing it.  Why would you do it
> that way?  I am open for suggestions...
> 
> Thanks,
> 
> Isa
> 
> 
> 
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Paul Morgan
> Sent: Thursday, September 01, 2005 10:33 AM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: Re: Subprocedure Question
> 
> Isa,
> 
> You could create a module for each file with every module 
> listed in the
> binding directory.  You could also create a service program 
> using those
> modules with every service program in the binding directory.  
> Either way
> something is going to have to be listed in the binding directory.  You
> will
> end up with a binding directory with thousands of modules just as you
> have
> thousands of files.
> 
> If you use service programs you will be sharing that file between
> programs.
> The file would be opened once in the service program.  If two programs
> use
> that file (service program) but one program calls the other program.
> The
> second program called from the first could do something with the file
> (SETLL, READ, CLOSE) that interferes with the first program.
> 
> With modules a copy of the module gets created in each program.  Two
> programs that use that file would each get a copy of the 
> module.  In the
> same example above the second program wouldn't intefer with the first
> program as the file would be opened twice.
> 
> Sometimes sharing a file between programs is desirable.  
> Maybe the file
> is a
> code file that only has random retrieval (chain) of records.  In that
> case
> use a service program otherwise stick with modules.
> 
> Have you considered making separate modules for the logical files
> instead of
> including them in the same module with the physical file?  
> You'd have a
> module for the physical file and one module for each logical file.
> 
> Paul
> 
> -- 
> Paul Morgan
> Senior Programmer Analyst - Retail
> J. Jill Group
> 100 Birch Pond Drive, PO Box 2009
> Tilton, NH 03276-2009
> Phone: (603) 266-2117
> Fax:   (603) 266-2333
> 
> Isa wrote
> 
> I would like to ask your option on the following subject.  I 
> am planning
> on implementing subprocedures for all file actions.  For 
> example, if you
> want to read, setll, open, update or write a record to a file 
> you would
> call a subprocedure.  I am planning on creating a module for 
> each file.
> Inside each module I would create all subprocedures related 
> to that file
> and logicals.  My question is the next step which I don't know what is
> my best action.  I now have a module for each file do I 
> create a binding
> directory for all the modules.  To me this does not make sense as we
> have thousands of file in our system.  So do I create a 
> service program
> for each module and at compile time bind them as I need them? 
>  Is there
> another way I can do this?  What is the best to handle this?
> 
> 
> 
> -- 
> 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 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.
> 
>