Home | Contact Us | Submit Troubleshooting Info | Search | Help
Output | Software Solutions | Proofing | Color, Screening and Calibration | Scanning | Digital Photography | Consumables | POS
Home | Contact Us | Submit Troubleshooting Info | Search | Help
Output | Software Solutions | Proofing | Color, Screening and Calibration | Scanning | Digital Photography | Consumables | POS
|
|
||
Product |
||
Platform |
||
Operating system |
||
|
|
||
Error |
||
|
|
||
Symptoms |
When trying to retrieve a job on a tape that is offline on a tape library, RSM asks for a tape that does not contain the job to retrieve and at the end, the retrieval fails. |
|
|
|
||
Cause |
When ejecting the tape too fast before the I/O port fully extended, the library will not trigger a scan to update the RSM. In this situation, the tape name will remain on the cache, when you inject a tape with different name, it will think it is named as the previous tape. When this happens, it will mess up the archiver medium table to store the name, and so when retrieve, it will ask for the wrong tape. | |
|
|
||
Solution |
We need to fix up the RSM and dbcs_archivemedium table first and to isolate which tapes have been mismatch. There is a utility called GetRSM_omid.exe, see also link, that can run on the system to get the mediumID for each tape in RSM, use the result to compare with the dbcs_archivemedium table to locate the mismatch tape. Manaully update the entry in the table. Once we fix up the table, we should advise the customer to wait 2 FULL seconds before ejecting the tape. Permanent fix: Qualstar is confirmed this is a firmware bug, but since we only seen one customer having this problem, they will release the fix on the next coming release. Permanent fix: |
|
|
|
||
See also |
||
|
|
||
Keywords |
archiver - RSM, archiver - retrieve |
|
|
|
||
Technical contact(s) |
Amy Chan |
|
Submitted by |
Amy Chan |
|
Date submitted |
07 June 2006 |
|