Conference 7.286::digital

    I thought we could send patches directly to customers through DSNlink
    via the Customer Support Centers.

Eric, we're ALREADY doing this.  We have Internet FTP systems which today
are providing a range of information, and a system is being put into place
to provide Internet access to updated product kits for service customers.
I expect that this latter will go online in the next month or two.  Indeed,
my experience is that Digital is ahead of its competition in how well it uses
the network to help customers.  Just recently we announced free Internet
access to Alpha AXP systems for customers to "try out".

Gail Grant is behind the Internet kit update service proposal.

Perhaps in the future you might ask first and shoot second?

				Steve

>Digital Refuses to Use Network

Were you a tabloid headline writer in a former job, by any chance?

My group (Un*x Networking [DECnet for OSF or ULTRIX]) uses the Internet all time
for distributing field test kits.  Other groups inside the Networks group use
it as well (DECNIS, DECnet-VMS, DNS, WANrouter, X.400, X.500, UCX).

It's all in the way you ask...

    Re .2:
    
    Who am I supposed to ask?  Do I have access to any of those systems? 
    Where are they; how do I put files there?  Before posting this note, I
    checked the Gateway conference; the latest topic on FTP access
    indicates only that we cannot do what I requested.  The FTP relay
    service that Digital has will not let me put files -- so how can I send
    a file to a customer's system?  (Don't say mail; these are binaries and
    sometimes are too large to send readily through mail when uuencoded.)
    
    Why won't the relay service let us put files?
    
    Digital is _not_ ahead of the competition in using Internet.  Having
    the Alpha system available is just a gimmick; it provides little
    substantial information.  We should have published mail addresses for
    technical support, sales inquiries, et cetera.  We should have a
    published FTP address where customers could find patches, release
    notes, documentation, et cetera.
    
    
    Re .4:
    
    _How_ do you use the Internet?  Do you make files available to
    customers via FTP?  Can you send files via an FTP put?  If so, how do I
    get the same capabilities?
    
    
    				-- edp

I make them available via anonymous ftp from gatekeeper.  You need to know the
exact path to be able to fetch the file.  The directory heirarchy is protected
so that you can't go looking for the file.

Announcements of where the files are are sent via FAX as each new kit is placed
on gatekeeper.  

    RE .2
    	Actually Steve the folks responsible for the Internet Patch 
    	Services Proposal are: Jack Callaghan, Joe Rogers, & Mike Temkin.
    	Gail has been an INVALUABLE asset in helping us move thru the politics.
    
    RE .5 
    	Actually we at the CSCs have been bundling up and shipping uuencoded 
    	patch files (even multi megabyte ones) for sometime now, but you've
    	got to watch it at the UUCP sites.  If you're going to put something 
    	out for anonymous FTP the person is most likely on the Internet and
    	large mail is not stopped.
    
    
             *********Now the Story behind the Rumor*********
    
    	We (at the CSCs (specifcially OSF&ULTRIX Support) ) can well understand
    	your concern about FTP from DIGITAL on the Internet  since 1 out of 3 
    	customer calls we take at the CSCs that need patches ask:
    	 "Where is your FTP site to copy them from, or can you E-Mail them?"
        this is what originally spurred us on!
    
    	Mike, Joe, and I have been working for some time getting
    	this project rolling, working with folks, examining security
    	walls (you've got to shield both networks from each other),
    	and finding our way thru the political landscape. 
    	(thats when we found Gail!!).
    
    	At the current time we are in the final phase of approvals and
    	hope to have it up in the timeframe Steve was quoting.
    
    	For anyone who has inquires please feel free to send them to
    	internet-patches@tsc.csc.cxo.dec.com (tsc::internet-patches)
    			Or
    	internet-patches@decatl.alf.cxo.dec.com (decatl::internet-patches)
    	
    	We've got a full proposal availalble (in postscript) and will be glad 
    	to respond to inquiries.
    
           						Jack
    

                    DECnet/OSI_for_DEC_OSF/1____________________________
                    End System Installation/Use

                    Part Number: AA-PVWTA-TE
                    March 1993

                _______________ Documentation Comments _______________

                If you have comments or suggestions for this book or
                any of the DECnet/OSI for DEC OSF/1 documents and if
                you have access to the INTERNET, mail your comments
                electronically to the DECnet/OSI writing group within
                Digital at the following address:

                              doc_quality@lkg.mts.dec.com

                ______________________________________________________

    
    .5>     so how can I send a file to a customer's system?  (Don't say
    .5>	    mail; these are binaries and sometimes are too large to send
    .5>     readily through mail when uuencoded.)
    
    	So, how do you propose sending those large executables to Digital
    	customers that are NOT Internet connected, but have dialup access?
    
    	There are several public domain packages that do the dirty work
    	necessary to send large binaries via email. My suggestion is to
    	grab one and learn how to use it. 

    Re: .7
    
    Jack,
    
    Please accept my apologies - Gail is the only one I've been in contact
    with about this.  I am grateful to ANYONE in DEC who is making this
    happen.
    
    Re: .9
    
    We ALREADY have this.  It's called DSNlink. 
    
    				Steve

Does anyone know what percentage of our customers have Internet access?  Would
these be our largest customers?  Small shops would be less likely to have a
connection.  How about DSNlink?

