Re: BIGINT parameter in SQLRPGLE -- RPG400-L

Paul,

This is a classic problem since SBMJOB always passes all parameters as character strings, if you code a CALL command in the CMD parameter of SBMJOB.

As Birgitta Hauser has suggested, pass all binary or packed values as hexadecimal.

Another option is to write a custom command wrapper for your program, so you would use that "command" instead of the CALL in the CMD parameter of the SBMJOB.

I hope that helps,

Mark S. Waterbury

On Tuesday, June 2, 2020, 9:25:54 AM EDT, Paul Bailey <pablomotte+midrange@xxxxxxxxx> wrote:

Thanks Jon,

There are three problems with my thinking then. I want to pass a BIGINT
into the SQLRPGLE (via SBMJOB) and maintain that value throughout the
various internal procedures.

1) From what you've said if I change the VALUE to CONST in the parameter
definition of my internal procedures then the value of the row ID will be
consistent?
2) The CLLE is using SBMJOB to pass the integer value to the SQLRPGLE, so
how should I change that to make certain the value passed isn't a 5 decimal
place number instead? Passing packed decimals from the command-line/SBMJOB
is a pain to work out, but do I pass an INT(20) that way as well?
3) TYPE(*INT) LEN(8) is the max possible integer size in CLLE, but you tell
me that is only an INT(10) value. Unfortunately, I can't find the site that
told me that was equivalent to INT(20) - maybe I misread it. How would you
store an INT(20) in a CLLE program purely just to pass through SBMJOB?

-Paul.

On Tue, 2 Jun 2020 at 13:40, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Well an INT with a length of 8 should be an Int(10) not 20. So that looks
like a pre-processor bug to me.

However, since the parm is defined as Const it shouldn't matter.

Similarly with VALUE. But when you say "when I pass the value to a
procedure with this parameter" is that a procedure of your design? Because
the value on the stack for a parm passed by value is very different from
that passed as const.

The real problem though is that debug is showing what appears a packed
value with 5 decimal places. That makes it look as if it came from the
command line/submit job and not created and passed internally. Does that
ring any bells?

On Jun 2, 2020, at 7:09 AM, Paul Bailey <PabloMotte+Midrange@xxxxxxxxx>

wrote:

I have an external stored procedure with a BIGINT parameter that calls
a CLLE program, which passes the parameter through SBMJOB to a
SQLRPGLE.

In the procedure, the parameter is defined like this: IN P#IMPORTBATCHID

BIGINT

In the CLLE the parameter is defined like this: DCL
VAR(&ROWID_INT) TYPE(*INT) LEN(8)

In the SQLRPGLE the parameter is defined like this:
p#ImportBatchID INT(20) CONST;

The SQLRPGLE works, using the correct row ID throughout the program,
except when I pass the value to a procedure with this parameter
definition: p#BatchID INT(20) VALUE;

The value passed into the stored procedure in parameter
P#IMPORTBATCHID is 223, but the value in P#BATCHID (from PGMDMP and
debug monitor field) is:

INT(20) 9177137167
VALUE IN HEX '000000022300000F'X

Have I made a mistake in the differing definitions of the field? I
would expect the value displayed in debug to be 223 and the hex value
to be '0000000000000DFF'X.

Any advice would be appreciated.

-Paul.
--