× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I only put service programs in binding directories and I only use one
directory for each major application (entire company).

I've always followed the standard of putting similar procedures in one
service program, like all message-handling procs, or all string-handling
procs, and that seems to work very well.  In that scenario, I've never found
the need for more than one module per service program.  If you have more
than one, that may be an indication that you need to break down the service
program to more discrete sets of procedures.  Your best and most useful
service program procedures will be those that only do one small function. If
they are built that way, it should be easy to group them into task-related
service programs.  If your procedures perform more than one function, they
probably need to be broken down further.

Generally, the only place I've found a need for multiple modules is in
application programs, not service programs.  The exception to that is on
file-related service programs.  There, I have one module containing all the
I/O functions for each physical and one for each related logical file, and I
group all those modules together into one service program for each physical
file.  I use a CM system that incorporates what would be a make utility, so
it is not a problem to keep up with the module list.  If I didn't have that,
I would probably use a small binding directory to list all these modules for
each service program, or you could create a small CL to help maintain it.

On the binder language question, RTVBNDSRC will very quickly and easily
create your first binder source member for each service program, but after
that, ALWAYS modify it by hand. RTVBNDSRC will really mess up an existing
binder source member.  (It just loves to re-order your exports for you...)


> Right now, my biggest issue with the whole deal comes down to managing the
> service programs.  Say I create a new module, I've got to recreate the
> service program that it should reside in.  I've got to update my binder
> language source first - by hand it would appear.  Then CRTSRVPGM -- and I
> have to retype all of it's constituent module names.  If there are 100
> modules, yuck.  I'm sure to forget one.
>
> Are you manually managing the binder language source?  What, if any, tools
> are there to help?
>
> Thank you.
>
> Regards,
> Rich
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which may be confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.