Re: Why a data structure subfield with the same name of a file field does not keep the same data type?

Maria Lucia,

This is my new main body code. The UpdFile proc was not changed. And
again, it compiled with no claim. I also debugged it, and followed all
lines. The first row is read, then the field "numclie" is loaded
correctly, and then I pass it on to the procedure, and all that works
correctly.

ctl-opt dftactgrp(*no) actgrp('MRTST01');
ctl-opt decedit('0.') expropts(*usedecedit: *alwblanknum);

dcl-f maeclie disk usage(*input);

dcl-pi MRTST01;
// no parms
END-PI;

dcl-s a int(10) inz;
dcl-s cnt zoned(5) inz;

a = 1;

read maeclie;

cnt = UpdFile(numclie);

*inlr = *on;

I am at V7R3 still, and I see no other cause of the issue.

Javier.


El mié, 28 dic 2022 a las 9:01, Maria Lucia Stoppa (<mlstoppa@xxxxxxxxx>)
escribió:

Hi Javier,

please, can you try reading a row from file maeclie inthe main section of
your program, then calling the procedure passing the field name?

To me it should work either, but I can't figure out what's wrong with my
code. Missing PTF maybe?

Il giorno mer 28 dic 2022 alle ore 15:48 Javier Sanchez <
javiersanchezbarquero@xxxxxxxxx> ha scritto:

Lucia, I tried to use your code as close as possible with a table of my
own. And I could get the same error, please see below. This is my code:

ctl-opt dftactgrp(*no) actgrp('MRTST01');
ctl-opt decedit('0.') expropts(*usedecedit: *alwblanknum);

dcl-f maeclie disk usage(*input);

dcl-pi MRTST01;
// no parms
END-PI;

dcl-s a int(10) inz;

a = 1;
*inlr = *on;

//*** End of program ***//

dcl-proc UpdFile;
dcl-pi *n zoned(5);
x_numclie like(numclie) value;
END-PI;

dcl-s count zoned(5) inz;
exec sql select count(*) into :count from maeclie
where NUMCLIE = :x_numclie;
return count;
end-proc;

The only reason for getting exactly the same error as you, is because the
table is not in the library list.
I just included it, and it went through!

In this program I used a dummy variable "a" and a dummy instruction
assigning to it a value of 1 just to have the main body do something.

HTH.

Javier.


El mié, 28 dic 2022 a las 7:19, Maria Lucia Stoppa (<mlstoppa@xxxxxxxxx
)
escribió:

Hi all,
I am struggling with a subfield definition issue which I haven't

understood

yet, and it's driving me crazy!

In a program, an update keyed physical file is defined with a packed

(5,

0)

key field.
The file definition is global, like this:
dcl-f tblstr disk usage(*input) keyed;
The program passes that key field plus a second field to a procedure,

and

the procedure uses those fields in an embedded SQL, like this:
dcl-proc UpdFile;
dcl-pi *n zoned(5:0);
x_STRNUM like(STRNUM) value;
x_STRNAM like(STRNAM) value;
end-pi;
dcl-s count zoned(5:0) inz(0);
message = '4-' + %char(x_STRNUM) + %trim(x_STRNAM);
dsply message ' ';
exec sql
select count(*)
into :count
from tblstr
where STRNUM = :x_STRNUM and STRNAM = :x_STRNAM
;
return count;
end-proc;


Well, the program doesn't compile, because both x_STRNUM and x_STRNAM

are

not usable by the SQL statement:
Position 21 Variable X_STRNUM not defined or not usable.
Reason: No declaration for the variable exists,

the

declaration is not within the current scope, or

the

variable does not have an equivalent SQL data

type.

The same for x_STRNAM.

When the SQL 'where' clause is commented, the program compiles and it
works, meaning the 'dsply' operation code is correctly executed.

I tried different options, like adding value to the parameters passed

and

casting the rpg variables used within the SQL statement, but I can't

get

rid of the issue.

The idea I get from all the tries is that file's fields used to define

the

input parameters of the procedure are not recognized by SQL, so the
variables inside the procedure are for some reason unusable.

What am I missing? Does any of you have any idea about it?

Any hint or suggestion is greatly appreciated as converting fixed RPG
programs to free format includes many of these situation.

Thanks!
Lucia

--

Maria Lucia Stoppa
mlstoppa@xxxxxxxxx
--
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

--

Maria Lucia Stoppa
mlstoppa@xxxxxxxxx
--
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