Welcome the P-Field:

P-fields are one-byte codes that control the color and attributes of a field in a display file. Before P-fields were added to data description specifications (DDS), it was necessary for a programmer to make decisions about color and attributes during development. Whichever attributes were selected had to be included in the DDS. To apply different attributes to a field in different circumstances required the use of conditioning indicators.
In the following example, the NAME field is shown in blue. ADDRESS appears in white and will be underlined if indicator 11 is on. The color and attributes of the PHONE field depend on the setting of indicators 12, 13, 15, and 16.
A NAME 20A O 10 6COLOR(BLU)
A ADDRESS 20A O 11 6COLOR(WHT)
A 11 DSPATR(UL)
A PHONE 12A O 12 6
A N15N16 COLOR(BLU)
A N15 16 COLOR(RED)
A 15N16 COLOR(PNK)
A 15 16 COLOR(WHT)
A 12 DSPATR(RI)
A 13 DSPATR(UL)
It works, but it's hardly any fun.
P-fields allows to determine color and attributes at run time without using indicators. Load a P-field with a character in one of two ranges--hexadecimal 20 through 3F or hexadecimal A0 through BF--and the system takes care of the rest. These hex values and their meanings are listed under the discussion of the DSPATR keyword in the DDS reference. Notice that P-fields can't be used for attributes MDT (modified data tag), OID (operator identification), PC (position cursor), and SP (select by light pen).
In the following display file fragment, the NAME field's attributes are controlled by the value in the NAMEATTR field.
A NAME 20A B 10 6DSPATR(&NAMEATTR)
A NAMEATTR 1A P
Notice the usage entry of P for the NAMEATTR field. This tells the system that NAMEATTR is a P-field.
One way an RPG program might load a value into a P-field is by assigning a hexadecimal literal, like this:
nameattr = x'28';
The hex 28 value causes the field to blink on a dumb terminal and to be displayed in red on a not-quite-so-dumb terminal. That's not obvious enough. The source code will be more readable if we assign a named constant to the P-field, like this:
D Blink C Const(x'28')

NameAttr = Blink;
But the P-field value does not have to be hard-coded in the program's source code. It could be stored in a file or data area, passed into a program through a parameter, assigned a value according to user input, and so on.
P-fields are a superior alternative to indicators. Using P-fields with named constants that represent display attributes results in clearer code. P-fields can be stored in external objects like files and data areas or passed to a program through parameters.
However, that does not mean we should use P-fields only. Having to create a P-field for every data field on a display can get unwieldy. If a field always has a certain color or display attribute (it's always underlined, for example), it may not be worth the trouble to use a P-field. But for those times when you need more flexibility, P-fields are the way to go.