I first really encountered this issue when a customer asked me to testify that he was lied to by STC when they sold him a device with 77GB of claimed storage but MXG reported only 72GB could be used.
And while I agree that GiB should be used wherever possible, I can't change the MXG formats that print "GB" to "GiB" because, first, I prefer to avoid mixed case :) and second, nicely collimated reports would wrap with the extra character. Barry Herbert W. "Barry" Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 [email protected] http://www.mxg.com - FAQ has Most Answers [email protected] - invoices/PO/Payment [email protected] - technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 - prefer email, still works -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Joel C. Ewing Sent: Wednesday, October 22, 2014 3:48 PM To: [email protected] Subject: Re: QUESTION ABOUT VSAM / VSAM EXTENDED On 10/22/2014 10:00 AM, John Eells wrote: > [email protected] (Chase, John) wrote: > <snip> >>> * I believe that is most likely GiB for the pedantic among us. >> >> IIRC, DASD capacities are expressed in decimal, rather than binary, >> quantities: >> >> 4KB = 4,000 bytes; >> 4MB = 4,000,000 bytes; >> 4GB = 4,000,000,000 bytes; >> Etc. > > This is perhaps the strangest marketing decision ever made by the > industry. I don't even know who started it (IBM or a PCM way back > when--it certainly predates me). But while it's true that we advertise > (unformatted, IIRC) disk space in powers of ten, most system limits > are in powers of two, including this one. > Actually, I always thought it made perfect sense for DASD capacities to use decimal conventions. The capacity in characters/bytes per track, number of tracks per cylinder, and number of cylinders per device for early DASD were based on physical attributes of the device having nothing to do with powers of 2. Decimal notation and power-of-ten multipliers were a natural choice. Computer architectures existed in 1950s and 1960s that didn't use binary addressing of main memory either, and those used decimal suffix conventions for describing memory capacity as well. It was only on machines where the hardware instruction architecture used binary addressing and memory increments were a power of two that KB, MB, and later GB became "corrupted" when talking about memory space to mean what should now be called KiB, MiB, and GiB. Although today's hard drives may typically have a fixed-block architecture with a block size that is a power of two, empirical evidence shows it is still the case that the number of blocks per track and cylinders per device is still constrained by physical properties of the drive that have no relation to powers of 2, so it still makes sense to continue to describe capacity with decimal multiplier suffixes. What I instead still find extremely strange is the decision with MVS-z/OS to go with binary power multipliers for space values in SMS, JCL space allocation by records, and ISMF space displays, which went counter to long-established DASD space conventions. The size required for a typical data set is mainly a function of logical record size and maximum number of records, neither one of which quantity is constrained to a power of two and most certainly would be described by the end-user community using decimal values, not values with binary multipliers. At the vary least, since the introduction of standard binary suffixes in 1998, one should consistently use the correct suffix notation whenever possible, and especially to avoid confusion where binary memory notation and non-binary DASD notations collide. The VSAM file limit is based on a binary addressing constraint on the total number of bytes in all CIs within the file and should be expressed as 4 GiB. I would hope there is at least a goal in place to gradually make all IBM documentation and software displays compliant with the 1998 suffix standards to avoid ambiguity and confusion to newcomers unfamiliar with the confusing contextual interpretation of these suffixes that was required before 1998, but which should now be avoided. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
