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