We just got  a new SDLT stacker from Overland.  I am having a heck of a 
time making the drive work with our existing software under solaris 8.

The following is our setup, prior to the new Overland LoaderXpress SDLT 
320 (LXB).

We have tape 4 stackers at our shop; three 3490's (two of which are 
Overland), one IBM 3590.

The stackers are not used for backup, but we receive binary data from 
our clients on boxes of tapes.

We have our own software for reading the data off of the tapes.  It 
works well with our existing stackers. All of the drives have two 
library modes 'system' and 'auto'.

I use the MTIO interface with ioctl(), within C/C++. Here is how I 
unload a tape, then load the next one:

System Mode
1 ioctl::rew
2 ioctl::offline
3 library then physically ejects the tape when offline is finished
4 the ioctl::offline call returns
5 ioctl::load
6 the library grabs the next tape and 'loads' it.
7 the ioctl::load returns
8 read(2)
x ...

Auto Mode
1 ioctl::rew
2 ioctl::offline
3 library then physically ejects the tape when offline is finished
4 the ioctl::offline call returns
5 the library grabs the next tape and 'loads' it.
6 program waits an preset time until the next tape inserted in drive.
7 ioctl::load, which returns immediately
8 read(2)
x ...

The LXB offers 'random' and 'sequential' mode, instead of 'system' and 
'auto'. The library responds slightly different to my MTIO commands than 
our other 4 stackers.

In 'random' mode, the ioctl::offline offlines the tape, but does not 
eject it, so the subsequent load command just 'loads' the same tape.

I decided that I could live with 'auto' or 'sequential'.  But I keep 
running into an issue where the ioctl::load  in step 7 fails, even 
though the new tape is physically in the drive.
The funny thing is that it works for the first 3 or 4 tapes in the 
magazine, then after loading the next tape, the ioctl::load fails.  On 
the ioctl::load failure my software exits. The drive then does not 
respond to an 'mt status', saying that no tape is loaded or drive is 
offline. Using a c program I wrote to interactively send 
read/load/offline/open/close at the user's request, I can then do an 
open.  Now any call but close and offline fail, so I do an offline, this 
ejects the tape and loads the next one.  Then I do a load, and exit my 
program.  Now the drive responds to an mt status again.

During the periods where the drive will not respond to an mt status (as 
mentioned above), the LCD reports the SDLT drive, and the robot as idle, 
and the green "ready" light is on.  But if I look at the tape format in 
the SDLT1 menu of the LCD, it shows 'not loaded'.  So the tape is in the 
drive, just not ready at load point.

I can take the tape that fails to load, and switch it's position, say 
with tape 2.  Now that same tape will get past the load point fine.

I have tried the drive on a SunBlade 2000 with solaris 9, and a Ultra 2 
with solaris 8.  On both machines I altered the st.conf file according 
to Quantum's direction, then did a boot -r.  The tapes we are trying to 
read are newly written DLT4's, written in DLT7000 mode, which Quantum 
assures me are read-compatible with SDLT drives.

If anyone has any suggestions, please let me know. We are getting 
desperate, and I would rather not have to send the drive back.

~S

In article <35qcnqF4p36jqU1@individual.net>,
 Shea Martin <smartin@arcis.com> wrote:

