Re: Display Screen problem

Bill,

>So why did IBM design this in such a way that other
>functionality could not be utilized when you use ERRMSG or ERRMSGID
>functions?

Because in the days when the 5250 protocol was designed, minimizing the number
of bytes sent was a primary consideration in speed.  (In those days, a 2400bps
modem was very fast.)  So there was a single display buffer with "display
attribute bytes" to control stuff like highlight and blink on subsequent display
positions rather than having two buffers (one with the character per posision,
and one with the attribute per position).

The idea was that for line of business applications, you'd only need to control
attributes at the field level, and it would eliminate the need for larger
buffers in the WS controllers and reduce communication byte counts.

But that also meant there was a limited number of "characters" which could be
reserved as "attribute" bytes.  It was decided that any character with the
binary bit pattern 001x xxxx would be an attribute byte (i.e., x20 to x3F).
This let them handle any combination of 5 attributes: column separators, blink,
underline, highlight, and reverse image. Each of the last 5 bits determined a
specific attribute. (xxx1 xxxx was column separators, xxxx 1xxx was blink, etc)

It didn't allow for anything else.  So non-display was defined as the
combination of underline, high intensity, and reverse image.  That's why if you
set on that particular combination, the field disappears. :(

Years later, color was invented. <g>  But the 5250 protocol still only gave them
the same 5 bits to work with for display attributes.  And they needed to keep
both underline and reverse image, which effectively reduced them to 3 bits to
work with.  So they sat down and mapped specific combinations of attributes to
colors in an attempt to make the same display file look good on both monochrome
and color displays.  So high intensity became white, etc.  They couldn't afford
to keep a bit to mean blink, so they decided if you had it blink before for
attention, they'd go with red for the color. For the most part, I think they did
an admirable job considering the constraints they had to work with.  (Three bits
is not a lot...)

I seem to recall there actually is a combination which will be both red and
blinking, but I forget what it is.  It will be 001x 1xxx with some other bits on
though, probably some combination of the xxxx x1x1 bits.

The 400 has had to maintain compatibility with the 5250 protocol.  The protocol
has since been enhanced with things like "extended attributes" which do let you
control attributes at the byte (not field) level, and obtain combinations not
possible with x20-x3F.  But not all controllers support it, and more to the
point, not all emulators, telnet programs, etc would support it.  This may have
something to do with why DDS was never enhanced to enable all the features added
to the 5250 protocol itself.

The bottom line is that there are basically 3 bits to control color, which is
why you only have 7 color choices.  And those combinations still have to be
supported for monochrome terminals too.

Doug

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---