If you are still having the problem, it may be TCP/IP. When you restart the ssi, you probably had to give it the host name; if it can't access that host name via TCP/IP, then you are stuck.
ACSLS is server software, TSM is server software, the ssi sits in between them (even if they are all running on the same host). When using a TYPE-ACS (ACSLS driven) library, TSM doesn't issue the robotic commands itself, like it does for a SCSI library. Instead it sends tells the ssi what it wants to do (like, mount a tape). Then the ssi sends the request on to ACSLS, which sends the command to the robot and also (I think) sends some sort of ack back to TSM via the ssi. If something prevents that inter-process communication from occuring properly, or one of the pieces of software drops a transaction (or an ack), then you die with an IPC failure. Redefining the drives or the library won't help; it's a communication thing. The best way to debug these problems is to become familiar with the ACSLS software and the lbtest command, so you can break the problem down and identify what is failing. When you bring ACSLS up, start cmd_proc and talk to ACSLS directly. (The ACSLS commands are described in the ACSLS admin guide, which you can download in .pdf format from the STK web site.) Issue a 'q drive all' command to make sure that acsls is awake and talking. If there are any tapes left in the drives (assuming TSM is down, or you wouldn't be having this problem), dismount them with ACSLS dismount FORCE commands. If you can't do this stuff, you need to call STK software support and let them debug the problem. Once you have proven that ACSLS is up and talking, start the ssi. NOW you want to run the lbtest command. You will find it in the /usr/tivoli/tsm/devices/bin directory. CD to that directory and type: ./lbtest Choose 1, manual test. Pick the commands starting with 51 and up, which are acsls commands. I usually choose 53, which is q drive all. Running lbtest lets you send the SAME 'q drive all' command to acsls. But you are sending it via ssi. You should get the same information back (formatted differently) as if you issue 'q drive all' directly to ACSLS. This proves that the inter-process communication between ssi and ACSLS is working. Now you should be able to start TSM, and it should NOT get an IPC failure. If you still have the problem, someone has changed your config, or PROBABLY dns or TCP/IP isn't working. Hope that helps... ************************************************************************ Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] "Intelligence has much less practical application than you'd think" - Scott Adams/Dilbert ************************************************************************ -----Original Message----- From: Hunley, Ike [mailto:[EMAIL PROTECTED]] Sent: Monday, March 04, 2002 5:59 PM To: [EMAIL PROTECTED] Subject: Question on STK 9360 library not working. We have a TSM 4.2.1.0 Server running on UNIX 4.3.3.0. It usually connects to an STK 9360 library. The building powered down this weekend. The TSM server rebooted. The Silo powered up. TSM issues these messages concerning the tape library... ANR8854E ACSAPI(acs_query_server) invocation failed, status=STATUS_IPC_FAILURE. 03/04/02 14:33:03 ANR8852E Initialization failed for ACSLS library ACSLIB We deleted two drives and tried to redefine them, but received a library not available msg. When I tried to make a change to the ACSLIB, I received a library busy msg. We issued these commands to show both daemons running. ps -ef|grep ssi ps -ef|grep mini We called STK and opened a PMR with IBM. Per IBM we performed the following steps to no avail... In dsmserv.opt: Made sure..ACSQUICKINIT YES 2. Halt TSM 3. kill.acs_ssi 4. Halt acsls 5. Wait 2-3 minutes 6. Restart acsls 7. Wait 2-3 minutes 8. rc.acs_ssi 9. Wait 2-3 minutes 10. Start TSM Does anyone out there have any other methods to get past this? Blue Cross Blue Shield of Florida, Inc., and its subsidiary and affiliate companies are not responsible for errors or omissions in this e-mail message. Any personal comments made in this e-mail do not reflect the views of Blue Cross Blue Shield of Florida, Inc.
