Re: Best way of using Service programs. -- RPG400-L

Thanks very much for all you responeses and info folks.
I am convinced about the usage of copy books is the best way to get away
from a maintenance nightmare.
Most of my doubts/fears were un founded due to lack of knowledge and you
guys were able to enlighten me.

So here are my conclusions based on the replies and I have started using in
my new project:

1. 1 or more module per service program.
2. Use Binder Language to compile Service Programs.
3. Use copy books to store PR def's one per Service Program, for less
maintenance head aches.
4. Include this copy book every where you want to declare the procedure.
(Module the procedure is defined as well as where ever it is used)
5. Over time as the number of service programs used increases, use a Binder
to group Service Programs and use it in CRTPGM command.
6. Use a scheme to define the procedures in such a way so that similar
procedures in different Modules/SrvPgm's will not conflict.
      I am following a convention of ModuleName_ProcedureName. It is a
little big on Typing but makes the code a lot more readeable.

Also I learnt the following:

1. Service Pgm Signature:
   signature comes from the exported procedures and their order.
   Procedure parameters have nothing to do with a service program signature.
   Service Pgm Signature is a function of two things, the names of the
_procedures_ and the _order_ in which they are exported.

The signature of a service program does not change
   1. If you change the business logic of a procedure.
   2. If Procedure definition is changed.
        need not recompile programs that do not call the modified procedure,
even though the procedure definition declared is outdated. (This can
happend when using copy books)
The signature changes if:
   1. A new Procedure is added.
   2. Delete an exising procedure
   3. Change the order of the procedures in the module.

2. Binder Language/Binding Source:
Binder source is the only way you can avoid recompiling existing
programs when a service program's signature is changed.


Thanks for all you advice.
I will be moving my focus to Activation Groups now. I have a lot of
questions/doubts on using them and I think it needs a seperate thread.


Thanks & Regards
Praveen


On 2/21/06, Fisher, Don <dfisher@xxxxxxxxxxxxx> wrote:
>
> We handle it with a change management package.  The good news about
> prototype definitions is that the actual procedures don't have to exist
> when
> a program is compiled.  That means the source member can be checked out
> and
> promoted for checkout by others very easily.  That may be more difficult
> in
> a larger shop and were I in that position I'd probably have to rethink the
> single source member concept.  Then again, a big shop could afford to have
> someone keep a document of all the procedures and where the prototypes
> reside.
>
> With a change management package, an emergency bug-fix, which I would
> think
> would only very rarely entail changing a prototype definition, is handled
> easily.  The production source is checked out, changed, and promoted back
> to
> production.  Anyone else that has the source member checked out gets a
> condition code that indicates the production source has been changed since
> it was checked out.
>
> Donald R. Fisher, III
> Project Manager
> Roomstore Furniture Company
> (804) 784-7600 extension 2124
> DFisher@xxxxxxxxxxxxx
>
> <clip>
> I agree that name clashes are more difficult to manage when using multiple
> source members, but in large MIS departments the thought of runnning
> multiple concurrent projects, is bad enough. But with the added
> complication
>
> of putting all prototype changes/additions into the same source member
> makes
> me want to take a lie down. :-) I can't even image how we would handle
> that.
> <clip>
> I just don't like the idea of having to change a prototype in a module for
> a
> production bug-fix, only to find three other programmers are working on
> the
> source member for three completely different projects. They'd have to back
> their changes out so I could get the "clean" code + bug-fix back into
> production asap. The more modules you include in this source member the
> higher the chances this will happen.
> <clip>
> --
> 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.
>
>