RE: Issues after going from TR4 to TR7

+1

Thanks Vern, I was not aware of the parameter declarations on a call.


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Vern Hamberg via MIDRANGE-L
Sent: Saturday, July 29, 2023 8:56 AM
To: midrange-l@xxxxxxxxxxxxxxxxxx
Cc: Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx>
Subject: Re: Issues after going from TR4 to TR7

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.