Conference 7.286::digital

	I can EASILY communicate with my brother-in-law in HOUSTON who
	works for AMOCO anc occasionally has a Digital Equipment Corporation
	question, e.g. does ULTRIX do??? etc.

	To communciate with ANYONE on CompuServe, is equally E-A-S-Y.

	The NECESSARY part is the correct address.

	Unfortunately, VMSmail, ALL-IN-1, etc. do NOT transpose incorrect
	addresses as well as, dare I say it, the United States Postal Service.

	Computers, ours and THEIRS, are very unforgiving MACHINES.

Al

If your customer has access to Internet, you can be reached at
	person@node.enet.dec.com
where "person@node" is the way the rest of the world writes the
VaxMail address NODE::PERSON.

You can send mail to your customer by
	DECWRL::"customer@whatever..."
where the text in quotes is your customer's Internet mail address.

This is quite sufficient for most use. The one exception is file transfer,
which is restricted to prevent folk on the Internet from snarfing files
off of our systems.

Martin.

re .1

Yes, I can very easily send mail most days.  I simply can not base my business 
contacts on a link set up and supported out of the goodness of an engineering
groups heart.  I simply want an organization (DIS?) to take ownership.  Have 
you tried to send your "brother-in-law in HOUSTON" mail over this past weekend?
We were off the net for DECnet for about a day, and are still off for IP.
Do you do it from a UNIX environment?  Has he had any trouble with aliasing from
his end as we change addresses names when you change account names or nodes?  I 
do not find my world simple enough where I use only one account on one machine.
I can not depend on forwarding even within my company.

I find the substitutions required for sending mail to CompuServe NONtrivial to 
determine.  For example:
user 123445,6789 as a CompuServe ID becomes 12345.6789@CompuServe.com
Why can't we support the ,?  How do you figure this out the first time unless 
you happen to try making random substitutions?  Naturally, we use a different 
format when the CompuServe user is part of a group with CompuServe being the 
mail service for the whole organization.  Then the same person is:
12345.6789@org_name.CompuServe.com.  It is not intuitive who uses CompuServe
for personal use and who is using it as a company outsourcing service.

>	Unfortunately, VMSmail, ALL-IN-1, etc. do NOT transpose >incorrect
>	addresses as well as, dare I say it, the United States Postal Service.

If you include our UNIX (tm) mail products like our .mh, then yes it does.  
I do not want to make this an operating system battle, I just want someone to 
take ownership of this company infrastructure as someone has with facilities, 
USPS mail, shipping...


re .2

You assume we use VAXMail as a common protocall here.  We do NOT.  We are a 
typical UNIX (tm) shop.  You should also notice that the example you use:
>   person@node.enet.dec.com
>where "person@node" is the way the rest of the world writes the
>VaxMail address NODE::PERSON.
breaks the corporate security guidelines about using nodenames.  I happen to 
think the people coming up with these guidelines know very little about 
computer security, however, that notion is covered in another topic.

I do not want to allow "snarfing," I do wish to have the ability to send files 
around the net.  Have you tried sending DECwrite files to a customer?  I 
find it difficult.  Perhaps because I am stupid, but there is certainly little 
in man or in DECwrite help to give me clues abut making this easy.

    If it's a formal, managed Email facility that you want, check out the
    Digital Telephone Directory, Electronic Mail Service, External
    Communication Services, MTS/X.400.

    X.400 works quite well for communicating with customers, is a formal
    business arrangement and the addressing is specified in a standard.
    I have found this to be a very reliable means of communications and the
    internal support is excellent.
    
    This service isn't suitable for transfer of non-ACSII files however.

    Why can't you use the , is a compuserve address?
    
    	1) because it violates RFC 822.
    	2) because the people you operate the compuserve gateway don't
    	support it
    
    

