Re: Using the same conditioning indicator

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.