Why would they always Bind?

["Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx>]

 >> Do you'll think it is just their way of making sure they are there if
needed?

Yes I suspect that is the case - the vendor has to assume that the client is
"ILE illiterate" since sadly that is normally the case.

 >> What is the impact of doing this when not needed?

Nothing.  A binding directory is a "yellow pages" type of list that can be
used when the routines required by the program are not found within the
modules supplied to the bind process.

 >> Also when they do the recompile they are told to always use PKMS as
activation group.  I say *caller because if for some reason down the road
that gets changed in that package  they will be covered by *CALLER.

Have to disagree with you here.  If they say use a named group they probably
have a reason for doing so.  This could be overrides, exported data items,
shared ODPs etc.  *CALLER raises the possibility that the program could run
in the default or another named AG in which case it will not see overrides
etc.

 >> Also they have other packages with different activation groups and with
*caller they will not have to remember each one for each package when doing
custom mods. Am I wrong in telling my client this?

I think you are wrong yes.  _If_ your client understands ILE then they can
look at the individual programs and determine the appropriate AG use.  If
they do not understand, then they are better off to follow the instructions
of those who wrote the software in my opinion.

The one thing that surprises me is that the vendor expects them to
"remember" which AG etc. to specify.  The simple approach to this is to code
H specs that define the BNDDIR, DFACTGRP and ACTGRP parameters - this way no
one has to remember.  The vendor should have done this.  In fact I would
create on simple source member that contains the directives and add a /COPY
of it into every program in the package.  You might suggest this to the
vendor.


Jon Paris
Partner400
www.Partner400.com