Re: create a COBOL ILE module with exportable procedures

Hi, Thomas,

I think ILE "signatures" has more to do with *SRVPGMs, e.g. to detect at runtime that changes were made, where someone has added additional procedures, etc., such that any ILE *PGMs that bind to this *SRVPGM would potentially need to be changed and recompiled, or at least, re-bound.

I do not think ILE signatures come into play when dealing with individual *MODULEs.    

So, it's all about using the binder language to decide what procedures to export, and in what order or sequence to export those procedure names.

I hope that helps,

Mark S. Waterbury






On Saturday, April 8, 2023 at 09:36:43 PM EDT, Thomas Burrows <thomas.burrows.1957@xxxxxxxxx> wrote:





Mark:

Could you explain more about binding language and how to use the signatures
with one one procedure per *MODULE.

Thomas Burrows

On Sat, Apr 8, 2023 at 8:16 PM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Jay,

The ILE COBOL approach to doing this is very different from RPG IV, due in
large part to IBM's attempt to conform closely to the ANSI and ISO
standards for COBOL.

Study this manual:

https://www.ibm.com/docs/en/i/7.3?topic=guide-pdf-file-ile-cobol-programmers


Study the diagram on page 38.

The easiest and simplest way is to just create one procedure per *MODULE,
then add them to a binding directory and bind them as needed to create your
*PGMs or *SRVPGMs.

After that it gets more complex; one example is, a single source member
may contain "nested COBOL programs".  :-o  Even worse, in my opinion, a
single source member can contain one or more "non-nested programs" in which
case a CRTCBLMOD command will actually generate multiple *MODULEs.  :-/
I am not sure what happens if you use CRTBNDCBL on such a source member.
:-(

Look again carefully at that diagram on page 38 ... and see if you can
wrap your mind around this concept of "nested programs"... :-o

My personal advice is to just stick with one procedure per *MODULE and use
binding directories and binder language to deal with it.

Good luck.

All the best,

Mark S. Waterbury

On Saturday, April 8, 2023 at 08:46:46 PM EDT, Jay Vaughn <

jeffersonvaughn@xxxxxxxxx> wrote:

I do this all the time in RPGLE.
A *module with *nomain, and many exportable procedures that can be compiled
into a *srvpgm.

How and what is the syntax to do this same concept with COBOL?

Does anyone have any examples?

google turned up nothing... the IBM i COBOL ILE guide is ok, but no real
examples on how to do this.

All I would need to see is the code to the module source with at least 2
different exportable procedures in it.  From there I'm sure I can figure
out the rest on how to compile to *srvpgm and be called by other ILE
languages.

tia

Jay
--
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
(COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/cobol400-l.



    *
    *
    *
    *

________________________________






On Saturday, April 8, 2023 at 08:46:46 PM EDT, Jay Vaughn <
jeffersonvaughn@xxxxxxxxx> wrote:





I do this all the time in RPGLE.
A *module with *nomain, and many exportable procedures that can be compiled
into a *srvpgm.

How and what is the syntax to do this same concept with COBOL?

Does anyone have any examples?

google turned up nothing... the IBM i COBOL ILE guide is ok, but no real
examples on how to do this.

All I would need to see is the code to the module source with at least 2
different exportable procedures in it.  From there I'm sure I can figure
out the rest on how to compile to *srvpgm and be called by other ILE
languages.

tia

Jay
--
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
(COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/cobol400-l.

--
This is the COBOL Programming on the IBM i (AS/400 and iSeries)
(COBOL400-L) mailing list
To post a message email: COBOL400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/cobol400-l.