Re: CALLPRC issue "Definition not found for symbol"

[Dan <dan27649@xxxxxxxxx>]

I think I got my answer with the mixed case naming of the procedure.  But,
for reference, CABNDDIR has only the CA9800 *SRVPGM object in it. I have
never considered putting *MODULE objects into a binding directory.
(Actually, I didn't know you could, and I'm not sure why one would.)

- Dan

On Thu, May 17, 2018 at 3:27 PM, Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

> Hi, Dan,
>
> Issue:
>     DSPBNDDIR BNDDIR(CALIB/CABNDDIR)
> or
>     DSPBNDDIR BNDDIR(CALIB/CABNDDIR) OUTPUT(*PRINT)
>
> and study the results, and examine the list of objects in this binding
> directory, to see if someone has somehow added both *MODULEs and *SRVPGMs
> to that binding directory ... (HINT: bad idea)
>
> The message is referring to a *MODULE object. In general, it is a "bad
> practice" to put *MODULEs into a binding directory.
>
> Instead, what you want to do is to bind *MODULEs into a *SRVPGM and then
> add the *SRVPGM into the binding directory.   And, never mix both *MODULEs
> and *SRVPGMs in the same binding directory.  ("There be dragons here.")
> This is very likely the root cause of this error.
>
> If you issue CRTSRVPGM with naming that *MODULE CA8560CT$2 explicitly, it
> would likely dynamically bind to  *SRVPGM object QZDMMDTA, and that would
> resolve the issue(s).
>
> _Summary_
> You should always explicitly name *MODULEs on a CRTPGM or CRTSRVPGM or
> UPDPGM or UPDSRVPGM command, never add them to any *BNDDIR.  Place "shared"
> modules into a single *SRVPGM, and bind to that, either by naming that
> *SRVPGM explicity on the CRTPGM or UPDPGM command, or by using a binding
> directory.
>
> Also, I highly recommend the use of a "make" or "build" tool like Alan
> Campin's COMPILE command, available at http://www.think400.dk/downloa
> ds.htm  -- this allows  you to store the create commands, such as
> CRTxxxMOD, followed by the CRTSRVPGM or CRTPGM commands, directly within
> the source code, as comments.  This way, you never lose those "make"
> instructions, and it makes all subsequent maintenance easier, since you
> just prompt the COMPILE command and point it at the source.  The COMPILE
> command is also designed to be easily integrated with WDSCi or RDi.