Bingo! Even though I though I had checked TCPIP's 191 disk for a file, perhaps it was still open when I checked. The messages appeared near the bottom of the file on TCPIP's 191 disk: "TCPIP TRACDATA A".
Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Harding, Mike" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 02/23/2007 04:06 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 And do you have TRACE FILE... in your tcpip profile? Did you look on tcpip's a-disk? Mike Harding EDS VM National Capability 134 El Portal Place Clayton, Ca. USA 94517-1742 * phone: +01-925-672-4403 * Fax: +01-925-672-4403 * mailto:[EMAIL PROTECTED] * <mailto:[EMAIL PROTECTED]> (personal) Note: For 2007, I am off on Fridays with even Julian dates and Mondays with odd ones. -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Friday, February 23, 2007 1:59 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Max size 3270 screen Bill, That would be a good help (more later in a reply to Alan's post), but did not work. I got two files back in TCPMAINT reader: FILE: TCPIP MESSAGE A1 Hewitt Associates DTCUTI002E OBEY TRACE TELNET issued by TCPMAINT; return code 0 and FILE: TCPIP MESSAGE A1 Hewitt Associates DTCUTI002E OBEY NOTRACE issued by TCPMAINT; return code 0 There was nothing on the TCPIP spooled console other than: PRT FILE 0010 SENT TO TCPMAINT RDR AS 1738 RECS 0002 CPY 001 P NOHOLD NOKEEP PRT FILE 0012 SENT TO TCPMAINT RDR AS 1739 RECS 0002 CPY 001 P NOHOLD NOKEEP Close, no kewpie doll (and no cigar either - a kewpie doll could stunt it's growth by smoking; ask Chuckie!). Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "William Moy" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 02/23/2007 02:37 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 Hi Mike, Well, you could do the following: Enable tracing of Telnet (for example: NETSTAT OBEY TRACE TELNET), Connect to the z/VM Telnet server and cause the disconnect, Get the TCPIP stack console (for example: NETSTAT CP SP CONS CLOSE) 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 ...Don't forget to turn off the trace (eg. NETSTAT OBEY NOTRACE). Is this sufficient? Best Regards, Bill The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on 02/23/2007 02:32:01 PM: > > Same 8K buffer here -- but since it is Friday I'll wait for our > weekly Sunday evening IPL. Thanks! > > Next question: why don't we see any sort of error on the TCPIP > console when the session is forcibly disconnected due the large > screen size/buffer size disparity? Thus sort of thing gets REALLY > hard to track down without messages (without even self-defining messages). > > Mike Walter > Hewitt Associates > Any opinions expressed herein are mine alone and do not necessarily > represent the opinions or policies of Hewitt Associates. > > > > "Fran Hensler" <[EMAIL PROTECTED]> > > Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > 02/23/2007 01:18 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 > > > > > Bill - > > You guessed right, my DATABUFFERSIZE is 8K. > > I won't be able to recycle TCP/IP until tomorrow. > I'll jack up the size and let you know the results. > > Thanks for all the replies. > > /Fran > --------------------------------------------------------- > On Fri, 23 Feb 2007 14:02:21 -0500 William Moy said: > > > >The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on 02/23/2007 > >12:50:07 PM: > > > >> What is the maximum size a VM 3270 screen can be? > >> > >> I like 66 x 160 and it works for most things in HostExplorer. > >> But it disconnects me when I use PEEK or NAMES when I hit <Enter>. > >> > >> I have played with some smaller sizes but they disconnect too. > >> I'm running z/VM 3.1. > >> > >> Is this a problem with z/VM or HostExplorer? > >> > >> /Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 > >years > >> [EMAIL PROTECTED] +1.724.738.2153 > >> "Yes, Virginia, there is a Slippery Rock" > > > >Hi Fran, > > > > In your z/VM TCP/IP configuration file (PROFILE TCPIP) what is the value > > of the DATABUFFERPOOLSIZE statement? If it is set to buffers that are > > 8K (or default to 8K), can you please try the next higher value 16K? > > Or, whatever your setting, try the next higher one, please. When I > > tried 90 x 160 I got the disconnect with 8K but it worked fine when I > > went to 16K. > > > > There is the following usage note under DATABUFFERPOOLSIZE in the TCP/IP > > Planning and Customization book in chapter Configuring the TCP/IP > > server: > > > > The TCP layer for Telnet uses regular data buffers only if there are > > no small data buffers available. The Telnet server also uses regular > > data buffers for internal processing, regardless of whether small > > data buffers are available. > > > >Best Regards, > >Bill Moy > >z/VM Development > > 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. 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. 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.
