home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / bit / listserv / lvmctr / 259 < prev    next >
Encoding:
Text File  |  1992-09-15  |  4.5 KB  |  87 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!ALBNYVM1.BITNET!SYSMRR
  3. Message-ID: <L-VMCTR%92091509110805@VM1.CC.UAKRON.EDU>
  4. Newsgroups: bit.listserv.l-vmctr
  5. Date:         Tue, 15 Sep 1992 07:27:10 EDT
  6. Sender:       VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET>
  7. From:         Mike Ramundo <SYSMRR@ALBNYVM1.BITNET>
  8. Subject:      listserv vs FTP
  9. Lines: 76
  10.  
  11. Hi All,
  12.      Hopefully, the demand for SCI to get some type of non-ibm net access
  13. will continue to build. What I'd like to get, before sending my letter to
  14. SCI, is a clear picture of what I expect from any vendor ( not that I have
  15. gotten all or even most of the following from any one vendor ).  I will
  16. list below what I feel an appropriate minimum service ( based on features
  17. of LISTSERV and a flexible ( Rice ? ) mailer along with what I feel to be
  18. justification. Please post your comments/additions/alternatives to either
  19. me or the list.
  20.  
  21. 1) I have been keeping a log of my 1st class mail - critical + warning
  22.    type letters especially.  Those via U.S.Mail reach me anywhere from
  23.    1 to 12 days after the postmark date, average time 4.  UPS ( tapes
  24.    and doc ) average 3 days.  If someone finds something that could
  25.    cause my system to hang or stop, I want to know within minutes, not
  26.    days - and be able to apply fix or preventative notice within same
  27.    amount of time.
  28.  
  29. therefore, I propose:
  30.  
  31.    SCI connect to bitnet or internet with rice mailer or equivalent and
  32. install listserv or equivalent on one of their mainframes.
  33.  
  34.    A list should be created for each product/major-release. That is,
  35. there should be separate lists for VMX43 and VMX44. ( probably separate
  36. lists for /E versions also ). Users should be able to 'subscribe' to
  37. a product list and:
  38.  
  39.    1) Receive notice whenever a possible problem is logged
  40.    2) Receive notice whenever a fix is released
  41.    3) using the 'get' command, request at any time:
  42.          a) the summary file of fixes for a product
  43.          b) any fixes available for the product
  44.          c) a summary file of open problems for the product
  45.             (anyone care to suggest name/suffix for this file ? )
  46.  
  47. When a site upgrades from one version of a product to another, it would
  48. only take moments to unsub from one list and sub to the other list.
  49.  
  50.     I think that item 3c might be one of the most critical items, I have
  51. learned ( since I first played with a 1620 ) never to be on the bleeding,
  52. I mean leading edge, unless you are strictly a test/development site or
  53. have a test/development system. With IBM and with SCI, I have felt most
  54. comfortable staying about 11 months behind the 'edge'.  I would love
  55. to be able to see what problems are reported AND STILL OPEN when I am
  56. looking at a new version and am trying to decide if/when to upgrade -
  57. the current summary file tells me what was fixed, not what, if anything,
  58. is still broken/incomplete.
  59.  
  60.      I suggest that generic mail-ids be set up to handle much of the
  61. data that currently comes in via phone.  Names like VMXPROB, CPUIDs,
  62. INSTALL could receive mail which could then be routed to the next
  63. available rep directly, or pulled into the current tracking system.
  64. ( Since a great percentage of times, a caller ends up leaving name and
  65. number anyway, this method would be at least as quick getting a problem
  66. into the queue and the ability to include accurate and detailed info
  67. with the original message might make it possible for rep to have
  68. solution ready at first callback rather then one call to collect data
  69. then another call with the solution.  Ongoing problems, requests for
  70. additional data or output, suggested tests, could all be communicated
  71. quickly, accurately and directly between the customer and tec rep.
  72.  
  73.      I hope this stimulates some discussion of the details of how
  74. software support ( from any vendor ) SHOULD work.  I'm sure I've
  75. missed at least a few items - don't hesitate to jump in with more/
  76. better ideas
  77.                      mike
  78. *---------------------------------------------------------------------*
  79. ║                                                                     ║
  80. ║  Michael R. Ramundo                        Fax (518) 442-3697       ║
  81. ║  Systems Programmer / Analyst            Audio (518) 442-3709       ║
  82. ║  Computing Services Center, CS-9C               Network             ║
  83. ║  State University of N.Y. at Albany        SYSMRR @ ALBNYVM1        ║
  84. ║  Albany,  New York    12222            SYSMRR @ uacsc2.albany.edu   ║
  85. ║                                                                     ║
  86. *---------------------------------------------------------------------*
  87.