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



Yes.
:)
If you created 5 or 8 new service programs you would pay a penalty when the
program that uses them is called, because the *SRVPGM's too would need to be
loaded. Depending on how they are compiled ACTGRP(*NEW|*CALLER|'named') they
will also have to create an activation group. 
Certainly larger service programs cost more than smaller ones, just like
loading a big program takes a bit longer than a small, tight one. You have
to decide what's best in your situation. Granted the difference between a
service program with 5 subprocedures and one with say 200 is pretty much
moot, so in your situation, no, it won't help breaking them up and could
possible hurt performance.
It is not, and should not be an all-or-nothing decision. Some people (not
you obviously) foolishly believe that they should put all their
subprocedures into one huge, corporate-wide service program. That's just
proof that those people shouldn't be allowed to drive yet.
Good question!


-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Booth Martin
Sent: Saturday, January 28, 2006 10:39 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Service programs

Sorry for this really dumb question, but it is something I don't know 
and would like to know.

Lets say this service program includes 42 various subprocedures.  Lets 
say one of our main programs uses this service program because it needs 
subprocedure4 and subprocedure12.  Is there any performance penalty paid 
because we have 40 other unused subprocedures bound into our program? 
Would we get performance improvements if we divided our 42 subprocedures 
  into 5 or even 8 service programs?

Bob Cozzi wrote:
> Thomas,
> 
> You can read/write/update files in service programs.
> Service programs are nothing more than a collection of subprocedures and
> fields that are isolated in an independent object for greater access.
> Simply use NOMAIN as a keyword on the Header specification in the source
> members you use to create the service program. Do not use mainline-Calcs
in
> the service program source members. Other than that, it is effectively
> similar to writing RPGIV application programs. The only difference is
you've
> moved the subprocedure out to a secondary source member and compiled them
> separately.
> 
> 
> -Bob Cozzi
> www.RPGxTools.com
> RPG xTools - Enjoy programming again.
> 
> 
> -----Original Message-----
> From: rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx
> [mailto:rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx] On Behalf Of thomas
> Sent: Friday, January 27, 2006 4:47 PM
> To: rpg400-l@xxxxxxxxxxxx
> Subject: Service programs
> 
>  does anyone have a simple service program I could look at to start to
> understand them.  A list of rules of what has to happen would help.  Have
> figured out that you cannot read and write files in a SERVICE program. Or
at
> least I think that is right. Thomas Burrows
> 
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!


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.