> We just got  a new SDLT stacker from Overland.  I am having a heck of a 
> time making the drive work with our existing software under solaris 8.
> 
> The following is our setup, prior to the new Overland LoaderXpress SDLT 
> 320 (LXB).
> 
> We have tape 4 stackers at our shop; three 3490's (two of which are 
> Overland), one IBM 3590.
> 
> The stackers are not used for backup, but we receive binary data from 
> our clients on boxes of tapes.
> 
> We have our own software for reading the data off of the tapes.  It 
> works well with our existing stackers. All of the drives have two 
> library modes 'system' and 'auto'.
> 
> I use the MTIO interface with ioctl(), within C/C++. Here is how I 
> unload a tape, then load the next one:
> 
> System Mode
> 1 ioctl::rew
> 2 ioctl::offline
> 3 library then physically ejects the tape when offline is finished
> 4 the ioctl::offline call returns
> 5 ioctl::load
> 6 the library grabs the next tape and 'loads' it.
> 7 the ioctl::load returns
> 8 read(2)
> x ...
> 
> Auto Mode
> 1 ioctl::rew
> 2 ioctl::offline
> 3 library then physically ejects the tape when offline is finished
> 4 the ioctl::offline call returns
> 5 the library grabs the next tape and 'loads' it.
> 6 program waits an preset time until the next tape inserted in drive.
> 7 ioctl::load, which returns immediately
> 8 read(2)
> x ...
> 
> The LXB offers 'random' and 'sequential' mode, instead of 'system' and 
> 'auto'. The library responds slightly different to my MTIO commands than 
> our other 4 stackers.
> 
> In 'random' mode, the ioctl::offline offlines the tape, but does not 
> eject it, so the subsequent load command just 'loads' the same tape.
> 
> I decided that I could live with 'auto' or 'sequential'.  But I keep 
> running into an issue where the ioctl::load  in step 7 fails, even 
> though the new tape is physically in the drive.
> The funny thing is that it works for the first 3 or 4 tapes in the 
> magazine, then after loading the next tape, the ioctl::load fails.  On 
> the ioctl::load failure my software exits. The drive then does not 
> respond to an 'mt status', saying that no tape is loaded or drive is 
> offline. Using a c program I wrote to interactively send 
> read/load/offline/open/close at the user's request, I can then do an 
> open.  Now any call but close and offline fail, so I do an offline, this 
> ejects the tape and loads the next one.  Then I do a load, and exit my 
> program.  Now the drive responds to an mt status again.
> 
> During the periods where the drive will not respond to an mt status (as 
> mentioned above), the LCD reports the SDLT drive, and the robot as idle, 
> and the green "ready" light is on.  But if I look at the tape format in 
> the SDLT1 menu of the LCD, it shows 'not loaded'.  So the tape is in the 
> drive, just not ready at load point.
> 
> I can take the tape that fails to load, and switch it's position, say 
> with tape 2.  Now that same tape will get past the load point fine.
> 
> I have tried the drive on a SunBlade 2000 with solaris 9, and a Ultra 2 
> with solaris 8.  On both machines I altered the st.conf file according 
> to Quantum's direction, then did a boot -r.  The tapes we are trying to 
> read are newly written DLT4's, written in DLT7000 mode, which Quantum 
> assures me are read-compatible with SDLT drives.
> 
> If anyone has any suggestions, please let me know. We are getting 
> desperate, and I would rather not have to send the drive back.
> 
> ~S

If you can see the drive in a scsi-probe and mt responds when you have a 
tape in the unit, that's about all you can do from Solaris' point of 
view.  The rest is up to you.  If you have the time and perhaps can get 
the hardware specification manual that describes the inner workings of 
the drive, then go for it.  Otherwise, return it and buy a drive that's 
not so hard to work with.  How much is your time worth here?

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

Michael Vilain wrote:
> In article <35qcnqF4p36jqU1@individual.net>,
>  Shea Martin <smartin@arcis.com> wrote:
> 
> 
>>We just got  a new SDLT stacker from Overland.  I am having a heck of a 
>>time making the drive work with our existing software under solaris 8.
>>
>>The following is our setup, prior to the new Overland LoaderXpress SDLT 
>>320 (LXB).
>>
>>We have tape 4 stackers at our shop; three 3490's (two of which are 
>>Overland), one IBM 3590.
>>
>>The stackers are not used for backup, but we receive binary data from 
>>our clients on boxes of tapes.
>>
>>We have our own software for reading the data off of the tapes.  It 
>>works well with our existing stackers. All of the drives have two 
>>library modes 'system' and 'auto'.
>>
>>I use the MTIO interface with ioctl(), within C/C++. Here is how I 
>>unload a tape, then load the next one:
>>
>>System Mode
>>1 ioctl::rew
>>2 ioctl::offline
>>3 library then physically ejects the tape when offline is finished
>>4 the ioctl::offline call returns
>>5 ioctl::load
>>6 the library grabs the next tape and 'loads' it.
>>7 the ioctl::load returns
>>8 read(2)
>>x ...
>>
>>Auto Mode
>>1 ioctl::rew
>>2 ioctl::offline
>>3 library then physically ejects the tape when offline is finished
>>4 the ioctl::offline call returns
>>5 the library grabs the next tape and 'loads' it.
>>6 program waits an preset time until the next tape inserted in drive.
>>7 ioctl::load, which returns immediately
>>8 read(2)
>>x ...
>>
>>The LXB offers 'random' and 'sequential' mode, instead of 'system' and 
>>'auto'. The library responds slightly different to my MTIO commands than 
>>our other 4 stackers.
>>
>>In 'random' mode, the ioctl::offline offlines the tape, but does not 
>>eject it, so the subsequent load command just 'loads' the same tape.
>>
>>I decided that I could live with 'auto' or 'sequential'.  But I keep 
>>running into an issue where the ioctl::load  in step 7 fails, even 
>>though the new tape is physically in the drive.
>>The funny thing is that it works for the first 3 or 4 tapes in the 
>>magazine, then after loading the next tape, the ioctl::load fails.  On 
>>the ioctl::load failure my software exits. The drive then does not 
>>respond to an 'mt status', saying that no tape is loaded or drive is 
>>offline. Using a c program I wrote to interactively send 
>>read/load/offline/open/close at the user's request, I can then do an 
>>open.  Now any call but close and offline fail, so I do an offline, this 
>>ejects the tape and loads the next one.  Then I do a load, and exit my 
>>program.  Now the drive responds to an mt status again.
>>
>>During the periods where the drive will not respond to an mt status (as 
>>mentioned above), the LCD reports the SDLT drive, and the robot as idle, 
>>and the green "ready" light is on.  But if I look at the tape format in 
>>the SDLT1 menu of the LCD, it shows 'not loaded'.  So the tape is in the 
>>drive, just not ready at load point.
>>
>>I can take the tape that fails to load, and switch it's position, say 
>>with tape 2.  Now that same tape will get past the load point fine.
>>
>>I have tried the drive on a SunBlade 2000 with solaris 9, and a Ultra 2 
>>with solaris 8.  On both machines I altered the st.conf file according 
>>to Quantum's direction, then did a boot -r.  The tapes we are trying to 
>>read are newly written DLT4's, written in DLT7000 mode, which Quantum 
>>assures me are read-compatible with SDLT drives.
>>
>>If anyone has any suggestions, please let me know. We are getting 
>>desperate, and I would rather not have to send the drive back.
>>
>>~S
> 
> 
> If you can see the drive in a scsi-probe and mt responds when you have a 
> tape in the unit, that's about all you can do from Solaris' point of 
> view.  The rest is up to you.  If you have the time and perhaps can get 
> the hardware specification manual that describes the inner workings of 
> the drive, then go for it.  Otherwise, return it and buy a drive that's 
> not so hard to work with.  How much is your time worth here?
> 

