Re: Procedure Examples VR7.1 -- RPG400-L

Linking a module to multiple programs or service programs is a lot like
playing Russian Roulette. Sooner or later you are going to blow your brains
out.

When you do a bind by copy you are making a copy. If you change the
original, the copy is still the same so you have to make sure that ever
program or service program that had that module bound in is recompiled or
re-linked. Sooner or later you are going to missing something and you are
going to have two different versions of logic running and it is invisible.
The more you do it, the more likely you are to have the problem and boom.
Damage it causes might be small or it might be huge. You just never know.

On Thu, Feb 2, 2017 at 9:02 AM, Duane Scott <dscott@xxxxxxxxxxx> wrote:

Ok. Belay my last question on my last response, (to buck).

This reminds me of the answer I was looking for. Thanks Charles.

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Charles Wilt
Sent: Thursday, February 02, 2017 12:00 PM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: Re: Procedure Examples VR7.1

Programs and service programs both require Activation (
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/ilec/activa.htm)

Activation performs the following functions:
- Allocates and initializes the static data needed by the program or
service program
- Resolves imports to runtime addresses of the corresponding service
program exports.

There is overhead involved in activation.

However, true ILE program and service programs remain active till the
activation group ends. RPGIV programs with DFTACTGRP(*YES) end when the
program returns with LR=*ON.

By default, any service program needed are activated when the program
needing them is activated. However, IBM added an enhancement to the
BNDSRVPGM parameter... BNDSRVPGM(MYSRVPGM *DFER) that defers the activation
of a service program till a procedure in it is called. It's only an issue
when you've got lots of service programs being used.

From a performance standpoint, simply stay away from ACTGRP(*NEW).

When starting out..
PGMs
DFTACTGRP(*NO) ACTGRP(MYCMPNY)

SRVPGMs
ACTGRP(*CALLER)

Charles

On Thu, Feb 2, 2017 at 8:49 AM, Duane Scott <dscott@xxxxxxxxxxx> wrote:

Ok. Some clearer. But I sometimes need to sleep on things awhile
when there is nobody to hit me over the head with clear examples.

Situation: I have a single $ figure that would be obtained from one of
three files depending on several factors, say 3 or 4. I could use a
procedure to obtain the $ figure in a display program for the user
benefit and in a batch process that MAY need the $ figure on each of
many records but not all.

I can see a bind by reference being the best for the display program, but
would it also be best on the nightly process? Once invoked, would the
referenced procedure become part of the job or each instance of need
be "loaded" into the job and cause additional overhead during the run?
(Does this even make sense, or am I not seeing the picture at all?)

duane

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Bradley Stone
Sent: Thursday, February 02, 2017 10:15 AM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: Re: Procedure Examples VR7.1

Duane,

Service Programs vs Modules is one of those things that is very
dependent, I feel, upon where and how it's used.

If I'm writing code for a shop for our custom software, I'll most
likely use service programs (bind by reference) for most of the

functions.

If I'm writing code to be distributed (as I do as an ISV) for most of
the internal functions I use modules (bind by copy).

For functions I want to make available to customers I use service

programs.

Even YAJL I'm now using as bind by copy. Scott and I ran into an
issue with my software vs Help systems using different versions of the
service program. I had anticipated this earlier and made the latest
versions of my software that use YAJL bind by copy. The customer
installed the new version of my software and things were honky dory

again.

Never say never. Never say always.

Bradley V. Stone
www.bvstools.com
Native IBM i e-Mail solutions for Microsoft Office 365, Gmail, or any
Cloud Provider!

On Thu, Feb 2, 2017 at 8:25 AM, Duane Scott <dscott@xxxxxxxxxxx> wrote:

Whoa. Wait! Not understanding this concept.

I bow to the experts on this as I'm most assuredly not proficient,
but I need clarification and pictures and diagrams (yes, I'm that old).

I'm fairly understanding of how procedures work, but I've not been
able to sit down with someone who uses it in a working environment.
Can you elaborate on the "Bad, bad thing to do." (More
specifically) what is it that is bad and why?

Duane

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
Alan Campin
Sent: Wednesday, February 01, 2017 4:53 PM
To: RPG programming on the IBM i (AS/400 and iSeries) <
rpg400-l@xxxxxxxxxxxx>
Subject: Re: Procedure Examples VR7.1

As you note, I use the Service program name. Obviously easy if you
know the service program name to find the module it is in and
usually a service program only has one member anyway and please
never bind the same module to multiple programs or service programs.
Bad, bad thing to do. Create service programs.

CONFIDENTIALITY NOTICE: This electronic message transmission is
intended only for the person or entity to which it is addressed and
may contain information that is privileged, confidential or otherwise
protected from disclosure. If you have received this transmission, but
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of the contents of this
information is strictly prohibited. If you have received this e-mail
in error, please contact NALC Health Benefit Plan at 703-729-4677 and
delete and destroy the original message and all copies.
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD