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




On 27/04/2010, at 5:28 PM, David FOXWELL wrote:

I have almost no experience of srvpgm, but soon I will be replacing the modules in our pgms by srvpgm. I would therfore be very interested to know how you managed to not bind to your srvpgm. Is it possible to bind to both the module by copy and the srvpgm by reference?

Yes it's possible, but to be blunt, only if you're an idiot. Usual cause is specifying a binding directory containing modules instead of either a binding directory containing service programs or the necessary service programs directly. Another cause is binding directly to modules that would be better served by being in a service program (a situation I'm sure you're familiar with). In this case it was because of a failure to check how the program was built thus presuming it would use the updated service program.

If you completely cock-up and reference both the modules and the service programs containing those modules (either directly or via binding directories) then the default behaviour will complain about duplicate definitions. There are very limited situations when you might choose to resolve that by specifying either or both of OPTION(*DUPPROC) or OPTION(*DUPVAR).

The proper solution is to design a way of working with modules and service programs that doesn't allow this effect. For me that is to always specify required modules on the appropriate create command. Only put service programs into binding directories. Reference the binding directory in the program if possible (e.g. H-Spec since this is the RPG forum) or on the create command otherwise.

A possible modification of this is to have a binding directory with the same name as the service program which contains only the modules for that service program and which is used only when creating the service program. However, I've found that unnecessary with a decent change-management system.

This way you end up with create commands like:

CRTSRVPGM DATE MODULE(DATE TIME TIMESTAMP)
CRTSRVPGM STRING MODULE(STRING)
CRTSRVPGM MATH MODULE(MATH)
CRTSRVPGM FINANCIAL MODULE(FINANCIAL)
CRTSRVPGM MEM MODULE(MEM)
CRTSRVPGM OBJ MODULE(OBJ)
CRTSRVPGM SEC MODULE(SEC)
CRTSRVPGM USRSPC MODULE(USRSPC)
CRTSRVPGM STDIO MODULE(STDIO)

CRTPGM OE MODULE(OEMAIN OEWS OEDB) BNDDIR(COMMON)
CRTPGM AP MODULE(APMAIN APWS APDB) BNDDIR(COMMON)

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.