[comp.sys.apollo] New -rem option to rbak

crgabb@sdrc.UUCP (Rob Gabbard) (02/17/89)

Has anyone gotten the new -rem option to rbak to work ? The SR10.1
release notes state that it must be to a host with /etc/rmt that you
can rexec to. Since both are Suns and Convex use this mechanism via
dump to do backups I figured that would be the perfect canidates.

After mounting a wbak-written tape onto both a Sun and Convex I tried
the following:

	rbak -f 1 -rem sun:/dev/rmt8 -index -all 
	rbak -f 1 -rem convex:/dev/rmt16 -index -all
	rbak -f 1 -rem sun:rmt8 -index -all 
	rbak -f 1 -rem convex:rmt16 -index -all

After all attempts the message "Login failed." is returned along with
a message from rbak telling me it failed to connect to foreign host.
The account I was doing this from was able to rsh, rlogin, etc. without
the -l option so I know that's not the problem. I figure Apollo is using
some canned account name to connect with the rexec.

So my next step was to call 1-800-2APOLLO. And the ever so helpful response
was "You got a VAX running UNIX ? R & D says it should work so I'm submitting
an APR (i.e. so he can close the call ASAP)."


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rob Gabbard (uunet!sdrc!crgabb)                 _    /|
Workstation Systems Programmer                  \'o.O'
Structural Dynamics Research Corporation        =(___)=   
                                                   U
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

weber_w@apollo.COM (Walt Weber) (02/24/89)

In article <529@sdrc.UUCP> crgabb@sdrc.UUCP (Rob Gabbard) writes:
>Has anyone gotten the new -rem option to rbak to work ? The SR10.1
>release notes state that it must be to a host with /etc/rmt that you
>can rexec to. Since both are Suns and Convex use this mechanism via
>dump to do backups I figured that would be the perfect canidates.
>
>After all attempts the message "Login failed." is returned along with
>a message from rbak telling me it failed to connect to foreign host.
>The account I was doing this from was able to rsh, rlogin, etc. without
>the -l option so I know that's not the problem. I figure Apollo is using
>some canned account name to connect with the rexec.
>
>So my next step was to call 1-800-2APOLLO. And the ever so helpful response
>was "You got a VAX running UNIX ? R & D says it should work so I'm submitting
>an APR (i.e. so he can close the call ASAP)."

Rob:

As the manager of the OS Support group at 1-800-2-Apollo, I was concerned that
you feel we could do better in supporting you.  I reviewed the incident which
was opened for this question, and have seen the following:

2/1 @ 10AM - you opened the call, got transferred immediately to a specialist
    who was unfamiliar with the new "-rem" option under 10.1.  She collected
    a bit more data from you, and transferred it to another specialist who
    knew more about 10.1 & rbak than she did.

2/1 @ 1200 - the second specialist contacted the developer for a quick check
    on the issue, since the new option didn't make it into the online help
    page, but was in the release notes - possibly a documentation bug?  Developer
    says "should work, get the following data for us .....".

2/1 @ 1420 - second specialist appears to have contacted you, since the call
    contains the answers to the questions asked by r&d.

2/3 @ 1530 - we reproduced the problem here using a non-apollo machine, and
    also between two apollo nodes.  We submitted the analysis to r&d via an
    apr (formal reporting procedure, r&d builds worklists from the apr system),
    and then left you a message with the apr number, and that the incident would
    be closed.

Analysis:

- We did really well on the analysis and timely report to r&d.

- We could have done better by suggesting a workaround to try (maybe
   "rbak -stdin | rsh sun1:dd" would work?).

- We did poorly in communicating the results of our analysis to you, leading you to
  believe you had been abandoned.

While it is not my desire to turn this into talk.sins.confessional, I felt that the
user community might be interested to know that we are interested in your needs,
and intend to address problems as we find them.  If you continue to inform us of
specific problems, we'll try our best to resolve them as best we can.

Thanks for your time.

...walt...
-- 
Walt Weber                            Apollo Computer          
(508) 256-6600 x7165                  People's Republic of Massachusetts
-The views expressed herein are personal, and not necessarily Apollo's-

crgabb@sdrc.UUCP (Rob Gabbard) (02/25/89)

> As the manager of the OS Support group at 1-800-2-Apollo, I was concerned that
> you feel we could do better in supporting you.  I reviewed the incident which
> was opened for this question
> 
> Analysis:
> 
> - We did really well on the analysis and timely report to r&d.
> 
> - We could have done better by suggesting a workaround to try (maybe
>    "rbak -stdin | rsh sun1:dd" would work?).
> 
> - We did poorly in communicating the results of our analysis to you, leading you to
>   believe you had been abandoned.
> 

I'd like to thank Walt for his responsiveness and would like to stress that I
did not want to cast any bad light on Apollo software support. I have found
Apollo support to be some of the best available compared to some other vendors
I have dealt with.

During this particular incident I was outraged that more effort was not put
into finding a solution to my problem. I did not know that the problem
had been duplicated at Apollo - all I heard was "R&D said it should work".
Without knowing this I assumed the support guy didn't even try it.

Most of the problems I call in are resolved by the support staff. However,
I usually give up when an APR is submitted. At that point I realize it is
out of their hands and in R&D's. Of about 10 APRs I have submitted in the last 
5 months, I have only gotten a reply on 1 of them. I get the letter with that 
infamous statement "Thank you for sending us your APR.  Your APR is currently 
being worked on and you will receive a reply from us SOON" but I rarely recieve
a follow up. Some of them were fixed in SR10.1 but I didn't know that until 
after I had 10.1.

It doesn't seem as if the problem is with the support staff but with R&D's
responsivness. Once again, I'd like to thank Walt for his thorough response.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rob Gabbard (uunet!sdrc!crgabb)                 _    /|
Workstation Systems Programmer                  \'o.O'
Structural Dynamics Research Corporation        =(___)=   
                                                   U
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=