Overland's support was at first hesitant as soon as I told them we were 
using our s/w not off the shelf back up software.  But I just got a 
phone call from them, and they seem to be willing to help now.  So I 
will work with them, and see if something can be worked out before I 
return the drive.

~S

Shea Martin wrote:
> 
> Overland's support was at first hesitant as soon as I told them we were 
> using our s/w not off the shelf back up software.  But I just got a 
> phone call from them, and they seem to be willing to help now.  So I 
> will work with them, and see if something can be worked out before I 
> return the drive.
> 
> ~S

FYI, Overland's support gave me a beta version of the firmware, which 
fixed the issues, and the drive now works in sequential mode.

~S

Shea Martin <smartin@arcis.com> writes:


> Shea Martin wrote:
> > Overland's support was at first hesitant as soon as I told them we
> > were using our s/w not off the shelf back up software.  But I just got
> > a phone call from them, and they seem to be willing to help now.  So I
> > will work with them, and see if something can be worked out before I
> > return the drive.
> > ~S
> 
> FYI, Overland's support gave me a beta version of the firmware, which
> fixed the issues, and the drive now works in sequential mode.
> 
> ~S

Speaking of which, what are a few of the tape changer vendors that don't
insist on a "support contract" before they'll do simple things like
supply updated firmware?

I just had a little exchange with Spectra Logic who won't give any
useful support- or even firmware updates- for an older unit of theirs I
rescued from excess.  I can see not wanting to get into support, but not
even a firmware update... sheesh.  As if I'm going to shell out a few
grand for them to email me a couple meg file to help me refurb a 5 year
old changer.  As if I'll ever buy anything from them in the future
either.

Gregm

Greg Menke wrote:
> Shea Martin <smartin@arcis.com> writes:
> 
> 
> 
>>Shea Martin wrote:
>>
>>>Overland's support was at first hesitant as soon as I told them we
>>>were using our s/w not off the shelf back up software.  But I just got
>>>a phone call from them, and they seem to be willing to help now.  So I
>>>will work with them, and see if something can be worked out before I
>>>return the drive.
>>>~S
>>
>>FYI, Overland's support gave me a beta version of the firmware, which
>>fixed the issues, and the drive now works in sequential mode.
>>
>>~S
> 
> 
> Speaking of which, what are a few of the tape changer vendors that don't
> insist on a "support contract" before they'll do simple things like
> supply updated firmware?
> 
> I just had a little exchange with Spectra Logic who won't give any
> useful support- or even firmware updates- for an older unit of theirs I
> rescued from excess.  I can see not wanting to get into support, but not
> even a firmware update... sheesh.  As if I'm going to shell out a few
> grand for them to email me a couple meg file to help me refurb a 5 year
> old changer.  As if I'll ever buy anything from them in the future
> either.
> 
> Gregm
> 
> 
> 
I can say that overland was very good.  When the problem was beyond 
them, the went to Quantum (only quantum can make dlt drives), and they 
me non-public version of the firmware.

Having said that, the drive was brand new, and I mentioned that I might 
just return it.  But the out of the box warranty on Overlands stackers 
is 3 years full support.

Personally I think firmware should be on the download page of the 
manufacturer's website.

~S