Hi Mark,
I have exactly the same software configuration here- AIX 3.1.2.42, ACSLS
5.3.
Libraries are STK9710's with DLT7000's and STK9840's.
I haven't found any doc for the ANR8855E messages either. On the other
hand, I don't think it matters much. What you do in response to the
messages is usually all the same.
When ADSM wants to do a robot operation, I think ADSM calls the ssi module
(see the startup for acs_ssi in your /etc/inittab.) And the ssi module
sends commands to ACSLS via the ACSLS API interface.
Whenever we see these messages, it's because ADSM has gotten some bad return
code back from ssi, or ssi has gotten some bad return code back from ACSLS.
What I do is first go directly to ACSLS and check out its function - Q LSM,
Q DRIVE, etc.
If it's healthy and responsive, then I go to AIX and run lbtest to do the
same commands via the ssi interface.
Sometimes I can find the problem, but usually I find that ACSLS is up and
working, ssi is up and working, but they refuse to talk to each other any
more, FNAR. I've never been able to come to any resolution but to take down
ADSM, ACSLS, and ssi and restart them in the right order. That's not a
pretty solution, but I don't know of any tools to do otherwise.
The most common one I see is IPC (inter-process communication) failure. I
don't know what causes it, but I suspect it's just timing. I suspect that
sometimes a timeout in the library itself (we see a lot of ACSLS timeouts
due to excessive cleaning on DLT7000 drives) exceeds somebody's time limit,
and either SSI or ACSLS loses track of an API call. Once ADSM/ssi/ACSLS is
out of sync, they rarely recover without being restarted. If you see a lot
of these, try increasing the value of ACSTIMEOUTX in your dsmserv.opt file,
that eliminated some of them for me.
Given the size, expense, sophistication, and customer base of these STK
libraries, the *SM support is disappointing. Most of it works, but it is
not consistently implemented - MOVE DRMEDIA, for example, STILL doesn't
support checkout from ACSLS-driven libraries (and we pay EXTRA for DRM to
not get that support - go figure.)
And the documentation and tools are marginal, at best. If you ever find any
tools that can tell you what REALLY goes wrong in the ssi interface, please
let me know!
Maybe this was no help, but at least you know there is someone else in the
same boat...
************************************************************************
Wanda Prather
The 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
************************************************************************
> -----Original Message-----
> From: Mark Owens [SMTP:Mark_Owens AT PRODIGY DOT NET]
> Sent: Monday, December 20, 1999 10:10 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: ANR8855E
>
> I apologize for reposting this. My service contract got hacked in the
> budget pro
> cess
> and I will be charged if I call Tivoli/IBM ........ I've got to believe
> there
> are other STK ACSLS customers out there whom have experienced these types
> of errors before.......... by the way, have a safe happy holiday!
>
>
> Server : AIX 3.1.2.42
> ACSLS : 5.3
>
> Hi All,
>
>
> From time to time I get message identifier ANR8855E which is documented in
> the V3 ADSM Messages manual. Unfortunately, I can't find info on the many
> different status' for example....... status=STATUS_NI_FAILURE. Whats a
> NI?
>
> Would anyone know where I can find documentation which explains the values
> to the right of status=
>
> ANR8855E ACSAPI(acs_query_server) response with unsuccessful status,
> status=STATUS_NI_FAILURE. or
> status=STATUS_CAP_IN_USE (this one I know) or
> status=STATUS_IPC_FAILURE
>
> I'm sure there are more but I can't find any doc.
>
>
> tia
>
> Mark
|
