IBM 3390 DASD Model Numbers
What do they mean?

I think it was Aloysius Shakespeare who once said,

What's a 3390 Model 9? That which we call a Model 9 by any other name would spin was well.

When you buy storage, there are two forms of identification:

  1. The vendor-specific identification.
  2. The IBM Extended Count-Key-Data (ECKD) architecture-defined type and model.

Both pieces of information are available to the host, but the vendor-specific info is just tourist information. No decisions are made based on it. The vendor ID is available via the READ CONFIGURATION DATA I/O command, and the architecture data is available from SENSE ID and READ DEVICE CHARACTERISTICS I/O commands. You can see both in the z/VM 6.4 IOEXPLOR command.

But let's look at the architecture data, as that's where the confusion begins.

The latest generation of traditional mainframe disk storage devices, often referred to as DASD (pronounced das-dee), are designed to conform to the IBM-defined Extended Count-Key-Data (ECKD) architecture. That architecture defines a reference device called the "3390", after the original IBM 3390 disk drive introduced in the early 1990s.

In ancient times, the details of a disk storage device (geometry and functionality) were all contained in a book which developers would translate into hard-coded information in the host device drivers. The operating system would ask the device "What kind of disk are you?" and would then use the answer to decide which device driver to use. And in addition to the device type, the device would also provide a model number so that the device driver could optimize for a specific model. Very traditional and a big waste of time and money. Also very annoying in the VM environment since minidisk sizes wouldn't match the device model. Grrrrr!

So when the IBM 3380 was introduced, new architecture was added that enabled a 3380 device driver to avoid having to add code whenever a new model was introduced. The device driver would issue a standard query to the device to get all the data it needed.

The IBM 3390 raised the bar significantly higher, so yet more new architecture was introduced and a new 3390 device driver was written. At this point the architecture was sufficiently mature that the device type was frozen.

All future changes could be handled using the existing query functions without advanced knowledge of what was installed and configured. So at that point being a 3390 simply meant that ECKD architecture was implemented, and that the host should query the device for its geometry (track capacity, number of cylinders or blocks), and functional capabilities (Flashcopy, HyperPAV, PPRC, etc.).

So a quarter of a century after it's introduction, the 3390 remains the basic device type because there has been no need to change it. Elegant, indeed, as it speaks to the foresight of the IBM ECKD architects.

The early 3390 devices had a predefined fixed geometry, so you could still infer the size of a volume from the model number. The IBM 3390 Model 9, however, marked the end of that era.

To determine the size of a Model 9, the host must ask the device. The good news was that the 3380 and 3390 device drivers had already been doing this for a long time and so it was a difference that had no real effect on the operating systems. (The system programmers, well, that's a horse of a different color and the reason for this essay.)

That architecture served well for many many years, but even it had to give way to the IBM 3390 Model A. The new model was necessary so that the ECKD architects could introduce a new data addressing scheme that allows the program to reference more than 65520 cylinders and a new way for device to discover the size of such large "extended addressing" volumes (EAVs), while maintaining compatibility with 3390 Model 9 device drivers.

So with that in mind, know that there are only five architectural models: 3390 Model 1, 2, 3, 9 and A. That's it. Five. The architectural model number is conveyed using an annoyingly different set of numbers. Use CP QUERY DASD DETAILS to look at the DEVTYPE on the first line. It will show:

  • 3390 Model 1 as a 3390-02
  • 3390 Model 2 as a 3390-06
  • 3390 Model 3 as a 3390-0A
  • 3390 Model 9 as a 3390-0C
  • 3390 Model A as a 3390-0E

Watch out for the 3390-0A and remember it's not a 3390 Model A!

Further, stop trying to tie the number of cylinders with the architectural model. True, the 3390 Models 1, 2, and 3 all had a fixed number of cylinders per volume, but remember that the Model 9s and As have a variable number of cylinders, with Model As having the ability to go beyond 65520 cyls. The storage volume allocation UIs typically provides some predefined models as well as the ability to create custom-sized volumes. The vendor and level of the software dictate the available allocation options.

What about the IBM 3390 Model 27 and Model 54, you ask? Well, they weren't real, not in any architectural sense. They were simply shorthand for larger-capacity 3390 Model 9s. The original Model 9 had a capacity of 9 times the Model 1, or 10017 cylinders. Additional models raised that to 32760 cyls (model 27) and then to 65520 cyls (model 54).

I have often heard, "We only have mod 54s." And yet I know that really means, "My storage admin will only create mod 54s." Well, that's not really true. Your storage admin can create devices of any size he or she desires, subject only to the limitations of the management software.

In conclusion, when someone asks you the size of a volume, the answer for a Model 9 or Model A should be in cylinders, not a model number. The model number is too ambiguous. If they ask you what model you have, answer with both the model number and the size.

And when someone says they need a mod 9, you ask, "How big?"

I hope this has been both educational and helpful. As always, Thank You for your patronage!

The information provided, and views expressed on this site are my own and do not represent the IBM Corporation.