Thanks Thomas for the debug tools. The Jaz drive is a real SCSI device and is using the 2nd.scsi.device on the A4000T at unit 1. I'm attaching the SCSISnoop for when 3.1.4.1 HDToolbox is launched vs. the 3.9 version (both being used in the 3.1.4.1 env.). I also noticed when I use the SCSIQuery, it also is does the defect check and it is there that Jaz drive hangs. The 3.9 HDToolbox doesn't look like it does that step.
Thanks, I seem to remember this when creating the IOTools. Collecting the defect data from a JAZ drive may take a while, so it probably does not hang, but is just busy. Instead of the size of the defect list, the IO drives had a custom SCSI command to read out the lifetime of the medium, but that helps little if you need the precise list of defect sectors. So just give it some time to process the results. The time should be rather measured in minutes but seconds, but the command will succeed after quite a while.
This said, all the defect management by HDToolBox is pretty much nonsense for even remotely modern drives - they do that all themselves. In principle, HDToolBox can collect such defect lists (which it does) and store it in the RDB of the disk (which it does) where it could be used by the device running the system, to work around such defects. This made some sense in the time of RLL and MFM disks which had no defect management in their firmware (which firmware?), but in how far the scsi.device implementation of this is working I do not know. For (real) scsi based disks (and anything more modern), this is just bogus as the drive manages defects itself.
One way or another, HDToolbox is a dinasour, and this defect management should really go as it is non-sensical. But then again, I would prefer not to waste any more time in this dinasour, and let it get extinct for good. The hdwrench library of 3.9 is in better shape and omits this step (for reasons), but its unfortunately not available for 3.1.4 and successors.