Often we assume everyone can get to the Internet, but I don't think that's true. 
This assumption makes customers without an electronic connection feel less
important.  I've read that in some of the Usenet newsgroups.

How about going one step beyond CD software distribution and send all our
customers a satellite dish pointing to a satellite Digital channel?.  Well, I
guess we could do this when the cost of a satellite dish is cheap.

Paul

    re: -1
    
    I'd guess at least 93-99% of our customers have Internet access. :) :) 
    Or maybe not.
    
    Personally, I feel Internet access and use is very much like VCR's and
    PC's.  As people (or companies) see the advantage, convienence, and
    connectivity offered by having Internet access, they'll get it.
    
    And yes, those without access probably do feel left out.  Companies
    also get pressured by comments such as, "great, can you mail the file
    to my account at xxx@xxx.xxx.xxx?  No?  Do you have UUCP or Fidonet
    access?  No?  Well, from Compuserve you can mail the file to me
    using...".
    
    My NT development skills would be months old if it wasn't for
    wuarchive.wustl.edu, ftp.cica.indiana.edu, and
    comp.os.ms-windows.programmer.win32.
    
    --- Gavin

RE           <<< Note 2471.11 by FUNYET::ANDERSON "OpenVMS Forever!" >>>
                            -< Internet customers >-
>>Often we assume everyone can get to the Internet, but I don't think that's true. 
>>This assumption makes customers without an electronic connection feel less
>>important.  I've read that in some of the Usenet newsgroups.

But they probably have a PC.  We could sell them a software package and
access to an 1-800 number.  We could sell them connect/space/CPU charges
for use of a central server and an internet mail client.  We could
make money as an "information utility" (aka service bureau).  But that's
probably too much of an '80s idea. Besides, there's CompuServe.  

MS

    There is no ONE right answer for all customers.
    
    For a huge and growing class of customers, Internet FTP is the obvious
    answer.  This is probably number one with a bullet.
    
    For a different but overlapping class of customers, a modem and a phone
    line is usable.  We internal to Digital often are unable to use that
    channel if our own vendors do, since our internal networks are set up
    to discourage it.  And it's slow.  But we can't ignore the customers
    who are condemned to such "kiddiecomms".
    
    For a very small and probably dwindling class of customers, few of whom
    are in the US, the best way is via X.400 mail.  We have product folks
    who still think this is real, but I don't know any users who take them
    seriously.

    
    
    re .11
    
    	from my experience most customers here in Germany ( and I guess
    	this is true for whole Europe ) even don't know how
    	Internet is spelled. Germany is lightyears behind with regard
    	to networking use. There are a few percent who are dialing
    	around using modems and there are some few other percent who
    	( don't ) know how to get through using cryptical X.400
    	syntax
    	
    	But I'm optimistic: Coke and Pepsi somehow crossed the Atlantic
    	and so will Internet some day ... :-)
    
    						helmut
    

    re .15:
    
    There are some German customers on the Internet -- I heard from one of
    them this week.
    
    					andrew

Commercial use of Internet is more common in the US than elsewhere in the
world, but even in the US it's generally restricted to the larger companies.
Most Internet users are at educational institutions (colleges and 
universities), and there are many of these in Europe.  I have corresponded
with customers in Egypt, Norway and even Russia!

Internet access is not a panacea, though providing services via Internet is
an inexpensive and effective option for a subset of our customer base.
I do expect that more of our customers will gain Internet access in the
years to come.

				Steve

    Re .11
	"Small shops would be less likely to have a connection."
    
    Actually, you'd probably be surprised at the number of small shops that
    have internet access.  It turns out that it can be MUCH cheaper to hook
    your PC into the internet (say via MV.COM in New Hampster) than to hook
    into one of the services such as Compuserve, if what you want it for is
    world wide communications, etc.

    I know many private individuals (soon to include myself) that do this.

I think that it is changing very rapidly.

MOST of the customers I have dealt with lately, from multi-billion $$
corporations to small biotech companies with a total IS staff of ~20
have some sort of Internet access.  For the smaller ones, the full Internet
licensing fees are too steep to justify, so they'll go a cheaper route - 
UUCP, or indirect Internet access through one of the service bureaus which can
be found in most any major US city. (not sure about European access, so I won't
make rash claims).

We must NOT be perceived as being behind the curve on networking.  If a client
is savvy enough to navigate the Internet and starts wanting to exchange
information (assuming a legitimate request), we must be ready to respond.