>You assume we use VAXMail as a common protocall here.  We do NOT.  We are a 
>typical UNIX (tm) shop.  You should also notice that the example you use:
>>   person@node.enet.dec.com
>>where "person@node" is the way the rest of the world writes the
>>VaxMail address NODE::PERSON.
>breaks the corporate security guidelines about using nodenames.  I happen to 
>think the people coming up with these guidelines know very little about 
>computer security, however, that notion is covered in another topic.
    
    That's topic 174.  Actually it's only the Company Identity Policy that
    prohibits node names on business cards.  While security was purported
    to be the reason for that guideline, all the security experts who have
    written in this conference and the conferences devoted to security say
    that it is NOT a security exposure.  It is not a corporate security
    guideline, but a company identity guideline, that says thou shalt not
    print node names on business cards.  Further discussion probably
    belongs in topic 174.

    I communicate with a number of people in my account (customer types).
    
    Some are on VAX and use VAXmail, some are on IBM and use PROFS.  I
    happen to use All-In-1.
    
    The 'mechanism' used is X.400, as described earlier.  It makes no
    difference what mail system on what platform is sending to what mail system
    on what platform, the X.400 system and the various mail agents take
    care of the conversion.
    
    	-Barry-
    

    Sending a customer a DECwrite file (or any other binary file) would
    require direct FTP access.  Because of the sensitivity of the
    information stored on our net, I for one, definitely would not want
    outside parties getting into the Easynet.
    
    If you need to send a DECwrite file, uuencode it, mail it the client,
    and have the client uudecode it.  The reverse is also true.  Is it
    timely?  Last week I tar'ed, compressed, uuencoded, and mailed 8MB
    worth of a clients benchmarks to the Easynet (I consult to another
    division of the client).  Sales Support received the files in less than
    2 hours, and had the files accessible to our engineers.  The benchmark
    runs (on the ALPHA OSF/1 platform) may generate *major* amounts of
    sales to our client.
    
    Overall, in the last 18 months I've seen the mail and remote FTP
    service get a lot better (and I've learned how to do a lot of network
    "tricks"), and have experienced the lag-time for electronic mail
    diminish.  The guys (and gals) that manage DECWRL, DECPA, and the
    message concentrators deserve applause for their efforts.  I understand
    that some of our gateway services are not funded per se, and that I
    would like to see changed.
    
    I agree with the base noter that our ability to communicate
    electronically with our clients and customers is crucial, and a
    production gateway system supported.  If we could only get more
    reliable NEWS feeds... :)
    
    --- Gavin

    	
    	re: -1.   Yes... it would sure seem that with increasing
    use of the gateways for purely business functions, funding should be
    given to support and enhance them...
    
    	With the "rightsizing" (sic) of the Palo Alto facility, is
    support going to get worse, rather than better?
    
    	/john

.8:

Actually, the last version of DECwindows MAIL I played with knew how to
send DECwrite files without problem (and properly receive, render and
extract on the other end).  Is that in the release DECwindows?

Otherwise, not so much luck with regular MAIL.  And, I don't know if the
tricks that DECwindows MAIL uses would make it through the gateway intact.

Yeah, now that I think of it, UUENCODING it starts sounding good.

    The answer to many of the basenoter's informational questions can be
    found in 
    	DECWRL::"gateway.doc" or
    	DECWRL::"gateway.ps"
    which describes how to get e-mail into and out of the company.  There
    is also a "help" conference, UPSAR::GATEWAYS.

    .10
    
    Actually, I don't use DECwrite, but FrameMaker instead (common
    ancestory).  I was just generalizing on sending any old binary file.
    
    It's interesting that the largest conglomeration of networks on the
    planet is still limited to 7-bit ASCII for a lot of things.
    
    --- Gavin

