< My question: Is it possible to truely mimic attrubute manipulation without 
using indicators? >  Yes, those program-to-system fields you say were 
a "nightmare".

Program-to-system fields aren't too bad.  Here is a different technique to 
consider:

 ** Display field names
D FldNames    DS   
d                               10a   Inz('C1NAME')
d                               10a   Inz('C1ADR1')
d                               10a   Inz('C1ADR2')
d                               10a   Inz('C1CITY')

 ** Display attributes for display fields
 ** (Field names match the names used in the DDS for the program
 ** to system fields and must be in the same order as the field 
 ** names in the FldNames DS)
D DspAtrs     DS
d  DaName
d  DaAddr1
d  DaAddr2
d  DaCity

Now you can easily set an attribute by a a position (or array element) by 
looking up the field name in FldNames.  The program can easily set any 
attribute based on the field name.  We've used this technique for field-level 
security and when we are validating entries we can easily change the attribute 
to Red Reverse Image.  A simple procedure can be called passing it the display 
field name and the attribute and the procedure will load the correct program-to-
system field in DspAtrs DS.

<Position cursor?> Yes.  This is even easier than attributes. Use the DDS 
CSRLOC keyword.  This requires you to load the Row + Column location.  I have 
discussed the APIs needed and basic logic required to write an external ILE 
procedure to retrieve this information for a Display File + Record Format + 
Field Name.  My procedure will return the Row and Column for a field in my 
display file.  If fields are moved around by a maintenance program it continues 
to work.

Adding to the confusion :)

We have been asked to begin converting our 24X80 displays to 27X132. More real-
estate good right? Putting three times as much data on a screen with editing 
and validation rules mean you run out of raw indicators pretty darn fast. We 
tried program to field once before and it was a maintanence nightmare 
especially when the user wanted to move things around. This approach isn't 
going to work for us. 

My question: Is it possible to truely mimic attrubute manipulation without 
using indicators? Position cursor? Reverse image?

@neilrh 
This will be very good, I see the value in this. 

@DaleB
This made it crystal clear.

I think I more less understand the basics of indicators with display files =)
Now to make them _do_ what I need...

Neil wrote: 
"Then instead of having instances of *in95 in the program, I can instead use:"

Let's be clear. It's not "I can instead use," it's "I must instead use."

INDDS breaks the connection between the file and *IN. The INDDS DS becomes the
only way of passing indicators to and from the file.

No within the Display file you're still using normal numeric like you always 
have.  INDARA tells the display file that indicators are not part of the 
display file record format I/O buffer, but treated as a separate bank of 99 
indicators always sent and received from the display.

An RPG compile over a display file that does not use INDARA looks like this:
I000000   OUTPUT FIELDS FOR RECORD HEAD1 FILE MYDSPF FORMAT HEAD1.
I000001                            *IN95      1  CHAR    1
I000002                            PGMNAM    11  CHAR   10
I000003                            MONTH     20  CHAR    9
I000004                            BEGDT     26  ZONE  6,0
I000005                            ENDDT     32  ZONE  6,0

You'll notice the *IN95 listed in the I/O buffer here.  Were you to specify 
INDARA this entry in the I/O buffer goes away and the entire *in array is 
always passed to the display file regardless of which indicators you use.  
Obviously there is overhead here, since you're sending 98 indicators that 
aren't needed.

In the program you can now use...
fmydspf    cf  ....etc
f                                         indds(mydspfind)

d mydspfind     ds
d  ErrorDates                      1n   overlay(mydspfind:95)

Then instead of having instances of *in95 in the program, I can instead use:
if DatesAreBad;
  ErrorDates = *on;
endif;

neilrh wrote:
"using INDARA (dspf) and INDDS (rpg) will allow you 
to "name" the indicators used in the RPG"

How does this work?
Will they be named on both sides? I understand within the DSPSRC I am limited to
numeric indicators but under INDARA can the names carry over so it's self
commenting?

Something like:
INDARA //in the DSPF
bob(55, 'Bobs magic number')

INDDS
a declaration for bob as 55

Or is this like PLISTS where I need to match argument for argument?