Kevin

    Re .6:
    
    How can I make files available on gatekeeper?  Can anybody just log in
    and create directories and put files in them?  Are there separate
    accounts for those who will put files on gatekeeper?
    
    
    Re .8:
    
    Sending comments is one-way communication.  That is nowhere near the
    benefit of sending electronic mail to a company with a problem or
    question and getting a response within 24 hours.  I know; I've done
    business that way.  It's easier to convey technical questions in
    writing than by phone, but electronic mail is faster and more
    convenient than physical mail.
    
    There's a million and a half sites on the Internet, with at least tens
    of millions and perhaps a hundred million people with access.  Digital
    should have a publicized server where customers can look for patches
    and other information.  A dark system where files can be retrieved only
    if the name is known is a start, but that serves only customers who
    take the initiative to get something put on the system for them.
    
    We should seek out the customers, not the other way around.  Invite
    them to see what we have.
    
    
    				-- edp

    
    
            Re: .10
    
            We made assumptions that got us in trouble. DSNlink for VMS can
            ship patches. The last time I checked, DSNlink for ULTRIX could
            not. I understand that a future version of DSNlink for ULTRIX
            solves this problem.
    
    
            Re: .11
    
            From my viewpoint (the CSC), our largest customers have Internet
            connections, smaller customers use a service provider like UUNET
            (Internet to UUNET, dialup to the customers), and the smallest
            ones are more than willing to set up a dialin line if the cost
            is "worth it." An 800 number is the answer for these people.
    
    
            Re: .14
    
            The proposal Jack, Mike and I are working on covers our Internet
            connected customers as well as our non Internet customers. Our
            target is to cover as many bases as possible with the service.
            Obviously, the first service offering is ftp based, dialup will
            be available in the future.
    
                                                                       

    re .20
    >    and other information.  A dark system where files can be retrieved only
    >    if the name is known is a start, but that serves only customers who
    >    take the initiative to get something put on the system for them.
    
    >    We should seek out the customers, not the other way around.  Invite
    >    them to see what we have.
    
    Actually that is EXACTLY what is happening.  With the CABs (Customer 
    Advisory Boards) that Gail has been running for years (I believe)
    just this kind of information has been gathered. A number of surveys
    on the Internet (via newsgroups) have asked just these questions as
    well, resulting in a MASSIVE  "Y*E*S" to such a proposal.   Be assured
    that we won't just "pop a couple dark systems on the Internet" for
    folks to search out. And then only the luck will find them, as is
    the rule of thumb when looking for FTP sites.
    
    RE.   Access to the internet possible/cost-effective?
    
    	In the past 3 yrs I've been AMAZED how connectivity charges have
    	DROPPED. In Colorado you can get UUCP, SLIP, or PtoP for costs
    	individuals can afford. One our our teammates recently paid $200.00
    	initial charge for a namespace from Colorado SuperNet, and pays a low 
    	monthly fee based on usage to be a subnet ON the internet (via pd SLIP
    	for his PC) and the monthly charge totals up SIGNFICANTLY less then
    	like usage of Compu$erve.
    
    

   Re: .22
   
   It seems many universitys are trying to augment their incomes by
   offering Internet access via their systems.  OSU offers a wide range
   of services on its OARnet.  For individual dialup access the cost is
   $100 for installation and $4/hr connect time (min. $40/mo).  Local
   call service is available in 5 major cities, "950" service is
   $10/hr, and "800" service is $12/hr.
   
   They also offer dedicated line services including low speed sync, T1,
   10 Mbps, and 45Mbps.

OSU=Ohio State University
5 cities = Columbus, Cincy, Dayton, Cleveland and ??

     re. 24
    
    that ? is Akron.
    
    Ken
    

     On the general issue of keeping abreast of network technology, using it
