From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: vmsnet.mail.mx
Subject: Re: Where are the MX errors documented?
Date: 26 Sep 1992 19:45:19 GMT
Organization: HST Wide Field/Planetary Camera
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <00961244.E90FC7C0.9743@vms1.cc.uop.edu>, Ed Bates <ebates@vms1.cc.uop.edu> writes:
><carl@SOL1.GPS.CALTECH.EDU> writes:
>>OK, Brian, since you seem incapable of understanding what either I or Matt told
>>you, here's a first cut at it:
>>[...]
>>How many more times do you have to be told this before you believe it, nitwit?
>>[...]
>
>I appreciate the information you passed on to us, Carl.  However,
>not everyone is quite the techno-wiz that you, Matt, and others are.

OK, let me try to make my position clear:  The status values we're talking
about here, in one sense should need no documentation within MX:  If you don't
know what a timeout is, the MX documentation isn't the place to learn it.  If
you don't understand the term "protocol violation," the MX documentation isn't
the place to learn what that means.  Likewise for most of the other status
values you'll see in the queues (the main exception is for the LOCAL delivery
agent:  It generally involves VMS MAIL status values;  again, the MX
documentation isn't the place to document these).  In no case that I can think
of offhand does the status value you see with the MCP QUEUE SHOW command give
you enough information to do anything useful:  It's just a rather general
description of the sort of problem that's occurring (except in the case of the
LOCAL delivery agent, in which case the status might be specific, but in that
case it's usually one of the status values that take text arguments (e.g.,
which machine was unreachable, and these values aren't dealt with by the MCP
QUEUE SHOW command).

So there's really not much point in documenting these values.  The ONLY way you
can figure out what the problem is is to enable debugging and look at the
trace.  Now, at THAT point, it's a good idea to know how the various protocols
are supposed to work.  Again, that's not something that should be put in the MX
documentation.  You should get a copy of the appropriate protocol definitions
from whomever maintains them (in the case of SMTP, you can get RFC822 from
NIC.DDN.MIL via anonymous FTP; you should also check for other RFCs that modify
RFC822).  It WOULD be nice if the documentation for MX contained directions on
where to find the protocol specifications.


Now, of course Hunter could expand the number of error statuses for each of the
agents so that there's a unique error status for each possible sort of error. 
However, I suspect that doing this for, e.g., protocol violations, would result
in more unique error values than are allowed to any one utility.  Documenting
all of them would take either several man months of effort, or a computer
program to run through all invalid action/response pairs possible in the
protocol.  Either way, the documentation at such a level would be meaningless
if you didn't understand the protocol in question, and unnecessary if you DID
understand the protocol.

>It has not been made clear to me that one has to have a complete
>understanding of VAX/VMS system management, TCP/IP, or even basic
>networking in order to receive assistance from people who may know
>the answers.  If that is true, can we make a separate distribution
>list for people who want to know things that long-time VAX managers
>know without disturbing the balance of techno-wiz discussions?

Brian received assistance from us.  He chose repeatedly to ignore it.  He was
told at least twice that the error statuses he wants documented were nearly
meaningless by themselves, and that the appropriate thing to do is enable
debugging and look at the trace.  He believed, apparently, neither Matt nor
myself when we told him this.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.