The following supplementary material is designed to answer these questions:
This description helps answer those questions by further explaining the rules for Field Attribute detection and interpretation. This information only applies to TN3270 and TN5250 single-byte character sets. The screen size is assumed to be 1920 linear positions or 24 rows x 80 columns. The upper-left corner is 1 or (1,1). The lower-right corner is 1920 or (24,80).
Introduction
This is a discussion of the structures and relationship of these HACL API planes:
These planes are artificial constructs for the convenience of the HACL API and the programmer. There is no need to refer to the "data stream."
The plane that might cause confusion is the FIELD_PLANE. The definition of the FIELD_PLANE is the inverse of the definition of the other HACL API planes.
TEXT_PLANE, COLOR_PLANE, and EXTFIELD_PLANE are fully populated planes. In contrast, the FIELD_PLANE is sparsely populated. "Fully populated" means that (nearly) every byte in the plane contains information. "Sparsely populated" means that only a few of the bytes in the plane are not NULL.
This example uses a 24 x 80 screen size. The retrieved TEXT_PLANE buffer is 1291 characters (1920 of printable characters plus a trailing NULL). For now, disregard the trailing NULL. The retrieved companion FIELD_PLANE is 1920 characters long, not 1921.
Each byte in the FIELD_PLANE corresponds to the same-position byte in the TEXT_PLANE.
Information contained in the text plane
Each of the first 1920 bytes of the TEXT_PLANE has a printable character value in it, including WHITESPACE (0x20). The TEXT_PLANE contains no other information and can be fairly represented by a TELETYPE printing with a black ribbon on a white paper tape.
If that imaginary TELETYPE printer automatically has a mechanical line feed and carriage return after printing 80 characters, the sheet feed will contain a 24x80 printed matrix of the TEXT_PLANE. However that arrangement of information is not contained explicitly in the TEXT_PLANE.
Information contained in the field plane?
Here is the HACL API definition of a "field." A field is one introductory attribute byte (not-NULL) followed by zero-to-many NULL bytes. Or, a field can be decomposed into two subfields. The first subfield is always present, always non-NULL, and always exactly one byte. Call this the "attribute subfield." It encodes (alpha)numeric, intensity, lightpen, etc. The second "padding subfield" may or may not be present; but if it is present, it always consists of NULL bytes (0x00).
When a field terminates or when the next field is encountered
Look at this 20 character example of the FIELD_PLANE represented against the corresponding 20 characters of the TEXT_PLANE. For the following example, there are five fields.
e000000c000000000ccc <--- MSBits of HEX of FIELD_PLANE 00000001000000000000 <--- LSBits of HEX ....,....1....,....2 Field1 Field2--- <=== TEXT_PLANE
Remember: a field begins with a non-NULL byte. In this 20-byte run, there are five non-NULL bytes. Therefore it is possible to count the fields and determine the length of each field.
1st: 7 [1 attribute non-NULL byte plus 6 padding NULLs]
2nd: 10 [1 attribute non-NULL byte plus 9 padding NULLs]
3rd: 1 [1 attribute non-NULL byte plus NO padding NULLs]
4rd: 1 [1 attribute non-NULL byte plus NO padding NULLs]
5rd: 1 [1 attribute non-NULL byte plus NO padding NULLs]
The HACL API documentation states that any non-NULL byte in the FIELD_PLANE forces the corresponding byte in the TEXT_PLANE to be WHITE_SPACE (0x20). Examine the example:
e000000c000000000ccc <--- MSBits of HEX of FIELD_PLANE 00000001000000000000 <--- LSBits of HEX ....,....1....,....2 Field1 Field2--- <=== TEXT_PLANE
This is how the HACL API orthagonally decomposes the "data stream" into (among others) the TEXT_PLANE and the FIELD_PLANE.
Conclusion
In conclusion, when working with planes, remember the following:
[ Top of Page | Previous Page | Next Page | Table of Contents ]