internally and giving access to customers, DEC has lagged quite a bit from its
former stature (although it appears it's regaining some ground through the
efforts of Callaghan, Grant, etc.).

     DEC hardware dominated in the early days of the ARPAnet (10s and 20s
running TOPS-10 and -20 with DEC or BBN ARPAnet support, 11s used as network
interfaces; then, later, VAXen running BSD).  The combination of DEC's presence 
on the ARPAnet and its explosively growing internal DECnet network made it very
visible to (and respected by) those in the know (at least those not stuck on
IBM's hiercharchical network architecture).  In the early days of the
commercialization of Ethernet, DEC dominated for some time in the number of
installed nodes. 

     But DEC was already beginning to lag, as the network market splintered.
Apollo did interesting things with high bandwidth token rings that DEC still
hasn't caught up with (maybe as Mach technology is incorporated. . .).  Pr1me
came out with their primitive-but-effective token ring before DEC came out with
clusters.  ARCnet, with its lower-than-ethernet interface cost, began to
dominate on the low end.  DEC's dominance on the internet waned as Sun and
Apollo took off.  DEC missed the boat WRT terminal servers and terminal
protocols.

     DEC failed to participate in any meaningful way in the PC network
revolution.  DEC purposefully ignored the explosive growth of TCP/IP and
related protocols as de facto standards in the late 80s (I can remember being
told that TCP/IP was counterstrategic, we're supposed to be selling DECnet -
I had never heard this neologism before NAK, I mean NAC started using it).

     But this is all water under the bridge.  I think DEC is frantically trying
to catch up in areas of networking and fairly aware now of the mess that's been
created.  In some areas, DEC is even trying to anticipate the market (consider
the ISDN interfaces present on many new DEC boxes).

     I appreciate your sentiments on this, Mr. Postpischil, but I think you're
late on the call.
							curmudgeonly,

								Robt. P.

	edp mentioned a few notes that it would be neat if rather than "just a 
comment address" customers could submit technical questions and receive answers
within 24 hours. 

	How does a few minutes strike you?  The CSC through DSNlink for VMS and 
DSNLink for ULTRIX (and DSIN for those who are secure sites and cannot have 
an outside system dial them up) has been answering questions this way for years.

	DSNLink also allows customers access to our solutions database, so they 
don't even have to wait a few minutes for a reply, they can look up solutions 
themselves.  

	DSNLink for VMS also allows them to pull patches.  (DSNLink for ULTRIX 
isn't there yet, but as mentioned, it'll get there.)  We're WELL aware that 
network distribution of patches is cost effective.  (If we cut a patch tape
or disk to send to a customer, the cost is about $81.  If SSB sends it out, it
costs about $18.  If pulled over DSNlink, cost is about 81 cents!)  

	Perhaps you should get some information about DSNLink (1-800-332-8014)
before lamenting any more that we don't do these things.  

Tracey 
US CSC
PATHWORKS for DOS(TCP/IP) and eXcursion support

Re: .27

Good for VMS customers.

ULTRIX customers may benefit some day as well, apparently.

Nothing for PDP customers (don't know how important that is, but... ;-).
Nothing for OSF/1 customers. Nothing for DOS/Windows customers. Nothing 
for OS/2 customers. Nothing for Macintosh customers. Nothing for SCO UNIX
customers. Nothing for Windows NT customers (for some developers now and
others later).

DSNlink needs to open up for customers regardless of the hardware and
operating system they've bought from us.

...petri

    Re .27:
    
    I know about DSNLink.  It's not what I asked for.  It's like the whole
    world has got telephones installed but you are still using tin cans
    with strings.  Golly gee whiz, how wonderful for you.
    
    Actually, it is good that the customers can query the database for
    themselves, but Internet provides advantages that dial-in access does
    not.  For one thing, its a common network that a rapidly growing number
    of people have access to and use regularly -- When we get a customer,
    it would be better if we make information available via the means they
    are _already_ using rather than making them learn a new way to deal
    with Digital.  Second, I can write up a message with questions and
    technical information and mail it off to a vendor on Internet and then
    go on to other work.  I don't have to hassle with setting up a modem,
    dialing, logging on to their system, working through its menus,
    transmitting the file via whatever details the file transfer requires,
    et cetera.
    
    
    				-- edp

	edp,

	Apparently you *don't* know about DSNLink.  DSNLink for ULTRIX uses the 
internet as it's communication medium!  And DSNLink for VMS does not require to 
you to dial up and all that mess that you said every time you submit a problem.
Setting up DSNLink is a one time proposition. (Sort of like setting up your 
initial connection to the internet. :-) )  Once you are connected, to submit 
a problem under DSNlink, you simply send electronic mail to a special address.  
Acknowledgement of receipt of the problem (and later the solution or a request 
for more information) is sent via Electronic mail to the account from which the 
problem was sent.  Which is precisely what you say you want! 

	As for Petri's point about the limited number of platforms upon which 
DSNLink is supported.  I whole-heartedly agree.  There need to be more supported
platforms.  And from what I can see, there will be. However, I am not at liberty 
to discuss "futures".  But right now, *Most* of our customers who have these
systems also have one or more VMS or ULTRIX machines that they can do database 
lookup, problem submission and Patch requests from. We have lots of folks who 
pull DOS, WINDOWS, and OS/2 patches through DSNLink for VMS.    

	I'll be the first to tell you what drawbacks there are in DSNLink.  It's 
not a cure-all.  No one method can be.  But it does address a need in an 
efficient manner for a large segment of our customer base.  

Tracey 
US CSC

    Re .30:
    
    > Which is precisely what you say you want! 

    The customer requested the patches be made available over the network. 
    _Exactly_ what should I do and tell them at that point?
    
    				-- edp

    re: .-1  (what should I do now)
    
     it strikes me that your customer wants a commodity service: "I want
    patches 7 x 24, over the network"
    
       OK. Get a dedicated modem ($200-400), and use DSNlink (we do).
    Access your brains out. Most customers are pretty happy at this point.
    
       Additionaly, if customer wants patches to work in their specific
    environment -- well, that's what we call System Integration Services...
    and any consultant can do that for the customer at a variety of prices
    (hint: it costs more than the dedicated modem, or any of their
    employees). I recommend a *good* *clear* *Specific* contract be
    constructed first, however.
    
    Bruce Evans

    Re .32:
    
    Telling the customer to buy more equipment and run more software so
    that, after the few weeks it takes to accomplish that, they can then
    access the patch they need now is not the right thing to do.
    
    The customer's on the net.  Digital's on the net.  We've got a patch
    for a problem that is supported under the contract we have with the
    customer.  The only thing preventing us from getting that patch to the
    customer quickly and in a manner that would please the customer is
    Digital's obstinacy.
    
    That's a problem.  It should be fixed.
    
    
    				-- edp

    Re: .33
    
    Eric, it IS being "fixed", as has already been explained in this
    topic.  What more do you want?  Who is being obstinate now?
    
    					Steve

    re:.34
    Oddly enough, I sympathize with edp in this topic.  He has identified a
    problem and proposed a solution.  Other replies have used typical
    Digital management doublespeak to explain that we're doing something
    that's as good, sort of, and even better, and only takes a little bit
    of getting used to, and of course there are some O/S dependencies but
    hey everybody can use a little VAX, etc. etc.
    
    Fixed:  J. Random Customer, with autorization, can use any old FTP (not
    a specific product) to connect to a given Internet node and grab up a
    patch.
    
    Not fixed:  J. Random Customer needs a modem and a phone line to run
    some kind of kiddiecomms program, or a leased line to Digital or a
    Digital-selected third party carrier, or can only access the patch via
    some kind of magick program running on his computer which makes some
    kind of weird connection to something hidden...
    
    I for one, as a reader of this note, do not see the answer.  I am
    very knowledgeable about networks and have no idea from this topic
    what this DSNlink is doing.
       confused_too

Unfortunately DSNlink for ULTRIX does not exist in Europe.
Quite frankly, I am not so sure that it should....

Everybody else in the computer industry just uses Internet and
ftp and mail, to distribute patch etc... But For Digital there is
allways the NIH syndrome, and so we invent different proprieatry tools
such as DSNlink...

	Pekka

    Re .34:
    
    When the problem is fixed, I will no longer say it needs to be fixed.
    
    
    				-- edp

    I think you should give DSNlink a break, the concept is few years old,
    when it started, Internet was not at all as spread as today.
    Things has changed and maybe Internet should replace it whenever
    applicable ( that is, customer wants that).

    				Not a scratch monkey.

It is not true that everybody else in the computer industry just
uses the Internet.  A very significant market segment (perhaps the
most significant) uses private bboards (analogous to DSIN) and 
public-access networks, like CompuServe, for this purpose.  Microsoft
(one of the larger software houses, for those who haven't heard of it)
uses ordinary telephone, automated FAX, and CompuServe; they don't
use Internet.

In the mean time, as indicated in .7, mailing large uuencoded patch
files is quite doable.  Another option is to get the local field person
(sales/services rep) to pick up the patch and hand deliver it, but this
requires building good teamwork with the field.

Also, as indicated in .7, people in the right organization have
taken responsibility for providing FTP access to patches.  Engineerings
job is to get out of their way, and focus on getting the bugs out
so that the patches wouldn't be required in the first place.

   Gary

    re: .39
    
    I dunno about Microsoft not using Internet.  Maybe I misunderstand the
    statement, but my brother works for Microsoft and we exchange e-mail
    all the time over Internet.  I've also exchanged mail with others at
    Microsoft over Internet.  Has Internet headers and postmarks at the
    bottom and everything.
    
    Steve

re: .40

That's the same usage as we have here.  Employees are allowed to
send and receive Internet mail.  However, Microsoft, as a matter of
general policy, does not make patches available on the Internet, nor
do they provide Internet addresses as an official support mechanism.
Individual Microsoft employees may act as if they are providing 
support, just as individual Digital employees do, but these are 
unofficial channels.

   Gary

>public-access networks, like CompuServe, for this purpose.  Microsoft
>(one of the larger software houses, for those who haven't heard of it)
>uses ordinary telephone, automated FAX, and CompuServe; they don't
>use Internet.

	Not quite true, MS uses internet at least for some of the NT
	related stuff (rhino.microsoft.com comes to my my mind).

	Anyway even if PC-industry, does not use internet, It is no
	excuse for Digital not to use it. All other UNIX vendors do.

    It sounds like a sequel to "A Tale of Two Companies".
    
    Another company might stick another disk on Gatekeeper, or put another
    machine next to it if necessary, and allow product support groups to
    upload things to it.  Digiboard has such a machine; I got a download of
    their microcode update that way.
    
    Digital, on the other hand, requires a phase review for the generation
    of a project plan to generate the program to generate a personnel
    requisition for a manager of hiring the department to study the options
    for the potential of creating a server that would be able to connect to
    the Internet.  But of course each step requires a VP's signature, which
    won't be granted unless......

    re:  Note 2471.39 by TLE::TOKLAS::FELDMAN
    
>                       Another option is to get the local field person
>(sales/services rep) to pick up the patch and hand deliver it, but this
>requires building good teamwork with the field.
    
    Sorry, but this isn't an option anymore. There are few enough people
    left in the Field, and getting fewer in a couple of weeks.
    
    Geoff

    It seems that few understood what Jack Callaghan was describing
    in .7 as "coming soon".
    
    To quote from .35:
    
    >Fixed:  J. Random Customer, with autorization, can use any old FTP (not
    >a specific product) to connect to a given Internet node and grab up a
    >patch.
    
    This is EXACTLY what Jack was referring to.  I have a copy of
    the "project plan" for this, an FTP-accessible Internet patch
    service run on dedicated systems with 24x7 availability, with
    "patches" (which can include complete replacement kits) provided
    by Engineering through the current DEC STD 204 process (I've submitted
    two Fortran kits through DEC STD 204 already, and it's a breeze.)
    
    Coming soon, to an Internet near you...
    
    						Steve
    
    

    re: Microsoft and Internet
    
    Microsoft faces the same kind of pressure from its customers as Digital
    does.  Developers are clamoring for "official" Internet support -
    perhaps one third of the crowd at a large seminar I attended in March
    asked for it.  In addition, Microsoft makes much of its base of
    Compuserve files available via ftp at node ftp.uu.net, along with many
    other hardware and software vendors.
    
    Some patches and updates from smaller vendors (for instance, in the PC
    world, ATI Technologies video card drivers) are "informally"
    transferred from company BBSes to Internet ftp archive sites with at
    least tacit cooperation.
    
    The point of this is, I guess, that deliberately or haphazardly the
    Internet has become a business tool for customer satisfaction at many
    companies.  Online access in general is now a preferred method for many
    business transactions beyond getting patches.  It seems to me we should
    be pursuing all viable channels of communication aggressively (not so
    indicated in previous replies) and people involved in the
    bugfix/upgrade process should understand well how to use them (the
    thrust of the basenote).
    
    Wes

    Can customers send QAR's to Colorado to internet today? If so what
    is the address? If not why not? 
    
    Can Colorado send patches to customers today on the internet? 
    
    Thanks, 
    
    JOhn

       <<< Note 2471.47 by AOSG::NORDLINGER "DTN-381-2894, ZK3-3/W20" >>>

    >>Can customers send QAR's to Colorado to internet today? If so what
    >>is the address? If not why not? 
    
    >>Can Colorado send patches to customers today on the internet? 
    
    I work at the CSC. First we don't support field test, which is what
    QARs are for. I have FTPd patches to customers before, works well.
    
    Some of our documentation(Rdb/VMS for example) now include an internet
    address to send comments to, something like doc@weorg.enet.dec.com, I
    don't remember. This address is published right at the front of each
    book.
    
    Simon

Simon,

Can a customer send an electronic SPR to an internet address?  Will it become a
'real' SPR?

Bob

    <<< Note 2471.49 by ROWLET::AINSLEY "Less than 150 kts. is TOO slow!" >>>

>>Simon,

>>Can a customer send an electronic SPR to an internet address?  Will it become a
>>'real' SPR?
    
    good question. 8-) Not that I know of. The reason for that is that SPRs
    do not go direct from the customer the engineering group. First they
    come to the CSC. The reason being a lot of SPRs are issues that can be
    fixed by the CSC. Now, if after the customer has worked with the CSC
    and we've detirmined its a product problem and an SPR is in order, the
    CSC does all the work. EASYNET is used to talk to the different call
    handling system.
    
    The only place this system fails is paper SPRs. The SSB stopped sending
    out paper SPRs years ago, but still a few are received. These are
    routed to a group in Atlanta, who type them into the CSC call handling
    system. The SPR is then handled like any other SPR, ie if we can fix
    it, it never goes further. If it is a product deficiency, off it goes
    to the product group.
    
    Now, where can Digital do better electronically,
    
    o Log CSC calls over Internet
    o use automated attendent services to get SPD etc
    o use automated ELF to reply to directory enquiries from Internet
    (include contractors etc in ELF, within a few years ICL will be 30%
    permies, 70% contractors)
    o allow inbound FTP traffic
    o make DECWRL, VBOMRC, DECPA etc supported by central money
    o send PAKs etc over Internet (Europe does this already from Galway)
    o software distribution on demand over Internet
    o packaged product demos over Internet
    
    I think you'll find all the above are happening in individual corners
    of the company, I'd love to see a big pool of money swish down and copy
    these implementations to every corner of our busines.
    
    Simon

    EFT sites can and do send QARs via the internet, directly into the
    appropriate QAR database.
    
    --Scott

    RE: .48  ... at a tangent ...
    
>    I work at the CSC. First we don't support field test, which is what
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    QARs are for. I have FTPd patches to customers before, works well.
    
    
    I well understand the fears of being involved during FT with customer
    sites - but I must confess to be mystified at the reluctance and
    short-sightedness of management over this sort of statement.
    
    We work very hard to get products created.  We hear lots of complaints
    about products not quite meeting the mark in this way or that,  of the
    CSCs not being ready to support or willing to take the risk of being
    involved in FT,  etc.  Every time in the last 9 years I have been
    involved with FT I have been aware,  most time,  of a reluctance for
    the CSC to commit to active involvement in a FT.  We hear semantical
    obfuscation about the involvement,  on the one hand pleading poverty of
    resources,  on the other strongly protesting "it's not my job" or "yes,
    we will" with the unspoken condition of "best efforts only",  and maybe
    eventually (if pushed) an apologetic "Sorry, the resource has had to
    deliver on other things on a higher priority".
    
    We must break this cycle.  If *** ALL *** the CSC management would make
    the decision to take an active role in FT and fund,  as part of ***
    THEIR *** investment in *** THEIR *** business,  a resource to partake
    in the FT process - it could make a significant difference to the way
    the business goes.
    
    I am not asking that all products get the same treatment for the whole
    period of each FT.  There is a time when it would be most helpful for
    them to pick up the kits and even to pilot the support for the product
    with a selected customer in their own Geography/Territory who is also
    doing the FT.  That active involvement would do a lot for ensuring that
    the boundaries for the product are well defined as well as ensuring
    that the product is supportable by the field.
    
    A simple routing of all Customer QARs through each CSC for
    acknowledgment,  filtering for those that can clearly be answered
    locally and a forward transmission on to the proper engineering QAR
    database of all problems would do wonders for some products.  For a
    start it would help to make the boundaries of confidence / difficulty
    in the product musch clearer to the field and then they would have real
    authority in making some of the necessary statements about what needs
    to be done.  How many times do we hear of Engineering making the
    decision to defer the resolution of a problem to "fixed in the next
    release" to then see a service issue rapidly arise after SSB
    distribution is well underway - an issue which would have been
    highlighted by more service involvement during the FT.  The answer to
    the question "why did they let it happen?" is quite simply that lack of
    field data and field analysis did not let them make any other decision.
    
    Yes,  the network is there,  but as pointed out elsewhere,  it needs a
    high level mandate to change the policy,  practice and funding.  That
    will not take place until the troops put together the evidence that
    shows, across the corporation,  A.  money is being lost and, B. that
    more money could be made.  A way to start that is for the Entrepreneurs
    amongst you to take the risk and make it happen locally.  If you
    succeed,  no matter what sacred business policy or practice is
    violated,  then you will start to make the change you want to see.
    
    As for using the network,  it should not be too difficult.  If the
    business unit is prepared to take telephone call,  since it is prepared
    to publish it phone (electronic) number,  there is every reason why it
    should establish an Internet Address and an X.400 address to the same
    customer base.  How many of you have struggled to record the customer
    problem over the phone and then pass it on accurately?  By requesting a
    mail input (having provided the format for product problem statements
    as a file on the distribution media) the customer can be reasonable
    expected to shoulder the cost of making a good problem statement
    without calling upon the DEC specialist to spend time as a secretary!
    (Even a typewritten FAX can be processed with a CSC based OCR system
    and then sent on.)  Do you really need senior management to authorize
    that?  It can be down the individual specialist just making it happen
    and then the group standardising on it's practice to maximise it's
    efficiency,  productivity and to excel in the quality of service (but
    don't excel too much - it just needs to be one point better than
    elsewhere to be effective!).
    
    So,  why not be the first to make it happen?  You will then have a job, 
    a real job with security - because it generates direct revenue.

    re .51 - I would like to know more about this (QARs direct from
    Internet to database) - can you send me a pointer off-line? 
    
    Thanks,
    Chuck Schneider

	Same here please..

						mike

    
    ditto on the QARs into the database via Internet, this should be
    standardised into all QAR systems out there. If you want to look at the
    best QAR system (IMHO) look at Rdb's, it sends mail when something
    happens to 'your' QAR. No logging in and periodically checking.
    
    answering the slight rathole on the CSC doing FT, as a specialist I
    agree! We could prevent a lot of the calls coming into the center after
    SSB ship by recognizing FT as the investment, core work that it is. As
    specialists I can tell you we are flat out busy! Finding time to do
    FT work, while making sense, would have be sanctioned at a higher level.
    
    The CSC is moving to self-managed teams. What this means is if the
    team, usually based around a product, decides to do something, they don't
    need a lot of approvals. So perhaps the DECsquidywidgy team will decide
    to some FT work?
    
    Simon

    I recently got my own access to the Internet through an outside
    company. It costs $6/mo, plus about $4/hr to use. Any terminal and
    modem can be used to access (i.e. I have my own Rainbow and Scholar).
    
    I do not endorse this or any other access company specifically, but I
    am determined to keep my access to the Internet now that DEC is clearly
    on a campaign to restrain communications between employees and the
    outside world. This is, of course, a futile attempt in this day and age
    of the enet, and access to Internet is important to most people in the
    industry.
    
    Send me private mail if you wish to get the phone number to the access
    company I use.
    
    
    ken
    

    re: .56 outside companies offering Internet access
    
    Discussed in UPSAR::GATEWAYS

> now that DEC is clearly
> on a campaign to restrain communications between employees and the
> outside world.

Huh? If anything, there's been a dramatic improvement in our Internet
access in the last few years, thanks in large part to Brian Reid, Paul
Vixie, and others at NSL in Palo Alto, but also thanks to a Corp IM&T
organization which was once reticent, but which has come to see the
value of this facility, and actively supports it (though there are
undoubtedly some Luddites in the crowd).

It can never move fast enough for some people, but I haven't seen
evidence of any recent campaign to restrain communications. I suggest
that if you want specific details on what kind of access is restricted
and why, that you contact Paul directly. He's one of the "good guys"
who has worked long and hard to improve the situation, while seeing
that Digital's genuine and perceived security needs are addressed. We
may not be as open as the average university, but you should check out
IBM's restrictions if you think we're in the stone age in this area.

         The network group here in LKG2 which is responsible for field test
    and releasing products, has a QAR system which allows users to enter
    problem reports over the internet.  This system will allow the user to 
    enter a new qar, or add to an existing qar or just do an inquiry to the 
    database.  What happens is a customer will receive an account on the QAR 
    system and will receive three different forms which they can use depending
    on what type of transaction they would like to perform.
            The enter forms for internal and external differ in the user
    profile information area. With an internal user the form asks for cost
    center, dtn, mailstop, enet mail address and the name and location of
    the test machine.  Where the external form will ask for the company name,
    full address, contact name and phone number, local software specialist name
    and phone number, and the local Digital software services office.  The
    forms also ask information about the qar that is to be entered and about the
    system that the user is having the problem with.  Once all of these
    questions have been answered then there is an area where the customer can 
    enter their problem statement.
            The append form asks the customer for the user name, their full
    name, database, and qar number.  Then again the customer has an area where
    they can enter their problem report.
            The Inquiry form will ask for all the information that the append
    form does and then the type of inquiry to perform.  The customer has a
    choice of dir or read.  A dir will do a full listing of the data base qars.
    The read will only read the qar number that the customer specified.
            Once the form that the customer chose to fill out is complete the
    customer can then use electronic mail and send it through the internet to
    the qar system to an account called QMA (Qar mail access).  The mail
    message will then get parsed and the qar will get entered into the
    database.  When the qar gets entered the customer receives a mail message 
    stating that the qar was entered successfully.  The maintainer gets 
    notified that there is a new entry in the database for him or her to look 
    at.  When the maintainer responds to the qar a mail message will be sent 
    back automatically to the customer notifying them that there is a response
    to their qar and what the response is.  If for some reason there is some 
    type of error the qar manager will be notified by mail that there needs to 
    be some type of user intervention.
         Once the customer has used the system they have had no problems and
    seem to like the ease and notification that the system gives them.  If 
    you would like to know more about the system let us know and we can
    discuss it in more detail.
    
    John

	Re: Chris's comments about the CSC refusing to participate
in field test. 

	I'd like to point out that the short-sightedness is not 
always on the CSC end.

	There have been times that we have BEGGED to be involved, 
we've even asked to provide support to customers who are running
field test.  We've gotten push back not only from our management 
over funding issues (a reasonable fear in these times), but sometimes
from *engineering*.  I don't know why, they apparently didn't trust us.
There have been times that we decided that we could afford the time to 
have some involvement in field test and Engineering has refused to 
keep us even up to the level of code that external customers have.  
No point in us testing and QARing code two or three baselevels old... 



	I am *thrilled* to say that I'm the project leader of a group 
that is not only field testing but doing the acceptance testing on a 
new product.  The engineering group has been working closely with the 
CSC for the past year or so and there is trust and cooperation there.
When the time came for Engineering to spend the money allocated for 
testing, they approached us, for the very reasons you cited.  (I.e.
we KNOW what we'll get calls on.)  We accepted for the very reasons 
you cited. (I.e. we can help keep those call producers from ever 
shipping AND we get familiarity with the product and common issues 
ahead of time.)  

	It's only a drop in the bucket, but our district is using this 
as a pilot to show other Engineering and CSC groups that this can be 
successful.  (And Oh by the way, it looks like we'll end up being 
cheaper (perhaps considerably) than the "traditional" testing channels.)


Tracey 
US CSC

    RE: .-1
    
    Well,  the end result is a refusal,  because there are so many things
    that get in the way of making the investment.  As you quite rightly
    point out,  there is often the willingness on the part of individuals
    or even groups,  but making it come together is another matter.
    
    You are entering a new era in Digital.  The "supply chain" is shorter. 
    Do work hard to establish the confidence between yourselves and the
    engineering groups.  They look to see you add value to the FT process. 
    If you can demonstrate that,  then you can change the scene.  
    
    Too often in the past,  the groups who wanted to help made too big a
    demand of engineering,  even to the point of creating excessive costs
    by confusing the customer who then regarded them as incompetant, 
    besides demonstrating their own inadequacies internally to the
    engineering group.
    
    They have also found themselves constrained by management who demanded
    that they pay all attention to other customers and delivered on the
    three-month budget deliverables,  demonstrated that they had got the
    right call statistics,   etc.  i.e. did not count FT work as part of
    the budget.
    
    Now if you can change all that for the better,  you can look forward to
    a better scenario for all,  including the customer base!  I wish you
    well on your efforts,  but sadly will not be here that long now to see
    them bear fruit.

    The Rdb Team here at the CSC is maxed out just taking calls on released
    versions of Rdb.  I wouldn't mind supporting Field Test releases.  We
    just don't have the people.
    
    BTW -- I've been sending in SAO's when I get calls from customers
           without Rdb on their list of supported products.  Maybe, if we
           could just get the freeloaders to pay their share or stop them
           from calling, we could either add headcount or have the time to
           support Field Test.
    
                                         Kurt

    It todays world, not answering "freeloaders" is losing customers.
    Not blaming you Kurt, pissing off paying customers is even worse,
    just the management without imagination. 
    There mustbe a more or less reliable channel for people out of support
    like third  parties developing or managing our products.

    We should be glad and encourage by the fact they use the products. 

    There is just no other way, this is how big boys do it.

           <<< SOFBAS::NDISK:[NOTES$LIBRARY]INTERNET_TOOLS.NOTE;1 >>>
                              -< Internet Tools >-
================================================================================
Note 526.0          Commercial Internet Gateway at Colo Spgs           3 replies
CSC32::CALLAGHAN "Internet Roadhouse Bartender or G" 17 lines  19-APR-1994 18:21
--------------------------------------------------------------------------------
                                  ---{*}---
                           -------------------------
    
    	              Commerical Internet Gateway Service 
                             At Colorado Springs
    
                           -------------------------
                                  ---{*}---

  This note will contain all info on this Commercial Internet Gateway service.
                                         
    Gateway Admin:  Mike Temkin    (tsc::mst)
    		    Jack Callaghan (tsc::jack)
            Phone:  719-592-5279 (DTN 592-5279)
    	     Mail:  Problems/Requests-> gw-admin@service.digital.com or 
                                        TSC::GW-ADMIN
    	            Information->       info@service.digital.com or TSC::INFO