home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / vms / 21853 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  10.7 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: How to post to info-vax/comp.os.vms (without getting flamed)
  5. Date: 23 Jan 1993 23:56:20 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 157
  8. Distribution: world
  9. Message-ID: <1jslv4INNi86@gap.caltech.edu>
  10. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  11. NNTP-Posting-Host: sol1.gps.caltech.edu
  12.  
  13. The following guidelines for posting  questions  to  COMP.OS.VMS/INFO-VAX  are
  14. intended  to help querants post their questions in such fashion as to maximize
  15. the probability that they'll receive quick, useful responses, and to  minimize
  16. he probability that the questions will annoy the people most likely to be able
  17. to give useful responses.
  18.  
  19. First, the very short version:
  20.     1)  Let us know how we can contact you;
  21.     2)  Tell us exactly what you're trying to accomplish;
  22.     3)  If you're reporting what seems to be a bug, then:
  23.         A)    Tell us exactly how to exercise the bug;
  24.         B)    Tell us the version numbers of all software involved;
  25.         C)  Tell us exactly what response VMS gives;
  26.         D)  Tell us what output you expected;
  27. Now, a bit more detail:
  28. 1)  Let us know how we can contact you.
  29.     The  COMP.OS.VMS/INFO-VAX  gateway  has  a  tendency  to   mangle   return
  30.     addresses.   You  therefore  can't  count  on  the  return address in your
  31.     message header to allow us to answer you.  Put a valid e-mail  address  in
  32.     the  body  of  your  message.  If your problem is one that might make your
  33.     system unavailable, you should seriously consider  giving  us  your  phone
  34.     number,  FAX  number,  or  possibly even your postal address.  None of our
  35.     answers can help you if you never see them.
  36. 2)  Tell us exactly what you're trying to accomplish.
  37.     Be specific.  Something like "How do I  use  the  system  services"  is  a
  38.     pretty  broad  question.   Answering it would take quite a bit of time and
  39.     effort.  In fact, providing  a  complete  answer  requires  at  least  two
  40.     binders' worth of information.  So tell us:
  41.     A)  What input, if any, you expect to provide, to  the  program  that  you
  42.         want to use;
  43.     B)  What output you want from the program;
  44.     Please *DON'T* come to us with a  preconceived  notion  of  how  something
  45.     *OUGHT* to be doable.  If you haven't been able to figure out how to solve
  46.     your problem, there's  a  good  chance  you're  using  an  entirely  wrong
  47.     approach.   So  rather  than  asking  about  one  particular  step in your
  48.     "solution," tell us what you really want to accomplish.
  49. 3)  If you're reporting what seems to be a bug, then:
  50.     A)  Tell us exactly how to exercise the bug: And I *DO* mean  EXACTLY.   A
  51.         DCL  procedure  that exercises the bug is preferable.  Some things, of
  52.         course, only work interactively.  In that case, SET HOST/LOG  to  your
  53.         own   machine  and  demonstrate  the  problem.   Then  log  out,  edit
  54.         SETHOST.LOG to put it in readable format, and mail us that file  along
  55.         with your description of the problem.
  56.     B)  Tell us the version numbers of  all  software  involved:  The  version
  57.         numbers  are  more  than  just  time/date  stamps.   Software actually
  58.         changes between versions.  If we're to help you, we often need to know
  59.         what versions of software you're using.
  60.     C)  Tell us exactly what response  VMS  gives:   The  output  of  the  DCL
  61.         procedure or SET HOST session from step A is preferable.  If you use a
  62.         DCL procedure, please be sure to SET VERIFY at the top of it.
  63.     D)  Tell us what output you expected.  Most reported "bugs" aren't bugs at
  64.         all.   They're  normal, documented behavior of VMS.  If you don't tell
  65.         us what results you expected, the most you can generally hope  for  in
  66.         an  answer  is  "That's what it's SUPPOSED to do." If you tell us what
  67.         results you expected, chances are that somebody will be able  to  tell
  68.         you how to get the desired results.
  69.  
  70. That sums up the guidelines.  The remainder of this post is a rather  rambling
  71. discourse  on  details of the above.  You need read no further if all you want
  72. is to be able to post questions and get polite, useful answers.   Just  follow
  73. the  above  guidelines.  I *DO* recommend that you read the rest of this post,
  74. as it will clarify some of the points that were glossed over above.
  75.  
  76.  
  77. Perhaps the most important thing to remember is:  You've run into  a  problem,
  78. and haven't been able to figure out how to solve it.  One possible explanation
  79. for this is that you're going about it the wrong way.  Therefore,  asking  for
  80. help  solving  a minor problem in what you think is a "solution" to your major
  81. problem may do you no good whatever.  So in general, there are two things  you
  82. ABSOLUTELY need to tell us if you want help:
  83.  
  84. 1)  How we can get in touch with you to answer your question;
  85. 2)  What you are trying to accomplish;
  86.  
  87. Now, for the specific guidelines I propose:
  88.  
  89. 1)  First and foremost, if you want us to e-mail  responses  to  you  (and  in
  90.     general,  I'd recommend that you actually read this group; there really IS
  91.     a lot of useful stuff you can pick  up  that  way),  please  include  your
  92.     e-mail  address  (including  a fully-qualified domain name) in the body of
  93.     your  message.   The  news/mail  gateway  mangles  addresses.    In   both
  94.     directions (well, actually, I think it's UUNET.UU.NET that tends to mangle
  95.     addresses coming in via mail).  If you really  need  to  have  a  response
  96.     mailed to you, the only way you can guarantee that we'll be able to figure
  97.     out how to do that is if you give us your e-mail address.
  98. 2)  If your question is about a VMS utility that doesn't do what  you  expect,
  99.     include in your question:
  100.     A)  The command you used that generated the "improper" response;
  101.     B)  A description of what you  thought  the  system's  response  should've
  102.         been.   A question of the form "X doesn't work properly.  How do I fix
  103.         that?" is unanswerable.  We have to know HOW X doesn't work  properly.
  104.         Sometimes  the  answer  will  be "X isn't supposed to do that.  You've
  105.         misunderstood the documentation.  To get the response you want, use  Y
  106.         instead."  But  we  can't help you unless we know what it was you were
  107.         trying to accomplish."
  108.     C)  The FULL error message (if any) given to you by  VMS.   VMS  is  *NOT*
  109.         unix.   VMS  error  messages  usually  contain LOTS of information for
  110.         those who understand them.  But we need the FULL  text  of  the  error
  111.         message, exactly as VMS gave it to you.  Vague mention of the message,
  112.         like "it said I didn't have enough memory" is useless.  The actual VMS
  113.         error message, for example, in a case like this example, would usually
  114.         have told us WHAT KIND of memory you ran out of.  So  please,  VMS  is
  115.         trying  to help you find the problem; do us the same favor and give us
  116.         all the information VMS gave you.
  117.     D)  The version number  of  all  relevent  software.   Oddly  enough,  the
  118.         version  numbers  aren't  just  time  stamps.   Things actually change
  119.         between versions of software.  Bugs in one version might not  show  up
  120.         in  other  versions.   So  if you have actually stumbled across a bug,
  121.         please let us know what version of the software you're running, so  we
  122.         can decide whether we might be able to help you.
  123.     E)  Complete  descriptions  (output  of  ANALYZE/RMS/FDL  would   ususally
  124.         suffice) of any of your files involved in the problem;
  125.     F)  If it appears to be a problem with SYSGEN parameters, let us know what
  126.         your  SYSGEN  parameters  currently  are.   Some SYSGEN parameters are
  127.         interrelated.  Since you haven't been able  to  diagnose  the  problem
  128.         yourself,  don't  be  too  sure  that you're even looking in the right
  129.         place.  Again:  Give us all the information that might be necessary to
  130.         solving  the  problem.   Don't  just give us the SYSGEN parameters you
  131.         THINK are causing the problem.  Give us ALL the SYSGEN parameters that
  132.         MIGHT POSSIBLY have an effect on the problem.
  133. 3)  If your problem is that some user-written code doesn't do what you expect,
  134.     then  don't  try  translating  from C (or PASCAL, or FORTRAN, or BASIC...)
  135.     into  English.   Believe  it  or  not,  most  of  us  who  participate  in
  136.     COMP.OS.VMS  actually  understand  one  or more programming languages, and
  137.     some of us even have compilers that we can use.  Furthermore, 99%  of  the
  138.     "compiler  bugs"  people find aren't compiler bugs at all:  they're poorly
  139.     written application code.  By the time you've converted your code into  an
  140.     English  description, you've almost certainly glossed over whatever it was
  141.     that was REALLY causing the problem (once again:  If you knew enough about
  142.     the  real  problem  that  you'd  think  it important to mention it in your
  143.     English-language description, you'd probably also know how  to  solve  the
  144.     problem).   So  don't do us the favor of "summarizing" your problem.  When
  145.     you do that, the problem itself usually gets summarized out of  existence.
  146.     Instead,  find  the  code  that's  causing the problem.  If it's something
  147.     huge, try to find a simpler version of the same sort of code that  creates
  148.     the  same  problem.  Keep working at it until you've got a program of less
  149.     than 100 lines of code that produces the problem, or until you can't  find
  150.     a simpler example that demonstrates the problem.  Strangely enough, by the
  151.     time you've done this, you'll have found the problem  yourself  more  than
  152.     half the time.  And if you HAVEN'T done this, chances are that nobody else
  153.     will be able to figure out what you're talking about enough to  help  with
  154.     your problem.
  155.  
  156.     If, once you've reduced the problem to the simplest example you  can,  you
  157.     still can't figure out what's going wrong, then post the code, the version
  158.     number of the compiler, complete descriptions of any  of  your  own  files
  159.     that  seem  to be related to the problem, and, as always, a description of
  160.     what you think your code SHOULD do, to us, and  you'll  likely  receive  a
  161.     prompt and useful answer.
  162. --------------------------------------------------------------------------------
  163. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  164.  
  165. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  166. understanding of astronomy is purely at the amateur level (or below).  So
  167. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  168. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  169. hold me responsible for it, but my organization had nothing to do with it.
  170.