I've run into the interesting challenge of getting a DECwrite document
through the Internet gateway (however it is capitalized /not) and
apparently it is not possible through the gateway (from DECwindows 
Mail or regular VMSmail) directly because "the outside world uses 7-bit 
ASCII".  Even if the recipient on the other end had DECwindows 
mail, the gateway would not pass the DECwrite file successfully as 
binary information.  Sure,  you can uuencode or whatever if you 
have all the appropriate bits lined up but many, many users have 
no idea what to do to get DECwrite messages uuencoded.  How 
many users are on non-UNIX systems and would have to go through 
convolutions to find uuencode?

Anyway, we definitely need something like NeXT's easy to use
and powerful built-in mail. I concur with the sentiment to 
have supported mail interfaces with all of the major networks, 
including  AppleLink, Internet, and Compuserve. Maybe even 
to the AOL's of the world too.

	erik

    The protocol used by the gateway does not allow 8-bits.  As such it is
    restricted from sending 8-bit mail.  There is work in the IETF to fix
    this but until then, reality is that 7-bits is it.

    The way outside people send stuff *in* to me is often by FAX.
    
    There is software you can get for a Mac (and I presume other PCs)
    that makes a fax modem look like a printer.  You just "print" your
    document, it dials the phone number and faxes it out.
    
    The same software will receive fax calls and put the received images
    into files.
    

    re: .16
    
    I believe that we have similiar software that works from VAX's.
    Something called, VAX to FAX or some such thing.
    
    Jim C.
    

There's VICfax  available from ALL-IN-1 

Allows you to send an electronic document as a Fax message.

It is an outgoing service only.

Support ASCII, WPS_Plus, SIXEL and DDIF (DECPaint) documents.

Not to be redundant, but X.400 should solve the base noters problem.
X.400 does support binary attachments so whether you're sending database
files, DecWrite, Fax images or whatever it will get through.

Where the problem comes is that both the sending party and the receiving
party need access to X.400 User Agents (All-in-1 is an example), have
access to an X.400 gateway (ours is in OGO I believe) and be a registered X.400
user.  We, DEC's PRMD, are connected I believe to the MCI ADMD and to the
PACIFIC BELL ADMD. I don't pretend to know what ADMD's and PRMD's are connected
to who, but the interconnection of X.400 MHS systems in an international
problem that gets solved little by little as time goes by. 

Al

    I think everyone has replied with some good ideas that you *can*
    do to solve all or part of the problem, but I think the point of the
    original note is that nobody outside of wrl *has* done it in
    a way that's accessible to the general employee population. For
    work purposes or anything else!  I use the wrl gateway daily to
    communicate with a major customer of ours and when the network
    ceases to function, it means at minimum embarrassment to me, and
    at most virtually total disruption of technical progress. I won't
    accept losing multi-$M business just because we can't figure out
    how to send mail to each other, or because we invent some policy
    that prohibits telling outsiders how to route mail to us.
    
    Let me not lambaste my colleagues in wrl, who have provided nearly
    flawless access to the internet for a long time. I like their low-key
    style and appreciate the fact that no bureaucracy stands between
    me and the net. Why can't they be chartered to officially provide
    this service?

    
    And another thing....
    
    I don't think INSPECT runs on Sun.... ;-)
    

"officially" is incompatible with "no bureaucracy"

I don't officially run a news server (which lots and lots of people use).
I don't officially add aliases to lkg.dec.com so can have addresses on
their business cards.

I didn't officially help run a notes server to help offload many machines
in LKG.  It now officially is maintained and has more loops to go thru to
add a conference ....

    
    
    
 >> <<< Note 1751.21 by ESGWST::DELISE "Change is the only real constant..." >>>
                                 -< Inspect? >-

    
 >>    And another thing....
    
 >>    I don't think INSPECT runs on Sun.... ;-)
    
    
    	Check back in a couple of months..... ;^)
    
    
    				Mike	
    				----

    re: .20

    What's been the result of your contacting the corporate
    telecommunications group with your business requirement?

    If the outcome doesn't satisfy you, then you can probably get a
    EASYNET-isolated system connected to the Internet at the expense of
    your cost center.  That would be your decision to make.

