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



Mark,

Please ignore my earlier reply. Knowing how thorough you are, I went through your reply and still missed the last couple of paragraphs.

I'm going to have to start going to bed a lot earlier.

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S. Waterbury
Sent: Tuesday, May 19, 2009 12:26 PM
To: Midrange Systems Technical Discussion
Subject: Re: Procedures, Modules, Service Programs

Hi, Birgitta:

The main problem with binding many modules into a single large service
program is that you force the system to activate the entire large
service program "all at once" -- the more procedures it has, the longer
this process will take. By keeping service programs smaller, with
relatively fewer procedures per service program, you can keep this
overhead to a minimum.

Note, however, that If service program A uses a procedure in service
program B, then when A is activated, this will cause B to be immediately
activated, too, and so on, down the line (if B uses procedures in C, and
so on). This process can add significantly to the "overhead" associated
with activation.

At V6R1, IBM implemented the ability to delay activating other service
programs until they are actually needed (when any procedure in that
*SRVPGM is first called). You must specify a new *DEFER option on the
BNDSRVPGM parameter of the CRTSRVPGM command to take advantage of this
new feature. For details, see:


http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/cl/crtsrvpgm.htm

This could be beneficial if you have many small *SRVPGMs that use
procedures in many other small *SRVPGMs, and you are running V6R1.

All the best,

Mark S. Waterbury

Birgitta Hauser wrote:
Hi guys,



I'm just curious and I'd like to know how to handle it:

Procedures, Modules, Service Programs and Programs



(We just had some discussions about it).

Currently I'm using several procedures within a single module (grouped
according functionality).

To make it easy I normally create a service program for each module
(exceptionally I also bind several modules with generic names for example
Date* into a service program).

Into a program only a single module gets bound and I never export procedures
from a program module.



An colleague argues having a lot of service programs is not good, he insists
in having a single service program with all modules for the whole
application, because there will be only a single activation.

I don't like this idea, because: If I only want to use a string function for
my batch program all display and printer file and what else functions must
be activated.



I just like to know how you handle it and why.



Mit freundlichen Grüßen / Best regards



Birgitta Hauser



"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)

"If you think education is expensive, try ignorance." (Derek Bok)

"What is worse than training your staff and losing them? Not training them
and keeping them!"





As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.