OK, Chuckie -- what have you done with Alan this time!? Obviously that trace message was a perfectly adequate typical self-documenting message. <He says while bending down to insert the knife from behind just above the kidneys> ;-)
How about an even more useful message: DTCOCPxxxI Conn 2: Client 10.11.12.13 screen dimensions (66 x 160) too large for DATABUFFERSIZE (8192). Closing connection. Such a "DATABUFFERSIZE" breadcrumb provides at least a solid clue for the highly skilled z/VM sysprog acting as a network admin (some shops are not very well delegated). Bill, the problem with turning on the trace presumes that one has discovered a repeatable problem, determined what causes the undesired result, and replicate it at will without significant effort, and has the authority to issue the commands (some shops are awfully well delegated). -- Can you imagine CP without dumps? OK, after you crash and IPL, set a CP TRSOURCE and then repeat the problem while capturing the error before the system crashes again -- not a very acceptable idea. If TCPIP encounters an error that causes the loss of a session one should reasonably expect that there would be diagnostic messages issued to the TCPIP console to permit at least a glimmer of "First Failure Data Capture", yes? I'm grateful for the NETSTAT OBEY TRACE TELNET/TRACEOFF example. It will go into my sysprog toolkit if Al Zheimer doesn't lose it first. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Alan Altmark" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 02/23/2007 03:38 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Max size 3270 screen On Friday, 02/23/2007 at 03:37 EST, William Moy/Endicott/[EMAIL PROTECTED] wrote: > The resultant TCP/IP console should have in it msgs similar to the following: > 15:20:49 DTCOCP032I Conn 2: Transparent-mode data overruns buffer. ToCpPos 8192, > CharsScanned 2048, hbound(...) 8192. Killing conn. > 15:20:49 DTCSTM120I Killing Connection: 2 (cough) That's not really a message - it's debug output and only meaningful if you're reading TNTOCP PASCAL. How about a real message that says: DTCOCPxxxI Conn 2: Client 10.11.12.13 screen dimensions (66 x 160) too large for data buffer (8192). Closing connection. and that is NOT behind a trace. The telnet server knows when it is processing a WSF QUERY REPLY and could stash the dimensions away when an Implicit Partition Query reply is received. The Msgs & Codes would tell you to update DATABUFFERPOOLSIZE and that it should be large enough to hold (rows x columns)+20(?) bytes. It must be Friday. Alan Altmark z/VM Development IBM Endicott The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
