× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.