PDNSFL = Pull Down Menu subfile, I think.

SFL = subfile record format
WINDOW = window record format
PULDWN = pull-down menu
MNUBAR = menu bar
SFLMSG = message subfile
WDWSFL = window subfile
USRDFN = user defined...used for 5250 data streams
PDNSFL = ?

Thank you every one this is very useful.  

I'm a bit stumped by the nine record types presented by the screen display...
I'll start a new thread if I have a specific question but does anyone have an
online resource that explains: RECORD, SFL, WINDOW, PULDWN, MNUBAR, USRDFN,
SFLMSG, WDWSFL, PDNSFL?

Really I'm just using RECORD SFL right now so those are taken care of but some
of the others sound strange... like PULDWN.

Thank you every one this is very useful.  

I'm a bit stumped by the nine record types presented by the screen display...
I'll start a new thread if I have a specific question but does anyone have an
online resource that explains: RECORD, SFL, WINDOW, PULDWN, MNUBAR, USRDFN,
SFLMSG, WDWSFL, PDNSFL?

Really I'm just using RECORD SFL right now so those are taken care of but some
of the others sound strange... like PULDWN.

To affect display atributes for fields without using indicators, you can code 
a program to system field (type P) with the hex value of the attribute that 
you want.  For example:

     A          R DRECMNT
     A            ATRMNT         1   P
     A            ATRDPO         1   P 
     A            XMVCUS    R        B 10 24REFFLD(ACVCUS) DSPATR(&ATRMNT)
     A            XMSHDY    R        B 18 24REFFLD(ACSHDY) DSPATR(&ATRMNT)
     A            XMDPO     R        B 15 24REFFLD(ACDPO)  DSPATR(&ATRDPO)

If you set ATRMNT to x'24' and ATRDPO to x'3A', then XMVCUS and XMSHDY will be 
green and underlined and XMDPO will be blue.

I was thinking of changing my name to "n" just to be trendy :)

Neil,

RDi is now going to be named RDp. Will the name changes will never stop?

I think they renamed RDi to something new.

The same is true for RLU (and has been for a while).  I think the SDA stuff 
has just started now with the new version 6.1 ?  

Anyway, I find it faster to make my screen or report using SDA & RLU first and 
then edit the source code ONLY as necessary to put in the "extras".

What's the new thing we're supposed to be using?  Websphere?  Or Rational?  Is 
there a such thing as Rational?  Or is it just Websphere renamed?  I've heard 
too many rumors.  Does IBM have a page on its website where it tells us what 
we should be using/learning to do DB2 programming these days?

Beware of SDA - it does not support the newest functionality available in 
DSPFs, specifically most of the date/time field attributes and such.

Quaternion,  I have been on here for 2 and a half years and have learned a 
bunch.  Display files are old hat to me now.  Would be glad to answer any 
specific questions as you put together your display file - to take some of the 
load off of Neil and others in here.

Are you using SDA to design it ?

You can eliminate the indicators from feedback function - command keys, etc - 
by using the AID in the File I/O Feedback (INFDS).

Actual conditioning of field attributes is a little more difficult, while you 
can load control bytes into output fields for color, underline, blinking and 
such, this means you need to make an output field with a leading character 
space for the activate condition character byte and maybe a trailing character 
space to load the reset character byte.

However sometimes you just cannot get away from using indicators in a display 
file (or coding around them is just too unmanagable - don't forget future 
maintenance), in which case using INDARA (dspf) and INDDS (rpg) will allow you 
to "name" the indicators used in the RPG, while still being limited to numeric 
indicators in the Display File.

Generally speaking, you can't completely avoid using indicators when defining a 
display file.

I'm just starting to edit a DSPSRC file.  I thought it was just a template but
now see that it defines the fields as well as makes use of them and is
conditioned by indicators...

Question 1, how to I avoid the use of indicators and use DSPF? 

It might not be possible but I've seen a lot of keywords which if I'm not
mistaken should be able to reduce some need for indicators... if so what ones
are most useful?

Perhaps I can see the need to condition some lines for inculsion or exclusion
but at this time I just want to use the DSPF as a template, nothing really
conditional.