EZY! The Outer Prefixes in the Metric System

[DonRocks]

Many people know gigabytes (one billion bytes).

Many people in the data industry know terrabytes (one trillion bytes, which deals with satellite data).

Then there's a big drop-off, but we're almost done.

A select few know petabytes (one quadrillion bytes).

But then there are three more levels, and they're EZY!

Exabytes, one quintillion bytes.

Zettabytes, one sextillion bytes.

and Yottabytes, one septillion bytes. That's as high as it goes!

And it goes just as low, too:

Many people know nanobytes (one billionth of a byte).

But there's also a trillionth, quadrillionth, quintillionth, sextillionth, and septillionth as follows:

pico, femto, atto, zepto, and yocto.

Here's a chart that will help you remember. Believe it or not, they *are* worth memorizing - you will come across the terms in everyday articles from time-to-time:

Just learn this - it will help you, and I'll help you out if you're stumbling.

[Al Dente]

Many people know nanobytes (one billionth of a byte).

But there's also a trillionth, quadrillionth, quintillionth, sextillionth, and septillionth as follows:

pico, femto, atto, zepto, and yocto.

I love the Marx Brothers.

[DonRocks]

I love the Marx Brothers.

(This made the laugh committee laugh.)

[The Hersch]

This is actually not right when applied to computer storage. One kilometer = 1000 meters, but one kilobyte = 1024 bytes. Unlike metric measurements, which go by powers of 10, computer storage measurements go by powers of 2. So one exabyte = 2⁶⁰, not 10¹⁸. Sixteen exabytes = 2⁶⁴, which is the limit of 64-bit addressing. I find it rather unfortunate that the two different measurement systems use this homonymous vocabulary.

[DonRocks]

This is actually not right when applied to computer storage. One kilometer = 1000 meters, but one kilobyte = 1024 bytes. Unlike metric measurements, which go by powers of 10, computer storage measurements go by powers of 2. So one exabyte = 2⁶⁰, not 10¹⁸. Sixteen exabytes = 2⁶⁴, which is the limit of 64-bit addressing. I find it rather unfortunate that the two different measurement systems use this homonymous vocabulary.

This calls for convert-me.com.

[The Hersch]

This calls for convert-me.com.

I'm not sure how useful a conversion of 16 exabytes into 1.845*10¹⁹ would be in the real world, or perhaps I should say in the 64-bit world.

[DonRocks]

I'm not sure how useful a conversion of 16 exabytes into 1.845*10¹⁹ would be in the real world, or perhaps I should say in the 64-bit world.

True. I'm also not sure how profound someone saying 'To Be' is in a work of literature.

[The Hersch]

True. I'm also not sure how profound someone saying 'To Be' is in a work of literature.

Or Not to Be?

Please indulge me in a little trip down memory lane. IBM announced the System 360 computing platform in 1964. The remarkable visionaries who engineered the architecture created a 24-bit addressing scheme, which allowed the use of up to 16 megabytes of main memory (usually called "storage" in the mainframe world). This was before anyone had thought up virtual storage, when nobody could imagine real memory sizes as large as 16 meg. Perhaps the most important aspect of the System 360 was IBM's commitment to maintaining perpetual upward compatibility. Previously, with IBM systems and systems from every other computer manufacturer, each new machine made all of the code written for older machines unusable. To upgrade hardware, you had to re-write all your software. With the 360, IBM basically said to its customers: Okay, one more painful upgrade, but we'll never put you through this again. Their keeping of that promise till this day goes a long way toward explaining why the IBM mainframe is still the rock upon which large organizations rely for data processing.

When I came on the scene in 1979, the current architecture was System 370, which still maintained 24-bit addressing, but also included virtual storage, which allowed for the simulation of 16 megabyte address spaces by moving pieces of storage called pages from main storage to disk when they weren't immediately needed, and bringing them back when they were, using something called dynamic address translation. By this time there was also something called Multiple Virtual Storage, or MVS (blessed be its name), which allowed for many address spaces of 16 megabytes each all coexisting within a system image.

System 370 XA, introduced in 1983, expanded the addressability from 24 to 31 bits. This was inelegant, but an expedient way for IBM to maintain the upward compatibility they had guaranteed in 1964. There was actually room in the places that addresses were stored for 32-bit addresses, which many other platforms later provided, but the high-order bit in 370 XA was used as a "mode bit", which signaled whether the address to follow was 24 or 31 bits in length. 31 bits provided the capability to address 2 gigabytes of storage (32 bits give you 4 gigabytes), and also allowed for programs written for 24-bit addressing to run without modification. System 370 ESA and System 390 maintained the 31-bit address scheme, but provided ways that programs could use multiple 2-gigabyte address spaces simultaneously, which was exploited in many ways but most importantly allowed for lots and lots of data to be held in memory, avoiding the cost of reading and writing to disk or tape storage.

By this time real memory was getting cheaper and cheaper, and more and more plentiful. Where a system might have had only 256 kilobytes of real memory in 1964, by the late 1990s real memory sizes were creeping up into the low gigabytes. Then in 2000, IBM introduced z/Architecture, which superseded the System 390, with 64-bit addresses allowing virtual storage sizes of 16 exabytes. (This was when Hitachi and Fujitsu abandoned the mainframe market.) At the time, and I don't know if this is still the case (probably not), but it was suggested that 16 exabytes was actually more memory than all of the disk storage in use in the entire world. Again, this is virtual storage; I don't remember the largest real storage that's available on the current line of mainframe processors, but I think it's in the low terabytes. (The relatively modest system I work on has 96 gigabytes of real storage.) But among the really remarkable features of z/Architecture is that IBM has still maintained the upward compatibility promised in 1964. A COBOL program, for example, written and compiled in 1964 on a 360 system, will run today on the current generation of mainframes without even being recompiled.

I've been working on IBM mainframes for a long time, and I guess it's lucky that I think they're great. It would be depressing if I didn't.