Re: Serviceprogram and BNDDIR Parameter

Hello Alexander,

This is becoming tedious.  On the presumtion that your questions are not
retorical ...

You wrote:
>How to organize our binding directories doesn't have a single
>right answer. It is really whatever works best for me. But I don't know
>what is the best solution of all your answers.
>(I remember the time when only the CRTRPGPGM command exists....)

I remember those times too.  There is actually a right answer.  You tried
one approach which seemed best for you but you have found that it doesn't
always work.  You've been given a number of other approaches.  Pick one.

>Simon Coulter wrote:
>> You should be using a change management tool to build your programs and
>> service programs.
>What is the best tool for us? What about the prices?

You must evaluate the available tools.  There are at least 4 that would be
suitable.  Pick the one you like best.

Prices?  Ask the respective vendors.  Do you want something for nothing?
In that case investigate an open-source source code control system and
port it to the AS/400.  It will cost nothing but time (and of course time
is free).

>Barbara Morris wrote:
>> Alexander, for each program and service program, create a binding
>> directory of the same name containing all the modules and service
>> programs it needs to compile.  It should then be easy to
>>      crtpgm xyz   bnddir(xyz)
>>      crtsrvpgm abc bnddir(abc)
>The merits of this approach are that it in effect creates a
>"specification" of the objects required to create a program. We also
>don't need to as worried about name collision. It is an easy solution.
>But there are a lot of binding directories.

Many binding directories versus many build scripts.  I don't see much
difference.

>Simon Coulter wrote:
>> I use a build script for each service program...
>> I may choose to use a binding directory also for things like
>> the QC2LE entry points...
>> I use a generic build script for my programs in which I list the main
>> entry module and the application binding directory.  The application
>> binding directory contains service programs only.
>> If I build a program out of multiple modules (e.g., logic,
presentation,
>> etc.) then I would create a specific build script that listed the
specific
>> modules and the binding directory of service programs.
>This option may be something in between where you use "bind by copy"
>mixed with "bind by reference" (Service-Pgms).

Any non-trivial application DOES use both methods.  At the simplest level
service programs are built using bind-by-copy and programs are built using
bind-by-reference (if we ignore the fact that programs must have at least
one module which must be bind-by-copy).  In actuality programs and service
programs use both methods; a given service program to handle database I/O
will be built from specific database modules but might also make use of
string functions from a STRING service program and maths functions from a
MATHS service program, a given program might have a module for logic which
calls functions in the TAX service program, a specific module for
presentation, a module for database I/O which calls functions in the
DATABASE service program, and so on.

Even using binding directories does not alter this fact.  *MODULE objects
found in the binding directory will be bound-by-copy, service programs
will be bound by reference.  What's your point?

>This implementation may require a great deal of planning, thought and
>rules. Creating a lot of scripts, binding directories and so on.

Surprise me!  All serious programming requires "a great deal of planning,
thought and rules".

>There is no single best solution, more options lead to more flexibility
>and more decisions to make....

Actually there is a "best solution".  It is the one that works with
minimal disruption in the maximum number of environments.  Read up on John
von Neumann's Minimax Theorem.  If you believe that your environment is
not zero-sum then investigate John Nash's Equilibrian Theorem which is a
reduction of Minimax.  You've been given a number of approaches, all of
which are better than your current approach.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists
   http://www.flybynight.com.au/

   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------