The Fujitsu M8100 3590 format drive is no longer manufactured or supported by Fujitsu. This is a great pity for the Seismic industry, but it does help the push towards Hard disk recording.
I won't describe much maintenance for the M8100 here - there are many things that can be done, but there is a very real risk to the drive if performed by untrained personnel.
I do however present some background information and tips.
I won't describe much maintenance for the M8100 here - there are many things that can be done, but there is a very real risk to the drive if performed by untrained personnel.
I do however present some background information and tips.
Fujitsu M8100A Settings Menu
Here is a list of the 'normal' or usual settings for a drive
70: S. TAR SCSI Address required
71: *****
72: S. LNG Language selection
73: S. RDY Y
74: S. *N Yes
75: S. ITS 0
76: S. ACL Auto
77: S. FT1 04
78: S. FT2 00
79: S. FT3 00
80: S. FT4 0F
81: S. FT5 00
82: CLN. T 0090
83: S. IND N
84: S. SDTR N
85: S. WDTR N
86: *****
87: *****
88: S. TYP Standard
89: FSGRP None
90: *****
91: DPSET Display the settings
92: WTROM Write ROM, save settings
Here is a list of the 'normal' or usual settings for a drive
70: S. TAR SCSI Address required
71: *****
72: S. LNG Language selection
73: S. RDY Y
74: S. *N Yes
75: S. ITS 0
76: S. ACL Auto
77: S. FT1 04
78: S. FT2 00
79: S. FT3 00
80: S. FT4 0F
81: S. FT5 00
82: CLN. T 0090
83: S. IND N
84: S. SDTR N
85: S. WDTR N
86: *****
87: *****
88: S. TYP Standard
89: FSGRP None
90: *****
91: DPSET Display the settings
92: WTROM Write ROM, save settings
There are 2 commonly available microcode versions seen in the M8100. For Seismic use, especially in the recorder, one is MUCH better than the other.
The good code version number is 990708C026C026
The Bad Version Number is D4AA0106
It is easy enough to copy microcode from a 'Good' drive to one that has a different version - basically you make a code tape using the good drive and use that to update the bad one. Details are in the manual.
The good code version number is 990708C026C026
The Bad Version Number is D4AA0106
It is easy enough to copy microcode from a 'Good' drive to one that has a different version - basically you make a code tape using the good drive and use that to update the bad one. Details are in the manual.
Different Interface Cards
I have seen 3 different types of SCSI interface cards for the M8100A -
The Dual Differential card should never be used - it creates all sorts of havoc, which is difficult to track down.
Here is a way to tell the difference between the cards without resorting to installing them and using the Drive's offline diagnostics to query :
The single ended card only has 1 bead diode on it, the diff card has 2.
The Diff card has 3 x SN75976A2 chips on it, the SE has none
The Dual Diff card has 6 x SN75976A2 Chips, 4 diodes and 2 LSI ASICs
The part number of the SE card is CA25340-M15202 (Top Side)
The part number of the Diff card is CA25340-M13102 (Top Side)
The part number of the Dual Diff card is CA25340-M09302 (Top Side)
I have seen 3 different types of SCSI interface cards for the M8100A -
- Single ended
- Differential
- Dual Differential
The Dual Differential card should never be used - it creates all sorts of havoc, which is difficult to track down.
Here is a way to tell the difference between the cards without resorting to installing them and using the Drive's offline diagnostics to query :
The single ended card only has 1 bead diode on it, the diff card has 2.
The Diff card has 3 x SN75976A2 chips on it, the SE has none
The Dual Diff card has 6 x SN75976A2 Chips, 4 diodes and 2 LSI ASICs
The part number of the SE card is CA25340-M15202 (Top Side)
The part number of the Diff card is CA25340-M13102 (Top Side)
The part number of the Dual Diff card is CA25340-M09302 (Top Side)
TAPE Problems
In early 2004, crews started to report numerous tape drive failures. It got so bad that I was concerned we would not have enough spare drives to keep our crews running.
It turned out that the problem was not so much the drive, but the tapes. The manufacturer of the tapes (Imation) had made a minor change in their manufacturing process and for some reason, which is still obscure, loading of any of these tapes into an M8100 caused it to fail.
The Failures appeared to be permanent, and even Fujitsu's diagnosis was that the head needed replacement.
With a turn around time of about 3 months and around 8000USD, this was not very attractive, or even realistic considering the limited number of spare drives we had.
Fortuneately, perseverance or perhaps just plain stubbornness paid off, and I discovered a technique to revive supposedly dead drives.
Essentially, you need to run a NEW cleaning tape 20 or 30 times, sometimes more, and periodically run the offline diagnostics to see how things are progressing.
It is essential to use a new cleaning tape. A tape that has been used on another bad drive, can quite easily take out a good drive, leaving you with 2 bad ones.
This is not going to work if the head truly is damaged or worn out, but is well worth a try before sending a drive in for repair - which is a waste of time now, as they are not supported.
Imation was quite receptive to us and very helpful in trying to resolve the problem. According to them, the problem revolves around the Volume Control Record (VCR) which is the first block of information on a tape. It contains format information and various statistics and is transparent to the user (us).
The Fujitsu M8100 cannot write a VCR, but an IBM B1A can
According to Imation, IBM made a change in the format description which Imation complied with (They write a VCR in the manufacturing process). It was this change in format of the VCR that screwed up the M8100. In other words IBM changed the way they write the VCR making it incompatible with Fujitsu drives.
In early 2004, crews started to report numerous tape drive failures. It got so bad that I was concerned we would not have enough spare drives to keep our crews running.
It turned out that the problem was not so much the drive, but the tapes. The manufacturer of the tapes (Imation) had made a minor change in their manufacturing process and for some reason, which is still obscure, loading of any of these tapes into an M8100 caused it to fail.
The Failures appeared to be permanent, and even Fujitsu's diagnosis was that the head needed replacement.
With a turn around time of about 3 months and around 8000USD, this was not very attractive, or even realistic considering the limited number of spare drives we had.
Fortuneately, perseverance or perhaps just plain stubbornness paid off, and I discovered a technique to revive supposedly dead drives.
Essentially, you need to run a NEW cleaning tape 20 or 30 times, sometimes more, and periodically run the offline diagnostics to see how things are progressing.
It is essential to use a new cleaning tape. A tape that has been used on another bad drive, can quite easily take out a good drive, leaving you with 2 bad ones.
This is not going to work if the head truly is damaged or worn out, but is well worth a try before sending a drive in for repair - which is a waste of time now, as they are not supported.
Imation was quite receptive to us and very helpful in trying to resolve the problem. According to them, the problem revolves around the Volume Control Record (VCR) which is the first block of information on a tape. It contains format information and various statistics and is transparent to the user (us).
The Fujitsu M8100 cannot write a VCR, but an IBM B1A can
According to Imation, IBM made a change in the format description which Imation complied with (They write a VCR in the manufacturing process). It was this change in format of the VCR that screwed up the M8100. In other words IBM changed the way they write the VCR making it incompatible with Fujitsu drives.
Here is some interesting information about the VCR, from IBM
==================================================================================
| | FID | DBM | SARS | DBMV/DBMCO| | Cust Data Area ->
==================================================================================
^ ^ ^ ^
| | | |
| | | ----> Logical BOT
| --------------------------------
| |
| ----> VCR (Volume Control Region)
|
----> Physical BOT (Leader Block)
The VCR is used only by the drive, and does not contain any customer data.
The distance between Physical BOT and the start of the VCR is not fixed, but is approximately 9m (on a 3590 standard length cartridge)
The distance between the end of the VCR and Logical BOT is not fixed, but is approximately 2m.
The VCR contain 4 separate blocks of information -
FID (Format Identification) - this block contains information about the tape format, including the track layout, the recording density, the block header structure, etc. From this data, it can be determined what drive model recorded the tape (such as 3590 model B, E, or H) and whether the current drive is capable of reading the tape contents.
DBM (Device Block Map) - this contains a structure describing the currently recorded set of blocks on tape. This is basically the Block ID's at a number of locations on tape, including those at BOT, End of Data, each wrap turn, and at a number of intermediate distances along each wrap. The drive uses this data to accomplish high speed searches and locates (as opposed to having to read every block at lower speeds).
SARS (Statistical and Recording System) - this block contains data structures showing a history of the last 100 mounts of the tape. Each entry shows the serial number of the device, and statistics on how much data was written or read, and also a large set of error statistics.
DBMV/DBMCO (DBM Valid / DBM Checked Out) - this block simply indicates whether the DBM block can be considered as Valid or not. Each time the tape is mounted, if a DBMV is detected, the contents of the DBM are read into memory, and the DBMV is overwritten by a DBMCO. While the tape is mounted, any appends or new write operations will cause updates to the DBM in memory. When the tape is unloaded, the updated DBM is copied from memory back on to tape. The updated SARS block is also written to tape. And then, the DBMCO is overwritten by a DBMV block.
==================================================================================
| | FID | DBM | SARS | DBMV/DBMCO| | Cust Data Area ->
==================================================================================
^ ^ ^ ^
| | | |
| | | ----> Logical BOT
| --------------------------------
| |
| ----> VCR (Volume Control Region)
|
----> Physical BOT (Leader Block)
The VCR is used only by the drive, and does not contain any customer data.
The distance between Physical BOT and the start of the VCR is not fixed, but is approximately 9m (on a 3590 standard length cartridge)
The distance between the end of the VCR and Logical BOT is not fixed, but is approximately 2m.
The VCR contain 4 separate blocks of information -
FID (Format Identification) - this block contains information about the tape format, including the track layout, the recording density, the block header structure, etc. From this data, it can be determined what drive model recorded the tape (such as 3590 model B, E, or H) and whether the current drive is capable of reading the tape contents.
DBM (Device Block Map) - this contains a structure describing the currently recorded set of blocks on tape. This is basically the Block ID's at a number of locations on tape, including those at BOT, End of Data, each wrap turn, and at a number of intermediate distances along each wrap. The drive uses this data to accomplish high speed searches and locates (as opposed to having to read every block at lower speeds).
SARS (Statistical and Recording System) - this block contains data structures showing a history of the last 100 mounts of the tape. Each entry shows the serial number of the device, and statistics on how much data was written or read, and also a large set of error statistics.
DBMV/DBMCO (DBM Valid / DBM Checked Out) - this block simply indicates whether the DBM block can be considered as Valid or not. Each time the tape is mounted, if a DBMV is detected, the contents of the DBM are read into memory, and the DBMV is overwritten by a DBMCO. While the tape is mounted, any appends or new write operations will cause updates to the DBM in memory. When the tape is unloaded, the updated DBM is copied from memory back on to tape. The updated SARS block is also written to tape. And then, the DBMCO is overwritten by a DBMV block.
All this is very interesting, but as far as I am concerned, I do not see how a format change in the VCR manages to completely screw up a drive.
My guess at the time, and I haven't seen anything to change my mind, is that the new format VCR upsets the calibration of the drive's read electronics (how this happens, I do not know). Running the cleaning tape repeatedly allows the drive to slowly recalibrate itself. Fujutsu dispute this, but haven't come up with any alternative.
From the point of view of people in the field, we just need to be able to identify which tapes could be a problem. Imation were very helpful here also and provided the following:
The cartridge ID is defined as a 16 character digits printed out on the bottom shell. The 4th, 5th and 6th digits from the left are YWW= date code. Y is the production year and WW= the production week.
So if we have a tape number F4J23078201052G8,
the date code is 230, representing the 30th week in 2002.
According to Imation, tapes made between March 2003 and March 2004 might have a problem. Not all tapes were affected. In fact it is somewhere between 10% and 30%, but the affected tapes are mixed in with unaffected ones.
So, be wary of tapes with a date code between 308 and 418. These are not 'Bad' tapes - they will work perfectly well in an IBM drive. If you do load one into an M8100 and then the drive doesn't work, try running a new cleaning tape 20 times and see what happens.
I must emphasise how important it is to use NEW cleaning tapes and NEW test tapes when working with drives that have been affected like this. If you use a cleaning tape or a recording tape that has been in another affected drive you stand a very good chance of messing up the drive you are trying to fix!
My guess at the time, and I haven't seen anything to change my mind, is that the new format VCR upsets the calibration of the drive's read electronics (how this happens, I do not know). Running the cleaning tape repeatedly allows the drive to slowly recalibrate itself. Fujutsu dispute this, but haven't come up with any alternative.
From the point of view of people in the field, we just need to be able to identify which tapes could be a problem. Imation were very helpful here also and provided the following:
The cartridge ID is defined as a 16 character digits printed out on the bottom shell. The 4th, 5th and 6th digits from the left are YWW= date code. Y is the production year and WW= the production week.
So if we have a tape number F4J23078201052G8,
the date code is 230, representing the 30th week in 2002.
According to Imation, tapes made between March 2003 and March 2004 might have a problem. Not all tapes were affected. In fact it is somewhere between 10% and 30%, but the affected tapes are mixed in with unaffected ones.
So, be wary of tapes with a date code between 308 and 418. These are not 'Bad' tapes - they will work perfectly well in an IBM drive. If you do load one into an M8100 and then the drive doesn't work, try running a new cleaning tape 20 times and see what happens.
I must emphasise how important it is to use NEW cleaning tapes and NEW test tapes when working with drives that have been affected like this. If you use a cleaning tape or a recording tape that has been in another affected drive you stand a very good chance of messing up the drive you are trying to fix!