December 2010

Q.“In your DTB APIs, you have tests that can test by number of minutes. But how can I do say a 100 second test?”

A. With the new VCPSSL that comes with your 8.3 release, we have added the capability to do tests by number of seconds. In your case you want to do a 100 second test – this is 1 minute 40 seconds. What you do is add the 40 seconds to the upper 16-bits of the value you pass to the API. Here’s how you would do this:

Int nNumberOfMinutes = 1;

Int nNumberOfSeconds = 40;

Int nValueToPassToAPI = (nNumberOfSeconds << 16) | nNumberOfMinutes; //This puts the number of seconds into the high 16 bits, number of minutes into the low 16 bits

$213,000 anyone?At a recent auction an original Apple-1 circuit board kit sold for a whopping $213,000. That got us thinking – – – what might the original STB tester circuit board sell for?

Circa 1988…

Long nights and weekends, “midnight-engineering” with an early copy of the SCSI spec in one hand and a wirewrap tool in the other. Our first “Portable SCSI Tester” was on overclocked 8051 struggling to monitor the phases of the SCSI bus.

No SCSI chips, no programmable logic arrays. Just an 8051 and some glue chips, and 32K of EPROM.

It was high impedance so it could just hang onto the SCSI Bus and not interfere… too much. Five MB/second SCSI was all she wrote – but it could monitor the bus and capture/display the commands and data going by.

Since there was some room left in that 32K EPROM the thought came – “could we make it talk to SCSI devices as well as listen to them?” and the box became an active SCSI tester. The wirewrap gave way to a circuit board and by mid-1990 the STM 100 was on the market!

At the time there was a very lucrative market selling disk drives to go on certain Unix-based computers. The problem was you needed to be a Unix guru as well as drive-savvy to be able to make the drives you sold “plug and play”. This was because there was a special “label” written on the drives. The label had some drive geometry info, some info about what partitions it had, and a magic number. To prep these drives required a very expensive machine and a Unix wizard to operate it.

Our little SCSI bus monitor – the early ancestor of BAM – showed us what was being written to the drives during “labeling”. A little detective work and voila – we were writing these labels ourselves, for any SCSI disk drive!

We still a little room left in that EPROM so we thought “ why don’t we stick in a secret operation that a user could call up that would instantly prep any SCSI drive?”

Why not indeed!

Suddenly the little box was something that a lot of fledgling “System Integrators” could use to get into the very profitable add-on disk business. And so, if you wanted to get into a profitable business on the cheap in 1990 you could just stop our booth 606 at the Summer 1990 Sun Expo trade show, spend $1,000 and have the magic formula for success!

Hardware gives way to Software

It wasn’t too long before that 32K EPROM was full. And honestly, writing 8051 assembly code was neither fun nor rapid. And then there was that new SCSI spec that went to 10MB/s… It was plain to see that the little circuit card had reached its useful end. It was time for it to unplug and go sit on the beach and enjoy the fond memories it had.

A big change was needed.

Something that wouldn’t become obsolete every time a new spec came down the pike.

Something that didn’t have a limit.

Something that could be expanded upon quickly and easily.

And so the first software SCSI Toolbox was born.

From the Fall of 1990 until the Spring of 1992 a whole new tool was designed and implemented. It ran on DOS and was programmed using Borland C. It used the ASPI library so it could work with any SCSI card. The first package was sold in a hardware/software set. A parallel printer port to SCSI adapter (!) and the new SCSI Toolbox software. All you needed was any PC. Plug into the printer port and away you went. It sounds ridiculous now, but it was actually a very good combination for anyone who was doing field service. A fully portable SCSI test solution.

Almost 2011 now…

It has certainly been a long time since 1988. We’ve migrated from DOS, to Windows, to Mac, to SunOS/Solaris, to HP-UX and SGI Unix, to Linux, to more flavors of Windows…a long, long way from that little 32KB EPROM and the 8051 assembler. As storage has progressed from SCSI to faster and wider SCSI, to Fibre Channel, iSCSI, ATA, SATA, SAS and so forth we have adapted our software to stay at the front edge of storage technology.

Computer storage hasn’t gone away. And we’re so happy to say that neither have we!

Any bidders?

And so we come back to auctions. The world-famous STB Museum was kind enough to bring the original prototype circuit card for the very first SCSI tester – “Mr. SCSI” itself – out of retirement for a photo session…

Please note that like the Apple-1, the winning bidder on MrSCSI lot #1 will receive not only the circuit board and case, but also the original press ad as shown at the beginning, autographed by Dr SCSI himself!

Please send all bids (reserve price only $212,000) to MrSCSIAuction@STBSuite.com

Best wishes, Merry Christmas and God Bless to you all in the New Year!

There are times when doing device command compliance that you may wish to go beyond just seeing if a device executes a command without a check condition. In this article we will discuss one way to compare the data being returned by the devices under test.

In this example we will be comparing the sense data of two different drives. Of course the same approach can be used to compare write/read data, log page data, inquiry data, etc.

We will use the STB Suite Original-mode User-Defined CDB function, and will show how to use BAMto confirm proper CDB execution.

Collecting the data

Follow these steps to collect the data from your devices:

1. First run STB in original mode.

2. Select your drive to test in the device menu,

3. and also start BAM and select the same device.

4. Start the BAM capture.

5. In STB, right-click on the device to test and choose User Defined CDB’s from the quick command menu.

6. Clear the data buffer by clicking Buffers and setting all bytes to zero

8. Save the data by going to Buffers->File Operations->Save to file. We will save the buffer data in the same format that it is displayed, that is as ASCII text and with the buffer addresses shown. This will make the data compare operation much easier.

9. At this point you can stop the BAM capture and view the CDB and response as a quick check to be sure that everything went as you planned

Repeat the above process for each device you want to compare. For this example we will collect the Mode Page data from one drive, then change a few settings in the Mode Pages, then re-collect the data for comparison.

Simply specify your first data file for the right side, and your second data file for the left. Any and all differences will be highlighted, and with the buffer address shown you can consult your SCSI command documentation to determine exactly which bits of which bytes of which mode pages are different between the two devices.

Simple! In this example we can see that byte 2 of mode page 8 is different.

Summary

The STB Suite makes issuing CDB’s and grabbing responses and data a breeze, and Winmerge makes finding and spotting the differences a simple and quick task.

Schedule your GoToMeeting with STB Today!Do you have questions about how to best use the STB Suite in your business? STB is happy to work with you in an interactive “live” environment to help you get the most out of your Toolbox. The cost? If you are a current Performa customer it is free! The commitment? Training sessions run between 30 and 60 minutes.

Here is a list of some recent customer training sessions that STB has conducted – live, interactive web sessions presented by STB programmers: