Said it better than I could have ...
Regards,
Bill Stephens
Sr. Technology Analyst, High Availability
SunGard Availability Services
10th floor
401 North Broad Street
Philadelphia, PA 19108
Phone: (215) 351-1099
Fax: (215) 451-2045
[EMAIL PROTECTED]
___________________________________________
Keeping People and Information Connected (TM)
http://www.availability.sungard.com
Phil Smith III
<[EMAIL PROTECTED]
om> To
Sent by: VM/ESA [email protected]
and z/VM cc
Discussions
<[EMAIL PROTECTED] Subject
.UARK.EDU> Re: Warning on NETSTAT Commands
12/12/2005 12:46
PM
Please respond to
VM/ESA and z/VM
Discussions
<[EMAIL PROTECTED]
.UARK.EDU>
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...)
