Re: iNext Revealed As IBM i 7.3

On 2/24/2016 2:24 PM, Steve Richter wrote:

but I meant being able to code procedures in the CL module itself. And
export those procedures. I use SUBR but I need to be able to pass parms to
the subroutine.

QCLSRC PROC1
pgm (&input &output)

dcl &input *char 128
dcl &output *char 128


chgvar &output %lower(&input)

endpgm

QCLSRC PROC2
pgm

dcl &string *char 126
dcl &result *char 126

chgvar &string 'NOW IS THE TIME, AM I RIGHT?'
callprc proc1 (&string &result)

dmpclpgm

endpgm

CRTCLMOD MODULE(BUCK/PROC1) SRCFILE(BUCK/QCLSRC) DBGVIEW(*LIST)
CRTCLMOD MODULE(BUCK/PROC2) SRCFILE(BUCK/QCLSRC) DBGVIEW(*LIST)
CRTPGM PGM(BUCK/PROC) MODULE(BUCK/PROC1 BUCK/PROC2) ENTMOD(BUCK/PROC2)
ACTGRP(QILE)
call proc

right, the CL module can be bound and called from another ILE module.

As demonstrated, one can call a CL proc too.

SQL supported In CL.

Like RUNSQL? Or do you mean that you want CL to become a full HLL with
complete database I/O capabilities? Have you tried ReXX or Python for

that?

use SQL just like it is used in RPG. With substitution variables. And
return variables.

Ah. Is this so you don't have to have the RPG compiler?

I pass an SQL statement to an RPG procedure from CL.
But that is too time consuming to write the code to build the SQL statement.

Not following the point; the SQL statement needs to be built at some
point, right?

I understand CL has its domain that it operates in. RPG has its domain. And
SQL procedures also is a domain. Would be good to have all 3 as equal ILE
languages. I am duplicating too much code between SQL procedures and ILE
RPG. Same with CL. Often times I want to call an RPG procedure from CL but
I cannot because the RPG proc has a parm that is varying and CL does not
support such a data type.

An interesting problem.

QRPGLESRC PROC3
ctl-opt option(*srcstmt: *nodebugio: *nounref)
debug;

dcl-pr proc3 int(10);
input varchar(128);
end-pr;

dcl-proc proc3vary export;
dcl-pi *n int(10);
input varchar(128);
end-pi;

dcl-s length int(10);

length = %len(input);
return length;
*inlr = *on;

end-proc;

QCLSRC PROC2
pgm

dcl &string *char 126
dcl &result *char 126
dcl &varystring *char 128
dcl &len *int 4
dcl &bin *char 4

chgvar &string 'NOW IS THE TIME, AM I RIGHT?'
callprc proc1 (&string &result)

chgvar &len %checkr(' ' &string)
chgvar %bin(&bin) &len
chgvar &varystring (&bin *cat &string)
callprc proc3vary (&varystring &len)

dmpclpgm

endpgm

CRTRPGMOD MODULE(BUCK/PROC3) SRCFILE(BUCK/QRPGLESRC) DBGVIEW(*LIST)
dltpgm proc
CRTCLMOD MODULE(BUCK/PROC2) SRCFILE(BUCK/QCLSRC) DBGVIEW(*LIST)
CRTPGM PGM(BUCK/PROC) MODULE(BUCK/PROC1 BUCK/PROC2 BUCK/PROC3)
ENTMOD(BUCK/PROC2) ACTGRP(QILE)
call proc

This works as expected.

My preferred way to interact with CL is to implement 'functions' as
commands, but it looks like I could also consume them as sub-procedures.