re: 1751.18  Can we manage our network like we suggest customers do?   18 of 19
>--------------------------------------------------------------------------------
This is true. VICfax is available through ALL-IN-1, but only if it
is installed on the system (it is not part of ALL-IN-1, although
it runs from A1.


>                                  -< VICfax >-
>
>Allows you to send an electronic document as a Fax message.

This is true, it does allow one to send a document as a FAX message, when
connected to to a Murata PC9F FAX machine.

>It is an outgoing service only.

It depends on how it is setup. It may be setup as one way (outgoing or incoming,
or it may be setup to be both). The nice thing about using VICfax with the
Murata (as compared to FAX Modems), is that for critical applications, if the
host link is down, the Murata will print out a paper copy from the 
back of the machine.

>Support ASCII, WPS_Plus, SIXEL and DDIF (DECPaint) documents.

From the VICfax release notes:
"VICfax supports only bitonal, image segment DDIF files. It does 
not support text or graphics segment DDIF files."

VICfax is in the Merrimack ASSETS Solutions Library.

    It appears that most of the comments come from US-based employees.  So
    I recommend you contact Bob Yost who is the Network Applications
    Manager for US Telecom.  Your local site may not be aware of what
    services are offered or planned.  Bob has established a services
    portfolio for Electronic Intercompany Communications which covers mail,
    file transfer, FAX, Telex, EDI, and interactive terminal access.
    
    New services are introduced based on the business needs, costs to
    provide, etc.  The corporate and geographic telecom organizations have
    partnered with Corporate Research in upgrading available Internet
    services.  However, the Internet is but one external entity; others may
    meet your need or your customer's/business partner's needs.  For
    example, US Telecom has also partnered with Manufacturing for file
    transfer solutions.

    
    re: .20
    
    I don't think that "multi-$M business" should be riding on delivery
    of a mail message (or series of mail messages) via Internet.
    
    Who are you going to call when your customer's Internet link is down
    for a week?  WRL?  What shall they be accountable for?
    
    How can the lack of message delivery via Internet cause you
    embarrasment with your customer?  Have they some magic network probe
    that can lay delivery blame with Digital's network?  
    
    I find the urgency of Internet message delivery and "it must be our
    fault" to be a bit troubling.

re -.1
Bob,

When we are communicating daily with customer doing joint development or 
scoping out a project we use Internet.  I have not yet had a mail message to 
my customers be delayed for more than 1 hour because of a problem on their end.
This may be due to the fact that I work in the valley on the left coast and 
Internet is considered a normal, expected business tool.  Similar to what we 
consider the EasyNet for internal communication.

When I send out briefings or summaries to customers, and they do not arrive, we 
track down why they did not arrive.  When our link goes down, we honestly tell 
the customer.  Why lie?  If they can communicate to other people, and not DEC, 
then it is rather obvious where to at least start looking for a fault.

Sending Faxes is slow, not point to point, and often a waste of paper.  
Internet mail is normally dependable, fast, and directly targetable.  When I 
care to get a message to my customer I use mail.  Faxes are very rarely private,
and much of the work we are doing with my customers has a limited audience for
security reasons.  I realize there are few secrets in the valley, but sending 
faxes is a well kown way to broadcast information prematurely.

Business depends on the ability to appear a modern, viable concern.  "multi-$M
business" never depends on a single message, however, it does depend on reliable 
communication.  When my customers have a question, 4 hour response is a goal.
Having a meeting tomorrow to discuss the question and then having 6 DECIES 
meet with the customer to further address it is not acceptable.  We have all 
been in these meetings and I find them destructive.  The people who support my 
sales efforts are expected to use the tools my customer does, and in today's 
environment that is Internet.

Re: .27

    How can lack of message delivery via Internet cause you 
    embarrassment with your customer?  Have they some magic network probe 
    that can lay delivery blame with Digital's network?

An absolutely true story: I was at a party (with primarily non-Digital
computer types) this weekend, and somebody mentioned that they hadn't 
been able to get mail to me for a while.  Not one but two people -- neither
of whom worked at Digital -- immediately responded "Aha!  The Digital
MX Internet delivery problem!" and a half dozen other people nodded in
immediate comprehension.  

When customers send us mail and it gets returned to them with a message
about how it couldn't get from DECPA to our site ... well, they can 
usually make a pretty fair assumption about where the problem is when
we can't them mail either.

    Who are you going to call when your customer's Internet link is down
    for a week?  

CAD companies rely on their Internet links sufficiently that this 
doesn't happen.  [At least, this hasn't happened in the two years that
I've been exchanging mail with people at this CAD company.]  Sun relies
on their Internet links sufficiently that this doesn't happen.  [At least,
it hasn't happened in the four years I've been exchanging mail with people
at Sun.]  This is how companies -- at least in the Valley -- do business.

    I find the urgency of Internet message delivery and "it must be our
    fault" to be a bit troubling.

