Re: Using the same conditioning indicator

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

I don't agree that they are "very nice" -- but sometimes they are easier 
than trying to rewrite a program that was poorly written to begin with.

IMHO, coding 5250 attribute codes directly in your application is not 
very nice, because:

1) It's harder to understand when another programmer looks at your code.

2) How things are to be displayed is the DSPF's job, not the RPG code's 
job. The purpose of a DSPF is to provide a level of abstraction so that 
5250 details are not required in the RPG program.

3) It usually involves forcing display logic to exist in the middle of 
your business logic, which will make things harder if you ever decide to 
update to a more modern display than 5250.

It's just my opinion, though... but if you use meaningful indicator 
names on the RPG side, your code is easy enough to understand without 
resorting to hard-coding 5250 attribute codes in your program. (Which is 
what the hex values you put in the P-fields are, they are the 5250 
attribute codes specified in the 5250 protocol.)

Cursor position is not actually a display attribute (despite the IBM 
kludge of making DSPATR(PC) move the cursor.)  Under the covers, when 
you use DSPATR(PC), it does not send an attribute code to the 5250 
terminal, but instead, it sends a move cursor order.

You can generate your own move cursor order using the CSRLOC DDS 
keyword. Like DSPATR w/P-fields, this means your program has to know a 
bit about your display file, so much like the DSPATR P-fields, I don't 
like this technique.   But, it's possible.

-SK


On 9/28/2012 9:38 AM, Anderson, Kurt wrote:
> Those are very nice.  I recall wishing program-to-system fields could
> control position cursor as well.   Though hopefully the use of these
> fields will help the OP out.