Re: Issues after going from TR4 to TR7 -- MIDRANGE-L

I agree sometimes a command can be the right solution but this one is also
easy and helpful:

Dcl-pi *n;
v char(10);
n1 packed(15:5);
dt date;
End-Pi;

Monitor;
if v = *blanks and
n1 = 0 and
dt = %date();
// Do nothing
EndIf;
on-error;
snd-msg 'Parm 1: A valid id on price list'
%target(*caller:1);
snd-msg 'Parm 2: A price or 0'
%target(*caller:1);
snd-msg 'Parm 3: Valid untill (*ISO date)'
%target(*caller:1);
snd-msg 'CALL PGM(TST0036) PARM('
+'('''' (*CHAR 10)) '
+'(1,1 (*DEC 15 5)) '
+'(''2023-01-01'' (*CHAR 10))'
+')' %target(*caller:1);
*inlr = *on;
return;
EndMon;

dsply ('Parm 1 char 10: [' + v + ']');
dsply ('Parm 2 packed 15,5: [' + %char(n1) + ']');
dsply ('Parm 3 date: [' + %char(dt) + ']');

*inlr = *on;
return;

In case you pass a wrong value:

CALL PGM(TST0036)
PARM(('Parm Too long' (*CHAR 10))
(1234,1234567 (*DEC 15 5)) ('2023-01-01' (*CHAR 10)))

you get:

CPD08A4 Parameter 0001 value does not match parameter type and length.

HTH
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco

Il giorno sab 29 lug 2023 alle ore 14:55 Vern Hamberg via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> ha scritto:

Hi Roger

You describe precisely what we need to do if we do *not* use a command -
and I must admit that sometimes I still don't take the time to write a
command, can't say why.

You make the point about a character in position *length plus 1* - this
is how one gets the full length and still have a useful test value. The
reason for the terminator is, IIRC, that trailing blanks in SBMJOB CMD()
or on a command line are stripped, and everything after the characters
you *do* enter is whatever is in memory. Also, if you do as the CL
manual and Stephen describe, you might not have valid test values.

An example is in order - if the program parameter for an IFS path is 256
long, and if you specify '/home/usrdp2/somefile.txt', you will get a big
surprise, usually. So you will get the next 7 characters as blanks,
because you are guaranteed up to 32, but the rest is who-knows-what.
Putting anything in position 257 makes sure that you are reserving the
full length of the parameter in memory. In my experience, this
terminator does not become the 1st character of the next parameter.

And this is why commands are the thing to use - the size of command
parameters is guaranteed to be reserved in memory. So you can have test
values that are sensible.

The details are in the *CL Overview and Concepts* manual, in the
*Controlling flow and communicating between programs and procedures*
section. https://www.ibm.com/docs/en/ssw_ibm_i_75/pdf/rbam6pdf.pdf

*NOW FOR SOMETHING COMPLETELY DIFFERENT!*

Sorry for the shouting, but this is a /_*BIG DEAL*_/!
In the 7.4 (and better explained in the 7.5 manual) is something new
with CL - we can include data type and length in literal parameters on a
CALL. It says that the call has to be in a compiled ILE CL program. I
took a shot at doing it from a command line, and it works there, too.
Maybe QCMD is ILE? Here's what the manual says, page 290 at the link above
-

*Passing parameters with type and length specified explicitly*
For a Call (CALL) command or a Call Bound Procedure (CALLPRC)
command that is issued from a compiled ILE CL procedure, you can
specify type and length explicitly for constant or expression
parameters to tell how the parameters are passed to the called program.

This is the program - which itself was OPM -

pgm parm(&char100 &dec5p2)

dcl &char100 *char 100
dcl &dec5p2 *dec (5 2)

endpgm

Anyhow, here's the command I entered -

call call_lits (('this is too short' (*char 100)) (24 (*dec 5 2)))

Without the type and length, here is the first parameter -

EVAL &char100
&CHAR100 =
....5...10...15...20...25...30...35...40...45...50...55...60
1 'this is too short █ '
61 ' '

The blob there is actually X'24' from the 2nd parameter, which is passed
as packed 15,5 for literals.

With the type and length, here is how the parameters look in debug, hex
and alpha -

> EVAL &char100 :x
00000 A38889A2 4089A240 A3969640 A2889699 - this is too
shor
00010 A3404040 40404040 40404040 40404040 - t
00020 40404040 40404040 40404040 40404040 -
00030 40404040 40404040 40404040 40404040 -
00040 40404040 40404040 40404040 40404040 -
00050 40404040 40404040 40404040 40404040 -
00060 40404040 ........ ........ ........ -
............
> EVAL &dec5p2 :x
00000 02400F.. ........ ........ ........ - .
..............

This is awesome!

On 7/29/2023 12:02 AM, Roger Harman wrote:

Creating commands to do this takes away all the issues. Makes life a

whole lot easier.

You eliminate the numeric padding issue, the stupid workaround of adding

a terminating character - like a "." in position 51 of a dummy field when
you want to pass a 50-character field. All those shenanigans just
disappear.

User defined commands are the unsung heroes in CL. I always wished

there was a direct interface with RPG to invoke them.

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power

-----Original Message-----
From: MIDRANGE-L<midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of

Jim Oberholtzer

Sent: Friday, July 28, 2023 5:13 PM
To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Issues after going from TR4 to TR7

That will work, but creating the command is so easy why not make it

simple?

On Fri, Jul 28, 2023 at 7:01 PM Stephen Landess<

steve_landess@xxxxxxxxxxx>

wrote:

I was taught to just pass the parms as character and then convert the
character values to numeric in the RPG program.

JDE has a standard subroutine called C0012 which does that conversion

that

and passes back the numeric value.

Note that /any/ parameter which is longer than 32 positions must be

passed

with the exact length of the defined parm. Otherwise it will screw up

the

remaining parameter values and you'll get unpredictable results.

- SJL

-----Original Message-----
From: MIDRANGE-L<midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Mark Waterbury
Sent: Friday, July 28, 2023 4:13 PM
To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxxxxxxxx

Subject: Re: Issues after going from TR4 to TR7

Dave,

Passing parameters as literal values on a SBMJOB has the same issues and
problems as doing a CALL from a command line... it uses the CL CALL

command

... :-o

Just search the archives for problems with passing parameters and

SBMJOB.

The "best simple" solution is to write a "command" definition wrapper

for

this call.

Hope that helps,

Mark S. Waterbury

On Friday, July 28, 2023 at 05:03:33 PM EDT, Dave Begley <

dave.begley@xxxxxxxxxxxxxxx> wrote:

A CL program submits DGL150R. So it is a batch CL program that is

calling

an RPG program.

Dave Begley | IT Manager
HealthSmart | Benefits Management, LLC
Dave.begley@xxxxxxxxxxxxxxx |http://www.healthsmart.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 contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
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
athttps://archive.midrange.com/midrange-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--

--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
--
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
athttps://archive.midrange.com/midrange-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

--
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.