But it *was* our fault.  Does that make it less troubling?





Okay, maybe I'm just a dumb development engineer who's under the mistaken
impression that Internet-style addressing should be enough.  All I know
is that twice in the last three months I've been blindsided in customer
meetings (including earlier this week one with a VP of a potential OEM
partner) becuase correctly-addressed electronic mail was not delivered
and I did not receive any notification of failed delivery -- and their
mail to me mentioning that the documents hadn't been received was
bounced back to them.  Two other times, I at least received inquiries
from the customer and so was only embarrassed over the phone.

To echo .8, the folks at DECWRL/DECPA definitely deserve applause for their
efforts.  The system administrators at our site similarly work their
posteriors off -- supporting a mixed Sun/HP/IBM/Ultrix/VMS/MAC environment --
and do a fine job.  I'm not pointing fingers at or laying
blame on anybody.  

The simple fact is, a mechanism that in my non-Digital incarnation I
could rely on as reliable, and which notified me on failed delivery, I
can now view as about 85% reliable (with no way to know whether
delivery succeeded or not).  

Considering we're presumably competing with Sun in at least one of
these accounts, it was rather disheartening to hear the Development Manager
say pointedly that a reliable E-mail connection would certainly be necessary
in order to work together, and in the very next sentence to mention that
they never seemed to have problems sending mail to Sun.  



That's what separates us from the animals: our ability to learn from
our mistakes.  I can adapt.  For important customers, I've fallen back
on either faxing the information or telephoning to assure myself that
it got there.  This works, so I can get my job done.

Of course I'm sure the amusement in their voices as they talk about
high technology making all of our lives simpler and make references to
fifteen years ago when they used "SneakerNet (tm)" to communicate
between their machines doesn't influence their opinions of Digital's
technology leadership.  I'm sure their laughing remarks that mail
delivery would be more reliable if I were running VMS doesn't make them
question Digital's commitment to U*IX and heterogeneity.  And probably
the running joke among friends of mine at other companies that US Mail
is more timely than relying on Digital's E-mail delivery is actually
good for us, since it increases name recognition.

    The DFE-UCO link is not part of the network maintained by the CT
    people.  If DFE can't hire someone to support it, then they shouldn't
    complain when it goes down.

    re: .30
    
>    The DFE-UCO link is not part of the network maintained by the CT
>    people.  If DFE can't hire someone to support it, then they shouldn't
>    complain when it goes down.
    
    If this kind of thinking was the norm a decade ago, we probably either
    would have no Internet access at all, or there would now be several
    vice presidents dedicated to managing the heirarchy supporting the
    gateway.
    
    Maybe the latter is the 'right thing' to do these days.  Sure as hell
    doesn't feel good to me.  I just don't know anymore.
    
    -joe tomkowitz

If the base note were about inadequate telephone service, no one would be
disputing the righteousness of the author's indignation.

