Hi *SM'ers,

Does anybody know how to read the LTO Cartridge memory from the LTO cartridge?
The LTO specs/brochure show an expected life cycle of about 1 million mounts 
and recommends replacement after about 5000 loads.
We want to know how close we are to this figure. TSM forgets about mounts as 
soon as a volume gets scratched...

Now did somebody perform the exercise Richards Sims describes below?
If not... I see an opportunity here.... I never did SCSI programming, so there 
must a first time for everything :-/

Thanks!

Marcel Anthonijsz
Central Data Storage Manager (a.k.a. storman)
Shell Information Technology International B.V.
PO Box 1027, 2260 BA  Leidschendam, The Netherlands

Email: Marcel.Anthonijsz.-at-.shell.com
Internet: http://www.shell.com

Date:      Jul 01, 09:42 
From:      Richard Sims <rbs AT BU DOT EDU> 

>Question is: Do you possibly know any software capable of extracting info
>from LTO CM??
>(I mean of course a program that can be run against a suspected cartridge)
>
>Wieslaw

Now, you know you weren't supposed to ask that question...  :-)

My research indicates that vendors don't consider that customers should need
to access the Medium Auxiliary Memory (MAM) - the industry generic name for
an in-cartridge non-volatile memory chip which tracks usage and other info.
The manual "IBM TotalStorage LTO Ultrium Tape Drive - SCSI Reference"
(GA32-4050) fully describes their MAM and how to read and write it via SCSI
commands.  The device driver programming manual (in this case, "IBM Ultrium
Device Drivers - Programming Reference (GC35-0483)) provides many ioctl
functions which make it easier for a programmer to invoke what resolve to SCSI
commands; but in this case I see no ready operation for getting MAM data.
Those ioctl operations are what the handy-dandy ntutil and tapeutil commands
invoke to acquire info, and I see nothing in their doc saying that they can
return it (though it might be implicitly returned from other operations).

All this is to say that with some SCSI programming, the information could be
obtained and presented.  We don't have LTO here, so I'm not in a position to
try this out.  So this remains an exercise for some industrious systems
programmer out there having LTO on-site.

  Richard Sims, Sr. Systems Programmer, Boston University OIT
      <http://people.bu.edu/rbs>