RE: CL Module Question.

Thank you Simon. Comprehensive and erudite as usual.

I'm now having problems with point 3 of your answer. I've spent about 3 hours 
scanning ILE Concepts manual, MidRange Archive and the iSeries News site. To no 
avail.
How do I invoke a CL procedure from an RPG program? 

There was a hint in one inquiry implying that it should be with a CALLB, and in 
fact the CALLPRC documentation refers to it as a Bound Procedure call so I 
thought I should give that a go. But I crap out on the compilation. Probably 
how I've implemented it. I have this gut feeling that I might need to go to a 
binder source solution, but I've never used those. Probably a good excuse to 
get immersed in them if that's what's required.

The CL module was created ok as ED991CL, so I presume the 'prcedure name' is 
the same as the module name since it's a 1:1 relationship.

I used the CALLB       ED991CL in the RPG(ED002), and compiled it with 
CRTBNDRPG. 
I also created a binding directory ED002 which referenced ED991CL as a *module.

The compile fails with:

*RNF7030 30   1734 116000  The name or indicator ED991CL is not defined. 

Presumably the binding step hasn't resolved to the ED991CL in the CL module. 
Although when I look at the DSPMOD of ED991CL it says there's one exported 
defuned symbol, which I presume is the (implied) procedure name of ED991CL.

Normally with RPG modules, there's an EXPORT statement assigned to the 
procedure names which are to be 'public'. Is the CL procedure public by 
definition since there's only one procedure? Or do I have to use the binder 
language to make it so?

By the way I was intrigued by your definition of CALLP being a CALL with a 
prototype. I'd always thought of it as a CALL of a (P)rocedure. Perhaps they 
should have named the CALLPRC command CALLBNDPRC?

Thanks for your time in guiding me through this.




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Simon Coulter
Sent: Friday, 17 March 2006 5:13 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: CL Module Question.



On 17/03/2006, at 4:06 PM, Mike Pantzopoulos - (H/O) wrote:

> A little while ago I had cause to use the CALLPRC command in a CL
> program. Simon Coulter (bless his little white socks), pointed me in 
> the
> right direction with regards to a variable length parameter set up from
> the CL to the ILE procedure interface. Now I have a CL module and I am
> able to create a program out of it(CRTPGM) or CRTBNDCL directly from 
> the
> module source.
> I'm now curious about the differences between RPG & CL modules.

At the module level their aren't any real differences

> An RPG module may have one or more procedures, but the CL module 
> doesn't
> seem to fit the RPG procedure template - no prototype, no internal
> procedure declarations.

Support for multiple procedures is a compiler thing. RPG IV originally 
supported only 1 procedure per module--which is why we have the current 
rubbish about sub-procedures. At VRM370 RPG was given support for 
multiple procedures.

> So the question is - what can I do with a CL
> module other than create a module? I have to create a module because of
> the reference to CALLPRC, but is there any other intrinsic reason for
> using CL as a module?

I can think of four reasons why you might create a CL module (i.e., use 
CLLE) rather than stick with CLP:
        1) You want to embed a copyright statement in the object via the 
COPYRIGHT command
        2) You want to call another procedure from CL via the CALLPRC command
        3) You want to bind a CL module directly to your RPG/COBOL/C program 
rather than call a program
                - You might do this to:
                        a) reduce the number of shipped objects (1 program vs. 
2 or more)
                        b) reduce the possibility of interposing a different 
program on a 
call
        4) You might want to bind multiple CLLE modules into a single program 
object

> I thought I might be able to reference it from a CALLPRC in another CL,
> but since there's no 'procedure' construct, what else can I do with it?

That's exactly what you can do. Specify multiple CLLE modules on the 
CRTPGM or CRTSRVPGM command and use CALLPRC to jump between them. 
CALLPRC is more like RPG's CALLB than CALLP. For the second time today: 
CALLP means Call with Prototype not Call Procedure. For example:

Source member CLMODULE1:
pgm
sndpgmmsg  'In module 1'
callprc clmodule2
endpgm

Source member CLMODULE2:
pgm
sndpgmmsg  'In module 2'
endpgm

CRTCLMOD CLMODULE1
CRTCLMOD CLMODULE2
CRTPGM CLMODULE MODULE(CLMODULE1 CLMODULE2)
CALL CLMODULE

The job log will contain "In module 1" followed by "In module 2' so you 
know that CALLPRC passed control as expected.

> While I'm at it:
>
> If the entire module is copied into a referencing 
> module/program/service
> program, then there seems to be a propensity to possibly create very
> large programs by the time an executable is created as the tip of a
> possibly very large pyramid of module references.

Only if the modules that are bound by copy are used in multiple 
programs. There is no real difference in object size between 1 program 
with 1 module of 50,000 lines and 1 program with 5 modules of 10,000 
lines each.

Certainly the additional binding information in the program object and 
the module information overhead will increase the size of the resulting 
object but not significantly--especially not when weighed against the 
convenience of smaller source members, separated logic, etc.

> It almost seems as if the best solution is to use a service program in
> almost all instances, regardless of the slight overhead of the initial
> reference.

But the modules are copied into the service program ....

If the module in question is common to 2 or more programs or service 
programs then it should itself be bound into a common service program. 
If the module is only used by one program then just bind it into that 
program.

The number of modules per program should not be a consideration. What 
matters is whether the modules effectively separate logic or function 
such that maintenance is improved. If that means 50 modules in a given 
program then so be it.

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                                   \ /
                                                              X
                  ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------