Re: Return *on or *off from CLLE module

...I still remember the pain of having to search for and fix the problem a few years back 😄



________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Charles Wilt <charles.wilt@xxxxxxxxx>
Sent: 06 August 2021 14:27
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Return *on or *off from CLLE module

Awesome find Tim!

*ILE CL Call Procedure (CALLPRC) advice for call to RPG now fails*
An ILE CL program that uses a 2-byte character variable to receive a 1-byte
character value from an RPG procedure call may require a change in the CL
source in V6R1 and later releases.

Some versions of the RPG Programmer's Reference prior to V5R1 advised users
to declare a 2-byte character variable and use a substring operation to
receive the 1-byte return value. This method was incorrectly based on undefined
implementation details that have changed in V6R1.

To determine whether you have code that should be changed, you can compile
a list of potentially affected CL source physical file members, examine the
CL source, and make changes as needed. To compile a list of ILE CL source
physical file members and line numbers of Return Value (RTNVAL) uses, the
following command can be used.

Note: This command assumes the ILE CL source is stored in files named
QCLSRC within libraries. QSH CMD('find /QSYS.LIB -name "*.MBR" | grep
"/QCLSRC.FILE/" | xargs grep -Ein "rtnval(\+|\()" > myoutfile.txt')

To display the results file: WRKLNK myoutfile.txt

To determine if the ILE CL source requires a change, examine the listed
source file members. If a 2-byte character value is returned from a call to
an RPG procedure, and only the first character is used by the CL procedure,
the code will no longer run as expected on V6R1 and later releases.

To correct the ILE CL source, change the declare of the character value
being returned to use TYPE(*CHAR) LEN(1). The substring operation is no
longer needed and can be removed.

For CL programs that will only be run on V6R1 and later releases, specify
V6R1M0 or later for the TGTRLS parameter for the compile of the CL module
or program. No change is needed in the RPG source.

If a single version of the CL program must be able to run on multiple
releases that include V6R1 and a previous release, then the source of the
RPG procedure being called also requires a change. Change the RPG source by
adding the EXTPROC(*CL) keyword to the prototype (PR) and procedure
interface (PI). Any RPG programs or modules that call the changed RPG
procedure must be recompiled. An alternative correction that would not
involve recompiling the RPG modules is to create a new "wrapper" procedure
with EXTPROC(*CL). The CL module would be changed to call the new
procedure, which would call through to the original, unchanged RPG
procedure.


Still don't know what the issue was "undefined implementation details" but
it seems to no longer apply.

Not something I recalled reading way back when.

Interesting that the RPG manual wasn't updated to say that
extproc(*CL:name) isn't needed for v6r1 and later.

Charles

On Fri, Aug 6, 2021 at 2:04 AM Tim Fathers <tim@xxxxxxxxxxxxx> wrote:

Maybe this was it? There was a change made to the way this worked back in
6.1, see page 70 here
http://think400.dk/files/Memo%20to%20User%20v.6.1.pdf

Tim.

________________________________
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of
Charles Wilt <charles.wilt@xxxxxxxxx>
Sent: 05 August 2021 17:19
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Return *on or *off from CLLE module

I seem to recall issues with passing char(1) parameters from RPG to CL...

I can't seem to find the details, just solutions
- extproc(*CL:name)
- use two byte parms...

Not sure if this will matter or not in this scenario...

And if somebody could refresh my memory on what the differences are for
char(1) parms between RPG and CL, that'd be nice :)

Charles

On Thu, Aug 5, 2021 at 9:22 AM <smith5646midrange@xxxxxxxxx> wrote:

Thanks for the reply.

This worked but since it took me a while to figure it out using "old
school"
formatting, I thought I would reply back with the code that I used to

test

the concept.

--------------------
Program RTNPARMPGM
d rtnparmcl pr n rtnparm
if rtnparmcl();
dsply 'Success';
else;
dsply 'Failure';
endif;
*inlr = *on;
return;
--------------------
Program RTNPARMCL
PGM PARM(&STATUS)
DCL VAR(&STATUS) TYPE(*LGL)
CHGVAR VAR(&STATUS) VALUE('0')
ENDPGM: ENDPGM
--------------------
I compiled both sources to modules and then executed command CRTPGM
PGM(RTNPARMPGM) MODULE(RTNPARMPGM RTNPARMCL)

When I ran RTNPARMPGM, it properly displays Success or Failure (had to

mod

the CHGVAR in the CL to test both results).

One other fun fact. SEU does not like the keyword RTNPARM but when you
look
at the error message, it says RTNPARM is one of the value values. I

know,

SEU is dead but it is still used in a lot of places so I thought that I
would point out this info because it took me a while to figure out what

was

wrong with it.



-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Niels
Liisberg
Sent: Thursday, August 5, 2021 9:41 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: Return *on or *off from CLLE module

I suggest you create the prototype for the CL where the first parameter

is

the RTNPARM

The you can use it in RPG as a function ( as you describe) but the CL is
just the first parameter you have to set to LGL '1' or '0'

https://www.ibm.com/docs/en/i/7.4?topic=keywords-rtnparm


On Thu, Aug 5, 2021 at 3:24 PM <smith5646midrange@xxxxxxxxx> wrote:

I define a lot of my RPGLE modules with a return type of indicator.
In the module, I return *on for success or *off for failure. If I
need more details from the module, I include fields as part of a parm
list. Then in my code, I can write something like this



If DoesCustomerExist(customerNumber);

// execute code based on customer existing

Else

// execute code based on customer not existing

Endif



Is there a way to return the *on or *off from a CLLE module? RETURN
does not have a parm.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com