BRYAN@WVNVM.WVNET.EDU ("Bryan, Jerry") (07/25/90)
It may not have been on this list, but there was recently a discussion of problems with TN3270 implementations using CICS on IBM mainframes. One problem is almost certainly the tendency of some TN3270 implementations not to return data fields from the emulated 3270 screen in a top-to-bottom, left-to-right order. However, another problem is an incompatibility between CICS and the implementation of special Yale ASCII nulls processing on TN3270. I became curious and posted the problem to the IBM7171 list, because the 7171 does implement the Yale ASCII nulls processing, but does not have the CICS incompatibility. I couldn't figure out why TN3270 fails with CICS, but the 7171 works. It seemed to me like they both should fail since both of them implement the Yale ASCII nulls processing. It turns out that the TN3270 implementations of Yale ASCII do not include what Yale calls the "TSO fix", but the 7171 does include the "TSO fix". Now that I understand the problem, I can recreate it on TSO as well as on CICS. Here follows a copy of the posting I made to IBM7171, as well as a reply from Howard Gilbert, who was one of the developers of Yale ASCII. I guess I hope that various TN3270 implementers would consider including Howard's "TSO fix". Note in particular that Howard has already reported the lack of the "TSO fix" to IBM with respect to IBM's TN3270 implementations, and IBM has accepted it as a bug which will be fixed. IBM must be the most difficult vendor in the world to convince that a feature is really a bug, so this one must really be a bug. My posting: This will eventually be a 7171 question, but will start out otherwise. We had a problem with several different implementations of TCP/IP TELNET (TN3270) on a PC emulating a 3270 and going into CICS. The symptom was that after signon was complete, all further input to CICS was considered by CICS to be an error. That is, no transaction name would be accepted as a valid transaction name. We obtained a VTAM buffer trace of the various TCP/IP implementations as well as a trace of a real 3178. It turns out that the problem has to do with the null handling code in the TELNET 3270 implementations, with the null handling modeled after the 7171 (in turn modeled after Yale ASCII processing in the Series/1). CICS is posting a SIGNON COMPLETE message to the bottom of the screen (line 24 column 1). It is then skipping to line 24 column 40, erasing to line 1 column 1, inserting the cursor, and reading what is typed. The user perceives that he is typing at the upper left corner of the screen, but the field actually begins in the lower right corner of the screen and wraps to the upper left. The erase operation places forty-one nulls in the lower right hand corner of the screen. On a real 3178, the forty-one nulls are omitted, CICS sees the characters which the user typed left justified, and all is well. With TCP/IP TELNET 3270, the forty one nulls appear in the buffer as forty one blanks, the characters typed by the user appear after the blanks, and CICS does not work at all. One of the TCP/IP TELNET 3270 implementations I am running permits special null handling to be turned off, making null handling work in 3178 style rather than in 7171 style. Turning the special null handling off makes CICS work fine with TELNET. Now for the 7171 question. CICS works through our 7171. We traced the exact same scenario through the 7171, and the trace is identical to the 3178 trace. This is "good" in the sense that it makes CICS work. However, it seems impossible to me. Why doesn't the 7171 have the same problem as TELNET 3270? It looks like the 7171 must have some sort of bug, because the nulls should be replaced by blanks, but if it is a bug, it is a most useful bug indeed. (That is not a bug, it is a feature!). Alternatively (and almost certainly the case), the 7171's null handling is somehow superior to TN3270's in some way which I cannot presently discern. Can anyone enlighten me? Thanks in advance. Howard Gilbert's response You have benefited from the "TSO fix" which has always been an amendment to the Yale ASCII "improved nulls" processing. At Yale we worked on TSO (VSAPL for TSO was ours) before SPF. In REAL TSO (not ISPF, not Session Manager) the system types READY on one line, puts an attribute after READY and then positions the cursor at the beginning of the next line: READY<?> -------------- all nulls to end of line ----------------------- listcat Were the imbedded nulls turned into blanks the command would echo back funny. Worse, you cannot enter an "end of file" which requires that the host read "/*" at the beginning of the input not preceded by any blanks. The fix for this problem is to check if there are any non-null characters from the attribute byte to the end of the line on the screen and, if not, start at the next line sending data. While this takes care of TSO and your problem, it would not suppress blanks if the field had started on the 23rd line, extended across the 24th line, and then wrapped back to home. To save cycles on the .250MIP Series/1 we only put in the adjustment for the first line of the field and turn subsequent completely null lines to blank. I have reported the lack of this adjustment to the ANTs (IBM's XANT, PM-ANT on AIX and OS/2). Given the TSO end-of-file example they accept it as a bug and expect to fix it in the next distribution. The real problem is that the adjustment is not needed in CMS and that is the only system TN3270 people generally test on.
jbvb@VAX.FTP.COM ("James B. Van Bokkelen") (07/26/90)
The "TSO fix" is a horrible kludge at every level. The *right* way to control Yale Null Processing is via the special 'orders' Yale defined which do so (and are accepted by all Minshall-derived tn3270s, including ours). However, given that it is apparently out of the question to ask that IBM add this to historical monuments like CICS, I guess the "TSO fix" will have to suffice. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901