Could it be we're seeing another East/West culture clash?  Us big boys here
in Boston and New York don't use internet.  Ergo, it's not really a serious
business tool, no matter what you boys on the Left Coast say about it.

-dave

    
    I wouldn't say it was so much of a culture clash as it is a support
    issue.  I use Internet routinely to communicate with many of our larger
    customers.  I hadn't realized that folks rely on delivery to conduct
    business.
    
    If it were a phone problem, then there are organizations internal and
    external with charters that include solving connectivity problems.
    
    Who is ultimately responsible for Internet connectivity to conduct
    business?  Not just within Digital but right through the network to all
    customers?  What about my colleague at Sumitomo in Japan?  Who can I
    call to complain about message delivery?  (facetious, of course)
    

    If the base note were about inadequate access to Prodigy, everyone
    would wonder what the complaint was about, and why this complaint was
    appearing in ::Digital and not ::Gateways.

    Could it be we're seeing another Digital group getting a free ride on
    something that the offering group cannot guarantee as being stable, 
    supported, and continuously available.  No good deed in Digital goes
    unpunished.

>    If this kind of thinking was the norm a decade ago, we probably either
>    would have no Internet access at all, or there would now be several
>    vice presidents dedicated to managing the heirarchy supporting the
>    gateway.
    
    Wrong.  CRA pays for and maintains the Easynet gateway.  They have
    hired people to support it (for themselves).  If it breaks, they will
    fix it. Hence the Internet seems stable since CRA has made an effort to
    make it stable.
    
    Have the people at DFE done so?  If not, is it really surprising that
    when the link goes down, that it stays down?
    
    To get an Internet link to Palo Alto, a cost-center must justify (to
    itself) the cost of the link.  This not only includes the phone system
    changes for copper/fiber, but the equipment on both sides, and the
    support infrastructure to make it stays up (or why would they be paying
    the money?).
    
    To blame those who have no responsibility for keeping that link running
    is just idle blather.  If DFE can't keep up the line, they have no one
    to blame but themselves or the people they arranged to support the
    link.  I personally don't know what arrangements were made (nor do I
    care). 
    
>    Maybe the latter is the 'right thing' to do these days.  Sure as hell
>    doesn't feel good to me.  I just don't know anymore.
    
    My point is that you shouldn't blame the system when the system isn't
    responsible (granted it may be at fault -- but in this instance).

    re .29
    
    You must have really slow parties if one non-Digital person complained
    about our networking and six other people agreed.  You should expand
    your social circles.
    
    Ken

As the base noter I am not complaining about the service we get from the people 
in Palo Alto.  We have put in a direct line to them and they have been more 
than supportive.  I am complaining that a tool used by a great number of people
ought to be supported.  I have sent mail to Mr Yost who was mentioned earlier,  
I will call him again.  This is no different than telephones, connections to 
U.S. Mail, or the power grid.

I just talked to Mr. Yost.  I will get more informatin next week.


On to ackronyms, Who is CT?  Who is CRA?

re .30
I certainly don't more VP's, and if that is the solution than I will go back to 
sneakernet and Boeingnet.  It just seems that the right way to fix this is not
hard, take a person or three from DIS and assign them to support the link.

re .33
I think there SHOULD be someone you could call when the link breaks in DEC
when you are sending a massage to Sumitomo.  Do you let someone know when 
you can't call Japan?

re .34
Yes I am getting a free ride.  We put in a direct phone line and have some 
dedicated hardware at each end.  I would gladly pay (as would the managers here)
for a supported system.  Heck, we even pay our phone bill and all the DEC 
support taxes!

Matt

This discussion has touched upon a number of issues very close to my heart,
and to the (in)ability of my work group to reach its highest maintainable
productivity level.  So, into the crusade I plunge!

Digitial is not just a VMS company today.  It is a systems vendor for VMS,
ULTRIX and DOS/WINDOWS hardware and software, a software developer for these
as well as SUN/OS and other platforms, and a systems integrator with products
such as Pathworks, LAN Complete, etc...

