The last line of any 3270 terminal is a special reserved area that cannot be addressed by the mainframe programmer or software. It shows status such as when the terminal is in Insert mode, shifted mode, pending print, and other indications which can be determined by the 3174 control unit (CU) and displayed on the status line of the terminal.
FIRST SIX COLUMNS SHOW CONNECTION TYPE
The first two columns indicate physical connectivity. In the case of a 3174 CU, the terminal displays a rectangle with a 4 inside. The second column shows an A or B with an underline to tell you whether the coax is plugged into the primary A row of connections on the CU or into the secondary B row positions.
Columns 3 through 6 display one of four symbols indicating what software is driving the terminal. A rectangle with a stick figure person inside indicates that the terminal is being used by the operating system software, such as when I have it connected as an operator console. A solid rectangle indicates that an application program is driving the terminal; this might be a CICS application for example. The four letters TEST indicate that this terminal is connected to diagnostic test programs in the mainframe temporarily. Finally, a rectangle with a ? inside tells us that the terminal is not driven by either applications or the OS at this time.
 |
| Terminal hooked to 3174 A port and driven by the OS |
MY QUESTION
What I don't yet understand is how the 3174 CU knows what software is driving the terminal. There does not appear to be any commands, orders or data that indicate these four states. There is no way to set the buffer address to the status line area in order to write to columns 3-6.
My working hypothesis is that a particular sequence of commands and actions is detected by the CU to determine which of the four states we are in. There doesn't seem to be any documentation covering this. I may need to look at the source code for the driver code such as DIDOCS which handles system consoles, seeing if any comments at connect and disconnect time hint about the special sequences that might be sent.
If any of my readers happen to know the answer to this or can point me to documentation/sources to help answer the question, I will be quite grateful.
Carl,
ReplyDeleteThe following document will answer most if not all of your questions. Assuming, of course, that you have a lot of background understanding in the first place.
http://bitsavers.org/pdf/ibm/3274/GA23-0061-1_3274_Control_Unit_Description_and_Programmers_Guide_Jan84.pdf
One of the problems with IBM manuals is that they are like a web of knowledge -- you need to know stuff from a whole lot of different areas before it is all comprehensible. For example, the above manual assumes a lot of knowledge of SNA and host access methods (VTAM and TCAM); it also assumes that you understand the 3270 Data STream -- which is documented in another manual; not to mention having at least a minimal understanding of how mainframe channels work. Back in the day, I had a shelf chock-full of IBM manuals.
A few other observations:
Why the dedicated 25th line? That is called the Operator Information Area (OIA), and gives a lot of diagnostic information. A lot of IBM equipment was designed with overt diagnostic information. Fairly useless for a user of the device, but invaluable if you are providing support (why the heck isn't my terminal working?).
What do the little symbols on the left end of the OIA mean? See Appendix B (specifically page B-1 and B-2, which are PDF pages 489-490).
How does it know what it's talking to? The SNA protocol is very stateful. A bunch of commands must flow in order to set up a "session" (technically, an LU-LU session)> First, the host access method (VTAM) needs to establish a connection with the controller (in IBM parlance, the controller is a Physical Unit) with an "Activate PU" command, and the controller needs to send a positive acknowledgement; then VTAM sends "Activate LU" (LU = logical unit -- you can think of this as the terminal, but really it's a state machine inside the controller). Finally, the actual host program that wants to use the terminal (say, TSO or IMS or CICS -- this program is also referred to as an LU, so think of an LU as an endpoint) needs to establish a "session", and this is done using an SNA "Bind" command. Each of these sessions is represented by the 3rd character position in the OIA -- if only ACTPU has flowed, then you see a question mark in a box; if ACTLU has flowed, then you see a stick figure in a box; and if Bind has flowed then you see a solid box).
The OIA also showed a bunch of other diagnostic information (documented in the aforementioned Appendix B). Really, the only OIA indicator I recall being useful to a user of the terminal was the big, bold "X" that indicated that the keyboard was locked.
Recalling all this stuff makes some very old neurons very happy, so feel free to ask questions if you have any.