RE: Binding directory question

David,

That is what I did for our existing code base:

First thing I did was create the binding directory (CRTBNDDIR). Then I
identified all *Module objects (most all of my compiled code is in one
library).

Next I used a PDM option. BN = ADDBNDDIRE BNDDIR(your binding directory
name/your library) OBJ((&N *MODULE)) to add each object to the directory.

Then I created a /copy member to provide the H spec for my programs. It
contains the following:

H Option(*NODEBUGIO : *SRCSTMT)
H BNDDIR('your binding directory name') BNDDIR('QC2LE')
H DFTACTGRP(*NO)
H ACTGRP(*CALLER)

One thing this did expose was that during subsequent program compiles, the
binding step failed because we had a few modules that used the same
import/export field names in different modules and the binding directory
couldn't resolve them at compile time. This was a good thing because it
forced us to review the offending modules and rename their import/exports
so they would be unique. This required changes/recompiles to about 20
source members.

As for the introduction to service programs, it was a bit more effort but
well worth it.

This was an entirely new application, modularized to the max with numerous
copy members, and all of the procedures were placed into one of two
service programs. One service program handles 'utility' type stuff and the
other one has 30 /copy statements to call what would have been 30
standalone rpg programs (see next sentence).

My QRPGLESRC file for this application has 43 source members, 38 of them
are /copy members (30 of which would have been standalone RPG programs had
my staff coded using their traditional approach). 3 are actual compiled
RPG programs and 2 are the service program members. Two of the /copy
members define the prototypes for each service program.

Individual copybooks are used to define a data area, constants, h specs
for both programs and procedures, F specs (with USROPN - this was probably
overkill and this doesn't work if I need to change file attributes such as
type of access, add records, output only etc - but does work in this
instance for this application). The point was to show the staff how to
modularize code and only define things in one place when possible.

You will also want to use binder language for your service programs. This
lets you define what procedures in your service program can be exported
(ie accessible to your RPG programs) and lets you manage backwards
compatibility when you change your service programs. You have to add
entries in your binding directory too for the *SRVPGM objects so the
compiler can locate them.

The only thing I didn't get to do was to externalize the database I/O
(someday - when time permits....)

That's most of it in a nutshell, and there are a few details I didn't go
into for brevity. Hope it helps. Good luck,

Regards, Jerry

Gerald Kern - MIS Project Leader
Lotus Notes/Domino Administrator
IBM Certified RPG IV Developer
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623-4299
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx


This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please inform the
sender by reply e-mail and destroy this and all copies of this message.