My point is that the company is already deeply into the multi-platform,
multi-vendor, heterogeneous LAN/WAN work environment.  If not, we could
not be producing and selling this list of products.  The problem is, it
is very hard to successfully do this due to the corporate momentum as a
VMS shop.

Digital corporate processes and mechanisms have remained very VMS oriented,
and this is what makes it hard and more costly to produce the products that
we must if we are to compete in today's computing marketplace.  Somehow we
must find a way to migrate to a work environment model that matches our
market, just as the existing environment served us well when it did.

What are we asking for?

1.  Site support for ALL platforms... not just VMS.

2.  Site support for electronic data interchange amoungst ourselves, our
    partners, our software developers, and our customers.

3.  Site support for ALL networking... not just DECnet.

What are the consequences of not doing this?

If a company is to change the way it operates, there must be a business
reason to do so.  In other words, we are all here to make money, so if
it helps make money, and that includes reduces the cost of selling the
same amount of product, then we should be doing it.

Just this week I experienced one of the most embarrassing meetings I have
ever been involved with.  I am working with a group of companies in our
industry on a project.  We are writting a document, rather normal for
this type of effort.  In the span of about a week and a half, I sent a
number of email messages that:

1.  Announced a meeting of our group.

2.  Provided details on this meeting.

3.  Distributed the version of our document that would be the basis of the
    work at this meeting.

4.  Tried to confirm that my previous email had been received.

When I walked into the meeting, I discovered that only one person had
received all of these messages.  I had brought hardcopy of our document
with me, and it turned out that everyone's first look at that document
was when I handed out my hardcopies at the meeting.  The rest of the
meeting was very predictable ... no one knew what we were talking about
because no one had read the document, so we disagreed over everything,
including how to communicate between meetings so we could actually be
prepared for the next meeting.  If these measures work, maybe we will
actually make some progress at our NEXT meeting... one that was not
intended and never should have been needed.  To top things off, the
day AFTER the meeting, we all were subjected to recieving 18 copies
of a message from one of the non-attendees complaining that he had
recieved the meeting announcement very late the day before the meeting.
(you Unix email folks can probably guess, those 18 copies were due to
a Unix email mailing list screwup).

The bottom line from this meeting was that digital did not have its act
together.  Since that was my job, I was totally humiliated since I had
worked very hard to be TOTALLY prepared.  I agree that a little more
rigor checking with some of the group would have helped detect the problem,
but that is not the answer.  What is scarry is that this is only one of
many experiences I have had, each due to a different problem, all due to
the same corporate problem.

We need to be able to depend on the tools we use to get our jobs done.  It
is a fact that digital does its business on multiple platforms, from multiple
vendors, on heterogeneous networks, and through electronic communications
with parties both inside and outside the company.  Today, there is no 
corporate commitment to this goal.  This means that to be successful, groups
must provide their own support for things normally supported by various
corporate organizations.  Just as it was profitable to perform these support
functions for VMS, it is a key to remaining profitable to get the company to
transition to supporting the current work environment.

Marc S. Gibian
Principal Software Engineer

>Site support for ALL networking... not just DECnet.
    
    We have TCP/IP and Appletalk backbones.... what else do you want?
    
    
    

>I will call him again.  This is no different than telephones, connections to 
>U.S. Mail, or the power grid.
    
    Really?  Since when did Internet become a public utility in the strict
    sense of the term?  What are the tariff structures?
    

>>    We have TCP/IP and Appletalk backbones.... what else do you want?

OSI....

--Scott

>>    We have TCP/IP and Appletalk backbones.... what else do you want?

