Re: Named constants in DCL-S

Thanks Barbara,

I have to say that is a little unexpected behavior. If the DCL-F is earlier
in the source than the DCL-S with a %LEN that might reference a field from
it then I would expect that to work. I've added a data structure (using
LIKEREC), and used that in the LIKE in my example, and now the code
compiles just fine.

Thanks for your help.

-Paul.


On Tue, 23 Apr 2019 at 17:38, Barbara Morris <bmorris@xxxxxxxxxx> wrote:

On 2019-04-23 12:06 PM, Paul Bailey wrote:

Thanks Barbara.

The field CURR_1 in my example is defined by a file. (There is a DCL-F
earlier in the source). The RDi outline finds the definition fine, but

the

resulting spooled file from the compile has the correct definition for
CURR_1 in an I-spec further down the source. Are DCL-F definitions done
after the DCL-C and/or DCL-S definitions? If so, is the only way I can
declare a zoned version of a packed file field to hard-code the field
definition?

The fields associated with files are defined by the generated I specs,
so that would be too late for your definitions.

You could define an unnamed (or named) externally-described data
structure to get the fields available earlier:

dcl-ds *n extname('MYFILE') end-ds;

--
Barbara

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com