RE: Display file attributes

Doug,

I think you may be correct about the screen compiler.
If I change the display field from 'O'utput  to 'B'oth it works correctly!!!

I don't see any downside other than 78 extra unnecessary characters being
returned to the RPG program as input.

Thanks to all for suggestions and information.

Tim Kredlo


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Douglas Handy
Sent: Thursday, November 04, 2004 11:57 AM
To: Midrange Systems Technical Discussion
Subject: Re: Display file attributes


Tim,

> This is the entire DDS for this format.
> Maybe someone can see something I am missing.

It seems to me that the system incorrectly optimizing out (or rather, not
inserting) a display attribute byte for the end of the MESG78 field.

As you probably know, the 5250 data protocol consumes a display byte for
each display attribute.  Each occurence of a byte in the range x20
- x3F affects all subsequent positions on the dispaly until the next
occurence of another byte in the range x20 - x3F.  Typically you will have
one of those in the byte preceding the start of a field, and at the byte
just after the end of a display field.

However, from years ago when I would study the contents of 5250 data streams
and directly imbed my own data stream commands in my output as a learning
exercise on the S/34, it was apparent the $SFGR compiler under SSP did not
bother to include display attribute bytes when it thought they weren't
necessary.  I think the DDS compiler does the same thing.

Input capable fields always required a display attribute byte preceding the
field, but output only or constant data would only have the display atribute
byte prefix / suffix when an attribute was requested (or conditional) .
Otherwise it just output the text directly starting at the row / col
specified, and included neither a leading or ending display attribute.

In your case, since MESG78 is using DSPATR(&MESG78_A), the DDS compiler
*should* realize an ending display attribute byte should be generated just
beyond the end of the field.  It obviously is doing so when you use
DSPATR(RI BL), but is evidently failing to do so with the DSPATR(&MESG78_A).

I use program fields for display attributes all the time, and have never
seen this.  I don't know why you are seeing it, but if there is not a PTF
for it then I'd say you have two options:

 1)  Increase MESG78 to 79 bytes, and always add a x'20' byte to the end of
your text
 2)  Include another field starting at row 23, column 1.  This should force
a display attribute to row 22, column 80 which is just beyond the end of
MESG78

FWIW, it doesn't appear to me you are doing anything wrong.  But aside from
a PTF fix, you'll just have to force the system into getting an ending
display attribute after the field.

Doug
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.