Alan Ackerman <[EMAIL PROTECTED]> wrote: >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. Wow. Let me go put a 45 on the turntable and fire up my Dodge Aries. Because last time I saw a response this boneheaded from IBM on something that's so obviously a bug, those were current items! So, let's review: you issue a command, which produces errors because the syntax is invalid, but performs some random action based on finding a token in the command string that it recognizes. The error arrives via reader file, and you, being a smart fellow, immediately realize that "netstat cp" was invalid, so you don't even look at the error file. Or you look at it, and miss the fact that *in an error file* it says "Yeah, I did this" (when normally, a "netstat obey trace" just says "Yup, I did that" on the console). And this is considered normal, because someone blew it when they designed that function. I've had code that was "designed" to PROG1 when you type bad inputs -- but that didn't make it a good idea. I'm all for not making changes via APAR that are incompatible, but given that: 1) TCP/IP is an essential system service in this day & age 2) TCP/IP is already far too easy to break (those of us who work thousands of miles from our system consoles are particularly sensitive to this fact!!!) 3) The format DOES produce an error -- not just an ephemeral message, but a reader file -- something that will need dealing with eventually, if someone IS using this behavior deliberately it would seem to me that anybody who is depending on that behavior is going to (a) be hard to find and (b) even if (s)he exists, isn't likely to complain. I'd thus suggest that this stance is not defensible, and ask IBM to revisit it. Loudly. ...phsiii (feeling younger, remembering the Bad Old Days when IBM would respond like this frequently, recalling arguing "all means all", when some long-forgotten command was documented as returning "all" of something and wasn't...)
