Wanda, Bill, Richard,
Thanks for your prompt responses. It turned out to be an error in the
scheduler configuration on the client, and NOT a real protocol error (just
as Wanda suggests below).
In the dsmerror.log file, I found that the 'primary' error - triggering
others, I believe - was that the scheduler gave this error: [ ANS1838E
Error opening user specified options file ''C:\program
files\utilities\adsm\baclient\dsm.opt" ]. As you can see, we decided to
install ADSM in a place of our choosing under WindowsNT 4.0, instead of the
default directory. We hadn't thought there would be a problem, as the
DSMCUTIL INSTALL command accepted this as the CLIENTDIR parameter (in
quotes) with no squawks. Hey, if DSMCUTIL can accept long file names, then
DSMCSVC should handle long file names, right?
I made several changes using dsmcutil, such as checking the password and
updating it, but restarting the Scheduler service always produced more
errors until I modified the CLIENTDIR to read
"C:\progra~1\utilit~1\adsm\baclient\dsm.opt" . If you haven't seen this
before, this is the "mapped" form of Windows NT 4 long file names, to allow
older DOS-type programs to find their way through paths and open data
files, etc.
I also did as Bill suggested and ran the GUI backup-archive client and
backed up a few files, entering the correct password in the process. But
I'm not sure that this was the answer, as looking in the Registry reveals
that the password the Scheduler service uses, and the password the
interactive client uses, are stored in two different places. The password
stored with the Scheduler service was unchanged after my interactive
backup. I also directly replaced the stored password (with the same
password) for the Scheduler by using DSMCUTIL UPDATEPW, and it verified
with the server no problem. And again there was no change in the Registry
entry for the stored password...
I'm still puzzled by a few things - such as, how did the scheduler find the
ADSM server if it couldn't open the dsm.opt file? But in any case, it
appears that one or more of the actions I did fixed the problem. We'll
know tonight, as I have this 'test' node scheduled for a window starting at
8:00PM.
Again, thanks to everyone who responded. Put me on the correct track
immediately.
Tony
At 10:37 AM 4/29/98 -0400, you wrote:
>When I see this message on the server, it usually does NOT mean there is a
>real protocol error, it just means that the session was broken off on the
>client end.
>
>On the client, look for the files dsmerror.log and dsmsched.log.
>You may see better error messages in there.
>
>If that doesn't give you enough information, try running an incremental
>backup from the client using the GUI interface. You may get a better idea
>of what is going wrong.
>
>Good luck...
>
>===============================================================
>Wanda Prather
>Johns Hopkins Applied Physics Lab
>443-778-8769
>wanda_prather AT jhuapl DOT edu
>
>"Intelligence has much less practical application than you'd think."
> - Scott Adams/Dilbert
>===============================================================
>
>
>> ----------
>> From: Tony White[SMTP:tony.white AT gtri.gatech DOT edu]
>> Sent: Wednesday, April 29, 1998 10:21 AM
>> To: ADSM-L AT vm.marist DOT edu
>> Subject: Error ANR0444W found: Protocol error
>>
>> Everyone,
>>
>> Once again I have stumbled into the next hurdle on the quest to
>> get ADSM
>> running and used. Hopefully you all can help.
>>
>> I was able to get my Exabyte tape library responding correctly (thanks,
>> Kelly) and at least one drive working, and labelled my tapes. I've
>> defined
>> a schedule and client node and associated them, using just the default
>> STANDARD domain and policy set.
>>
>> On my Windows NT client (NT v4 with SP3), using client code version
>> 3.1.0.3, I installed the service (as Administrator) and it started the
>> scheduler. It contacted the server (ADSM v3.1.0.2 on AIX 4.x) within a
>> few
>> minutes, but we get an error and session terminates:
>>
>> ANR0444W: Protocol error with client node AIST068 - out-of-sequence verb
>> (type SignOff) detected.
>>
>> I've searched the last 3 months of the list logs, and searched the IBM
>> readmes and fix descriptions. No specific references to this error. I've
>> got the latest client code for WinNT, but I noticed that my server version
>> (3.1.0.2) is NOT the latest (3.1.1.1) .
>>
>> Is this the likely cause of the protocol mismatch?
>>
>> Thanks in advance -
>>
>> Tony
----------------------------------
Tony White, Research Scientist II Tony.White AT gtri.gatech DOT edu
Tony White, Research Scientist II Tony.White AT gtri.gatech DOT edu
GTRI Computer Coordinator (404) 894-8157 fax: 894-9337
GT/GTRI/AIST, Atlanta, GA 30332-0816
"Optimist: a Yugo owner with a trailer hitch."
|
