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



Booth,

Here is a second example where I've basically set up a DS with the same
field names as the file (so it directly refers to the file fields - you
read a record and the DS is populated)

https://code.midrange.com/1b33553e59.html

In order to allow for the same fields to be passed to more than one
subprocedure, I've used separate Data Structures but this time made them
qualified so they don't directly try to "organise" the way the file fields
are stored in memory.
This means that:
1) I had to define the field types / lengths which I did using LIKE
2) I need to move the data from the DS which is linked to the file (CarDS)
to each separate DS using Eval-Corr.

I appreciate this is not particularly elegant, but it's the first way I
thought to do it.

Again, I'd probably ask myself - what is it that I'm actually gaining by
putting these fields on a DS to pass to the subprocedure.
Does it make things cleaner and clearer or am I just creating complication.
If you only need one or two fields in each, would it be clearer to pass
them individually.
If you need many - would it be better just to allow global access.

Up to you :-)

best regards,
Craig

On Sat, 29 Dec 2018 at 11:17, Craig Richards <craig@xxxxxxxxxxxxxxxx> wrote:

Booth,

Here is an illustration of the simplest example where you don't require
the same field to be passed into more than one subprocedure:

*https://code.midrange.com/f20c2783d3.html
<https://code.midrange.com/f20c2783d3.html>*

Nb there is probably a whole other conversation to be had about whether
you should actually pass in exactly the fields your subprocedure(s) need or
whether you allow them just to access the global definitions directly.
That's a very subjective matter although I have my own opinions, I'm not
trying to address that here. Just to help answer your question

regards,
Craig

On Sat, 29 Dec 2018 at 10:41, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Booth

Without a lot more information, I suggest that you try using the
QUALIFIED keyword - then the subfields - what you called "...field names
in the data structures..." - the subfields are not already defined.

HTH
Vern

On 12/29/2018 1:11 AM, Booth Martin wrote:
I have confused myself. Again.

Learning about service programs, prototypes, procedures and stumbling.

I I have a service program with which I wish to offer several
procedures relating to the various fields in a specific file.

Each procedure will have specific data structures dealing with the
fields related to that procedure. I would like to use the same data
structure name in several procedures although the fields will be
different in each data structure. It's not letting me do that. Then,
when I changed the names of the data structures it tells me that the
field names in the data structures are already defined.

So... how do I make data structures and field names that are local to
the procedure in which they reside? Or is that a you'll-be-sorry wish?


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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.