Prototype CL subprocedure in a service program

[allthom]

Hello everyone, perhaps a stupid question, more about style than strictly technical, but which sparked a discussion in my working group. In short: how do you build the prototype for a cl subprocedure within a service program to make it callable with a meaningful name?
In our environment we have the rule of giving meaningful names to the subprocedures that we call, so for example the subp that is responsible for writing a new record in the CUSTOMERS db table will be called CreateNewCustomer and will be callable by the interested programs with a statement of the type
CustomerCode=CreateNewCustomer(SomeParms);

and this is because the procedure was declared with something like:

Code: Select all

DCL‑PR CreateNewCustomer int(10) EXTPROC('CreateNewCustomer');
    SomeParms LikeDS(ParmsDS);
END‑PR;

Now I'm working on a service program that takes care of producing logs and which will be used by other programs to log their activity.
A sort of log4j but much simpler and lighter.
Some of the subprocedures should reside in cl sources.
For example, when a new log needs to be created for a job, there is a cl module that takes care of creating a new log file and giving the overdubfile command for subsequent writings of the log file of a certain job.
Until now, CLP objects were external programs to be called with the normal call.
I would like to make them modules and be able to recall them with something like

CreateNewLog(SomeParms);

instead of:

Callp CLOGS(someParms);

But how should I write the prototype of a cl subprocedure?

[vhamberg]

Every CLLE module has exactly one procedure, named the same as the module name. I have never done this but have to think that dcl-pr would include EXTPROC with the name of the module (same as its procedure) in it.

When you create a CLLE module, do a DSPMOD and look at what its procedure exports are - you would treat those the same as any other service program.

The service program that exports the procedure has to be bound to your program in the same way as other service programs are.

I hope this makes sense and is even correct!

Cheers
Vern

[Scott Klement]

Every CLLE module has exactly one procedure, named the same as the module name. I have never done this but have to think that dcl-pr would include EXTPROC with the name of the module (same as its procedure) in it.

Yes, if you use EXTPROC it should be the same as the module name for a CL (or Cobol) procedure. It's limited to 10 characters, et al, the same as the module name.

Note that if you aren't "renaming" it, and don't have variables that need to be converted to CL's calling conventions, the ExtProc may not be necessary...

For example:

Code: Select all

Dcl-Proc CRTCUST ExtProc('CRTCUST');
...parms...
End-Proc

Is identical to:

Code: Select all

Dcl-Proc CRTCUST;
...parms...
End-Proc

They do the precise same thing, they call a procedure named CRTCUST.

I'm mentioning this because I've seen a lot of people get confused and say "my call is to an external procedure, therefore must use ExtProc" -- that's not true at all. ExtProc has nothing to do with whether the procedure is in the same module or outside of it. ExtProc just gives a different name for the procedure, or the calling convention (such as *CL, *CWIDEN, *CNOWIDEN)

However, if you want to give it a nicer name in your RPG program (Even though it won't be using it in the CL code or anywhere else under the covers) ExtProc might be a way to do that.

Code: Select all

Dcl-Proc CreateNewCustomer ExtProc('CRTCUST');
...parms...
End-Proc

When you create a CLLE module, do a DSPMOD and look at what its procedure exports are - you would treat those the same as any other service program.

I don't see why you'd do that.. it'll be the same as the module name... what's the point? (This is also true in Cobol and was true in RPG back in V3R6 and earlier. For this reason I really don't do many procedures in CL. I tend to use RPG or C/C++ instead. If something is really significantly easier in CL than other places, I might use a program call or even make a CL command. Making it a procedure works fine, but doesn't really provide much benefit.