× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.

I have got news!

It looks like free RPG doesn't support DS subfields with the same name of
file's fields either: it derives the subfield length from the database
field but not the data type.
If a DS is created containing the very same STRNUM and STRNAM names as from
the previous example, then the internal file field's variable is stil
packed(5:0) whereas the DS subfield is zoned(5:0).
So, using DS simply to group fields doesn't seem possible in free RPG

I really like to find where this is described in the RPG Reference book: I
couldn't find it at all.


Il giorno mer 28 dic 2022 alle ore 15:16 Maria Lucia Stoppa <
mlstoppa@xxxxxxxxx> ha scritto:

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;
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
return count;

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



Maria Lucia Stoppa


Maria Lucia Stoppa

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2023 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.