Thanks everyone. In the end I converted the *INT(8) CLLE parameter into a
*CHAR(20) value, then passed that to the SQLRPGLE where I converted it back
to INT(20). I was aware that CLLE only handles 15,5 decimal numbers on the
command-line but it hadn't occurred to me that was what I was seeing in the
debug information - sorry for any time wasted.
-Paul.
On 02/06/2020 15:30, Jon Paris wrote:
If you want to do it as a submitted job you'd need either a shell
program to take the default 15,5 packed that will result and move it
to an Int(10) before doing the call - or you may be able to use a
command interface. Have never tried to use one of those to supply an
int so I don't know if that is doable.
When I said Int(10) I was talking RPG definitions and that is a 4
byte integer. So the CL equivalent would be Len(4).
On Jun 2, 2020, at 9:24 AM, Paul Bailey
<PabloMotte+Midrange@xxxxxxxxx> <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>
<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> <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.
--
midrange.com