>>OSI....

    It depends on what you mean by "We have".  Support means a lot more
    than mearly providing specific backbones.  It means proper
    administration of the network, and the network related parts of all
    machines connected to it.  Some machines will require direct
    administration by their owners, but that should really be the
    exception, not the rule.
    
    We don't need every user of a machine, be it a big VAX or a low end PC
    running PATHWORKS, to be a tcp/ip, DECnet, appletalk, OSI, etc..
    administrator.  That's a pretty expensive thing to do, when a small
    number of site support network experts could do a better job for less
    money.

    >                   -< But what do YOU call support? >-
    
    Well I don't expect resources to be served up on a silver platter.
    
    Are you saying that our internal TCP/IP network is not managed
    properly?
    

RE: .37

CT = Corporate Telecommunications, the folks who administer and maintain the
	EasyNet

CRA = Corporate Research and Architecture, the group to which WRL
	(Western Research Laboratory) and most likely SRC (Systems Research
	Center?) in Palo Alto belong.  Last time I looked, Sam Fuller was
	VP of CRA.

--PSW

    Re: .40 .41 .42
    
    IMO, every DEC site needs DECnet, TCP/IP, OSI, and any other network
    protocol which helps the company (both internally and with out
    customers).  Our site (a remote field office) has only DECnet and LAT
    protocols connecting us to the rest of the Easynet.  This makes it very
    hard for us to do business with other sites.  The reverse is also true. 
    We have a DECmpp 12000 machine sitting on the Easynet, and the only way
    to get to it is via DECnet.
    
    Not every machine should run all the protocols, but the availability
    needs to be there.
    
    --- Gavin

>   protocol which helps the company (both internally and with out
>   customers).  Our site (a remote field office) has only DECnet and LAT
    
    Opps!  I mean't "and with *our* customers". :)
    
    --- Gavin

You are correct.  Our internal TCP/IP network is not managed properly!  As
an arbitrary example, my group currently is "stuck" in the ljo.dec.com zone.
The party to whom administrative control of our zone has been delegated will
not install the required MX records needed to properly support my group.
Since they are not a site support group, and have a relationship with my
group only at the highest management levels, there is no incentive for them
to do things that will make my group more productive.  This is just one of
many examples.  I do not view this as a "silver platter" issue.  My group
CAN NOT fix this since we do not have the delegated authority to do so.

    Well, I promised to write here when anything happens with Corporate
    Telecommunications, but I have given up.  After several phone calls,
    and some mail message, they never responded.  So, we will create yacc (yet
    another communication channel) between ourselves and the outside world. 
    It won't be supported, of course, nor will it be accessable to the
    general DEC population unless someone wants to manage it.  It will be a
    business tool that only a few people can use, only a few will kow how
    to use, and over time when it breaks the people who set it will be on
    to some other company.  All in all, a typical DEC business support
    decision.
    
    To all you people satisfied with the current system, be happy, The
    Company Did Not Have To Modernize!  To all you would like a modern
    system, buy modems and UUCP connections.
    
    As a sales person, I will not fight the lack of decisions in DEC, I
    will make one more suboptimal decision and have the company pay for it.
    That unfortunately is my job.
    
    Matt

    Hnag on a second.
    
    Over the past year I have discovered Internet, and the capability to
    mail people outside of the comapany. I have sent many, many mail
    messages and all have arrived at their destination. All people who I
    have mailed have been able to reply to me, with no problems. I am in
    the UK and can mail other peopl in the UK, or anywhere in the world.
    The uk people get mail's within the hour, as far as I am aware. I have
    carried out all sortsd of conversations and helped friend with "What is
    xtz on VMS for, etc etc"
    
    Now I do this from VMS, using the recognized DIGITAL gateways. We have
    an ULTRIX machine hooked up to the TCP/IP backbone, but we are still
    learning about this machine and hence I would not trust it to send
    these everyday mail messages.
    
    In the past month DIGITAL have set up an FTP relay services which means
    I can now grab binaries off anywhere on the Internet very quickly and
    easily. I used to do this by mail, the relay is SO much better.
    
    I do think we have a good working solution.
    
    Greg