Thank You for the response Wanda. Your level of detail is always very
appreciated. What I know so far concerning my environment is:
status=STATUS_NI_FAILURE was corrected through a DNS modification. The NI
"may" stand for not initialized. In my case someone had modified DNS removing my
acsls entry. The LSM was unable to converse with ADSM nor acsls.
status=STATUS_CAP_IN_USE was corrected through hardware. Our 9740 CAP
(cartridge access port) was working improperly. STK replaced some of the CAP
and the problem appears resolved. I could actually depress the CAP and get the
LED read out to change on the LSM.
status=STATUS_IPC_FAILURE does focus on the SSI. I know if the SSI is not
up, you get the error.
I'm still scratching to find the true technical definition of these errors.
Will keep
you posted. Its scary to know that *SM addresses it, codes for it and doesn't
document it....... unless you have the source.
Concerning your config, do you notice on occasion that the library doesn't
become
"ready for operation" immediately following server startup... and yet, if you
"bump"
the server it almost always becomes ready the second time around?
"Prather, Wanda" wrote:
> 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
|
