× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Duane,

I'm piecing together information from a few different messages.  I'm doing
this primarily to organize my own thoughts, since the information has been
spread out throughout the day...

>From your original message:

> RPG source#1 is the driving code created as module(using crtrpgmod)
> RPG source#2 is the procedure portion also created as a module
> PGM object was created with CRTPGM listing source#1 and source#2 as
> modules with source#1 being the entry point
>
> To here everything works, I get compiled modules and a pgm object.

Okay, from this description, it sounds like you're doing this:

     CRTRPGMOD SOURCE#1
     CRTRPGMOD SOURCE#2
     CRTPGM PGM(MYPGM) MODULE(SOURCE#1 SOURCE#2) ACTGRP(*NEW)

This means that you're creating one program from two modules.  When your
program starts, it'll create a new activation group, and as soon as your
program ends, that activation group will be automatically destroyed.

I inferred the *NEW from the fact that it's the default option on the
CRTPGM command.

Then you say:
>   Message . . . . :   Cannot resolve to object source#2. Type and
>       Subtype X'0201' Authority X'0000'.

That's very interesting, because if you're using the procedure outlined
above, there's nothing to resolve to for SOURCE#2, since both SOURCE#1 and
SOURCE#2 are in the same program.   So, I'm guessing from this message
that you're not binding the modules together directly, but rather doing
external program calls.

Then, to Scott Mildenberger you say:
>                    ****************************
>   0012.02       * Procedure Prototypes
>   *
>   0012.03       ****************************
>
>   0012.04      d ediprseg        pr
>  extpgm('EDIPRSEG')
>   0012.05      d
[SNIP]

I thought you were working with procedures, but this prototype is
referring to an ExtPgm ("external program") rather than a procedure.
ExtProc() would point to a procedure -- though the ExtProc keyword is only
needed if the procedure name is different from what you've got in
positions 7-21 of the D-spec with the "PR" in it.    Specifying ExtPgm
makes CALLP work just like CALL.

Okay, so now I know what you're doing, but I'm not sure what you're TRYING
to do...

If you're trying to implement this as a dynamic program call, then the
EXTPGM is correct, but the way you're compiling things is wrong.

If you're trying to implement this as a "bind by copy" situation where
more than one module is compiled into the same program, then you need to
omit the EXTPGM on your prototypes.  (I don't recommend this approach if
you plan to use the module in multiple programs, it becomes a maintenance
nightmare quickly.)

If you're trying to implement this as a service program (which is what I'd
recommend since you're re-using the module) then you need to both remove
the EXTPGM and change the way you're compiling it...

As I finish writing this, I see a new e-mail message that says "Resolved"
so I'll stop here...   :)

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.