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



Hi Dave,

You can do the from-to thing. These days the OVERLAY keyword is in vogue, primarily because when you're dealing with data structure subfields of varying lengths, it's easier than calculating the from-to positions. On the other hand, indicators are always 1n, so that's not much of a consideration. On the gripping hand, I still use OVERLAY because I can copy the line of source code and only have to change the position in one place, not two. Either way works just fine.

*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /

Turnidge, Dave wrote:
Now THAT'S what I mean. Thank you! But, I'm not going to let you go just
yet...

     D P_Indicators    S               *   Inz(%ADDR(*IN))

     D Indicators      DS                  Based(P_Indicators)

     D Update_Mode                         Like(*IN)
Overlay(Indicators:01)

Begsr *INZSR;

In the above example the  "Overlay(Indicators:01)" keyword is used. Is
this necessary, or can you do the from and to thing?

D Update_Mode           1        1n

Thank you so much for your historical perspective.

Dave

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Peter Dow (ML)
Sent: Wednesday, December 06, 2006 11:26 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Indicator Redux

Hi Dave,

Maybe a little historical perspective would help.  RPG has always had
just 99 indicators.  At some point, programmers were allowed to access
them as if they were in an array (the *IN array).  After display files
were introduced, they started eating up all the available indicators in
order to position cursors, set display attributes and what not.  Pretty
soon, there weren't enough indicators for both the display file and RPG.

The solution was to allow display files to have their own set of 99
indicators.  This is done by specifying the INDARA keyword in the
display file, and the INDDS keyword on the file spec in the RPG program.
Once you've done this, RPG has its 99 indicators in the *IN array, and
the display file references the 99 indicators in the data structure
specified in the INDDS keyword on the file spec.

Now it is possible to have the display file's indicator data structure
overlay the *IN array, by making the data structure based, and having
its basing pointer point to the beginning of the *IN array.  If you do
this, you're back to one set of 99 indicators, which negates the
intention of having a separate set of indicators.  And it's a waste of
coding time, since you have the same effect by leaving off the INDARA
and INDDS keywords.

The only reason I've ever seen for mapping a data structure to the *IN
array is to allow naming the 99 RPG indicators so you don't have to use
*IN34 or *IN(27), which are not very meaningful.  But you don't need to
use INDARA or INDDS to do this.  Simply define a based data structure
whose pointer points to the address of *IN01.  This data structure does
NOT have to be specified in an INDDS keyword.  You don't even need a
display file.  In other words, you could have a program with an INDARA
display file where INDDS points to data structure ABC, and a separate
based data structure XYZ that overlays the *IN array.  That way you can
name the 99 RPG indicators and the 99 display file indicators.

hth,
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
pdow@xxxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxxx> /



Turnidge, Dave wrote:
This "pointer" thing is new for me, as far as USING it is concerned. If I'm reading your code correctly, you are setting up a data structure over the *IN array. Yes? Where or how does this get related to the INDARR and INDDS? Would I use the *IN pointer method INSTEAD of

INDARR and INDDS, or use both?

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lapeyre, Francis
Sent: Wednesday, December 06, 2006 10:34 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: Indicator Redux

I do it with a pointer, because I often have to condition things on the output specifications. But it will work on display files, as well.

       // Define indicators

     D P_Indicators    S               *   Inz(%ADDR(*IN))

     D Indicators      DS                  Based(P_Indicators)

     D Update_Mode                         Like(*IN)
Overlay(Indicators:01)

Begsr *INZSR; // List or update mode? Update_Mode = (%PARMS > 0 And P_Update = 'Y'); Endsr;
Francis Lapeyre
IS Dept. Programmer/Analyst
Stewart Enterprises, Inc.
E-mail: flapeyre@xxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Turnidge, Dave
Sent: Wednesday, December 6, 2006 10:12 AM
To: RPG programming on the AS400 / iSeries
Subject: Indicator Redux

I have looked through the archives having to do with Indicator Arrays,

and am confused. It appears that there are two arrays(?): one for display file indicators, and one for RPG indicators.

When I started on my current project I was told that I didn't need to use the "pointer method" to define my indicators, but now I am running

into a problem. I have set up variable "ExcludeSys" for position 27 in

my indicator data structure. However, when I turn ExcludeSys *ON, *IN27 is not *ON, and, I WANT it to be on.

Please help me understand the difference (if there is one) and/or how to be able to use a variable name and have the action continue on to the indicator. Also, if there is a page in a Redbook (or equivalent) that explains this from IBM's "easy to understand" viewpoint <G> a link would be nice...

Thank you,

Dave

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



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




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.