Alan, I remember this happening to me, and I didn't even start the trace unintentionaly! :-)
When a TCPIP trace starts, by default it goes to TCPIP's console. In our case, the problem is not so much that the spool was quickly filling up (that can be taken care of), but the fact that we had a PROP user as a secondary user to TCPIP. Since PROP cannot write the messages to a file on disk as fast as TCPIP is generating them, they queue up and THAT can kill the system. From then on, I always do a SET SECUSER TCPIP OFF before I start the trace and/or do a trace to a file, not the console (FILE and NOSCREEN trace statements). This obviously won't help you if you start the trace accidentaly. Therefore, if you do use PROP to manage TCPIP messages, put 'NOSCREEN' and 'FILE fn ft fm' statements in the trace section of your relevant PROFILE TCPIP file. That way you will still be able to have TCPIP messages managed by PROP, while trace, if it accidentaly starts, will go to a file until it fills up the minidisk. If the minidisk fills up, the trace output IS terminated. And if you want to start the TCPIP trace to the console intentionaly (e.g. if you need a large amount of space for the trace output and you have enough spool space), do a CP SET SECUSER TCPIP OFF before you begin the trace and then ocasionaly do a NETSTAT CP CLOSE CON and you'll be OK. Cheers, Ivica Brodaric Tabcorp, Australia -----Original Message----- From: Alan Ackerman [mailto:[EMAIL PROTECTED] Sent: Monday, 12 December 2005 3:22 PM To: [email protected] Subject: Warning on NETSTAT Commands *********************** The file attachment (no filename) has been scanned using antivirus software. It does not contain a computer virus. This message was scanned for computer viruses using Trend Micro's VirusWall for SMTP filter, and was found to be virus-free. ***********-*********** Warning: Be very careful what commands you issue via NETSTAT. Someone here accidentally issued NETSTAT OBEY CP Q TRACE. This turned on a TCP/IP trace. This slowed down TCPIP so much that it rejected any logins or new NETSTAT commands; it also filled up the spooling space. (It also uncovered a problem with the backup system that we use to login when TCP/IP access is not available -- but that's another story.) IBM told us: When an OBEY command is issued the parser ignores any invalid keywords in the string but reads the entire string to the end. Unfortunately TRACE is a valid command, it turns on TRACE MOST by default. So ignoring the invalid keywords the command that got accepted was NETSTAT OBEY TRACE. The PROFILE TCPERROR file reported that to you. Development does not believe it is a bug the parser parsed the string as it was designed and supposed to do. I will open a development report to see if that can be visited in the next release and maybe changed. Development does not feel the change should be made via an APAR. So I thought I'd better warn everyone! Alan Ackerman alan (dot) ackerman (at) bank of america (dot) com *********************************************************************************** The information in this e-mail message and any files transmitted with it are intended to be confidential and for the use of only the individual or entity to whom they are addressed. The message and files may be protected by legal professional privilege, or other legal rules. The confidentiality of and privilege applying to this message and files is not waived if this message or files has been sent to you by mistake. If the reader of this message or files is not the intended recipient, you are notified that retention, distribution or copying of this message and files are strictly prohibited. If you receive this message or files in error, please notify us immediately by telephone or return e-mail and delete all copies from your computer system. It is the recipient's responsibility to check this message and files for viruses. Thank you. ***********************************************************************************
