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 <[EMAIL PROTECTED]> >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>
