Newsgroups: bit.listserv.l-vmctr
Date:         Tue, 15 Sep 1992 07:27:10 EDT
From:         Mike Ramundo <SYSMRR@ALBNYVM1.BITNET>
Subject:      listserv vs FTP

Hi All,
     Hopefully, the demand for SCI to get some type of non-ibm net access
will continue to build. What I'd like to get, before sending my letter to
SCI, is a clear picture of what I expect from any vendor ( not that I have
gotten all or even most of the following from any one vendor ).  I will
list below what I feel an appropriate minimum service ( based on features
of LISTSERV and a flexible ( Rice ? ) mailer along with what I feel to be
justification. Please post your comments/additions/alternatives to either
me or the list.

1) I have been keeping a log of my 1st class mail - critical + warning
   type letters especially.  Those via U.S.Mail reach me anywhere from
   1 to 12 days after the postmark date, average time 4.  UPS ( tapes
   and doc ) average 3 days.  If someone finds something that could
   cause my system to hang or stop, I want to know within minutes, not
   days - and be able to apply fix or preventative notice within same
   amount of time.

therefore, I propose:

   SCI connect to bitnet or internet with rice mailer or equivalent and
install listserv or equivalent on one of their mainframes.

   A list should be created for each product/major-release. That is,
there should be separate lists for VMX43 and VMX44. ( probably separate
lists for /E versions also ). Users should be able to 'subscribe' to
a product list and:

   1) Receive notice whenever a possible problem is logged
   2) Receive notice whenever a fix is released
   3) using the 'get' command, request at any time:
         a) the summary file of fixes for a product
         b) any fixes available for the product
         c) a summary file of open problems for the product
            (anyone care to suggest name/suffix for this file ? )

When a site upgrades from one version of a product to another, it would
only take moments to unsub from one list and sub to the other list.

    I think that item 3c might be one of the most critical items, I have
learned ( since I first played with a 1620 ) never to be on the bleeding,
I mean leading edge, unless you are strictly a test/development site or
have a test/development system. With IBM and with SCI, I have felt most
comfortable staying about 11 months behind the 'edge'.  I would love
to be able to see what problems are reported AND STILL OPEN when I am
looking at a new version and am trying to decide if/when to upgrade -
the current summary file tells me what was fixed, not what, if anything,
is still broken/incomplete.

     I suggest that generic mail-ids be set up to handle much of the
data that currently comes in via phone.  Names like VMXPROB, CPUIDs,
INSTALL could receive mail which could then be routed to the next
available rep directly, or pulled into the current tracking system.
( Since a great percentage of times, a caller ends up leaving name and
number anyway, this method would be at least as quick getting a problem
into the queue and the ability to include accurate and detailed info
with the original message might make it possible for rep to have
solution ready at first callback rather then one call to collect data
then another call with the solution.  Ongoing problems, requests for
additional data or output, suggested tests, could all be communicated
quickly, accurately and directly between the customer and tec rep.

     I hope this stimulates some discussion of the details of how
software support ( from any vendor ) SHOULD work.  I'm sure I've
missed at least a few items - don't hesitate to jump in with more/
better ideas
                     mike
*---------------------------------------------------------------------*
                                                                     
  Michael R. Ramundo                        Fax (518) 442-3697       
  Systems Programmer / Analyst            Audio (518) 442-3709       
  Computing Services Center, CS-9C               Network             
  State University of N.Y. at Albany        SYSMRR @ ALBNYVM1        
  Albany,  New York    12222            SYSMRR @ uacsc2.albany.edu   
                                                                     
*---------------------------------------------------------------------*