64 bit operating systems was Re: 64 bits is a really big number!
On 20 Jul 2006 11:30:02 -0700, in bit.listserv.ibm-main you wrote: Leif Rundberget (as quoted by Joel C. Ewing) wrote: | Be careful with like terms between the PC(intel) world and the mainframe | world. When someone says they have a 64-bit Intel server (Intel, | Solaris, AMD, etc.), it does not mean that the server can access an | address 64-bits long, the 64-bits refers to the width of the bus. So it | can transfer 64-bits in parallel. Since there are 64 bit versions of Windows, Linux and various flavors of Unix I find this hard to believe. rest snipped -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bit operating systems was Re: 64 bits is a really big number!
Clark Morris [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On 20 Jul 2006 11:30:02 -0700, in bit.listserv.ibm-main you wrote: Leif Rundberget (as quoted by Joel C. Ewing) wrote: | Be careful with like terms between the PC(intel) world and the mainframe | world. When someone says they have a 64-bit Intel server (Intel, | Solaris, AMD, etc.), it does not mean that the server can access an | address 64-bits long, the 64-bits refers to the width of the bus. So it | can transfer 64-bits in parallel. Since there are 64 bit versions of Windows, Linux and various flavors of Unix I find this hard to believe. rest snipped I remember to have read something about it when looking for hardware for a new PC. This is what Intel says: http://www.intel.com/technology/64bitextensions/ Intel(r) Extended Memory 64 TechnologyΦ (Intel(r) EM64T) enables 64-bit computing on the server/workstation and desktop platforms when combined with supporting software. Intel EM64T improves performance by allowing the system to address more than 4 GB of both virtual and physical memory. Intel EM64T provides support for: 64-bit flat virtual address space 64-bit pointers 64-bit wide general purpose registers 64-bit integer support Up to 1 terabyte (TB) of platform address space It looks like a real, full 64-bit architecture. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [Fwd: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)]
Actually the terminology is much more ambiguous than that. Register size, address size, bus size within CPU, bus size to memory, bus size to peripherals, could all be different bit widths, and physical hardware register sizes don't have to match the register sizes of the hardware architecture visible to the user. I'm pretty sure larger IBM mainframes have had some internal bus sizes of 64 bits and larger for years, even though the architecture visible to the user only had 32 bit registers and and 31 bit addresses at the time. Since the introduction of IBM S/360 in the 1960's almost all processors have been implemented using microcoding techniques, which means that the choice of hardware physical bus and register sizes is a matter of cost-performance trade offs rather than something uniquely dictated by the logical architecture seen by the users. Leif Rundberget wrote: Be careful with like terms between the PC(intel) world and the mainframe world. When someone says they have a 64-bit Intel server (Intel, Solaris, AMD, etc.), it does not mean that the server can access an address 64-bits long, the 64-bits refers to the width of the bus. So it can transfer 64-bits in parallel. Leif John KcKown wrote: And, just for fun, Sun has implemented a 128-bit filesystem in Solaris! That means that a single filesystem can contain 2**128 bytes of data. Good heavens! I think that most UNIX filesystems are either 32 or 64 bit at present. But don't quote me on that. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bits is a really big number!
Leif Rundberget (as quoted by Joel C. Ewing) wrote: | Be careful with like terms between the PC(intel) world and the mainframe | world. When someone says they have a 64-bit Intel server (Intel, | Solaris, AMD, etc.), it does not mean that the server can access an | address 64-bits long, the 64-bits refers to the width of the bus. So it | can transfer 64-bits in parallel. There is once widely used IBM terminology for this quantity. As far back as the System/360, a model 30 had a FETCH WIDTH of one eight-bit byte and the fastest models, as they came along, had fetch widths of eight bytes. Higher fetch width is good, but it can have odd side effects. There were System/360 models for which Load Halfword (LH) was slower than Load (L) not just because of sign propagation but also because LH fetched four or eight bytes from storage two or six of which then had to be discarded. Analogously, there are z/Architecture situations in which eight-byte (64-bit) instructions are faster than their four-byte (32-bit) variants. John Gilmore Ashland, MA 01721-1817 USA _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bits is a really big number!
On Thu, 20 Jul 2006 18:29:48 +, john gilmore [EMAIL PROTECTED] wrote: Higher fetch width is good, but it can have odd side effects. There were System/360 models for which Load Halfword (LH) was slower than Load (L) not just because of sign propagation but also because LH fetched four or eight bytes from storage two or six of which then had to be discarded. Analogously, there are z/Architecture situations in which eight-byte (64-bit) instructions are faster than their four-byte (32-bit) variants. Are you sure? Color me skeptical. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bits is a really big number!
I clearly remember the first (L faster than LH on some machines) but can't comment on the second (64 v. 32). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Thursday, July 20, 2006 12:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 64 bits is a really big number! On Thu, 20 Jul 2006 18:29:48 +, john gilmore [EMAIL PROTECTED] wrote: Higher fetch width is good, but it can have odd side effects. There were System/360 models for which Load Halfword (LH) was slower than Load (L) not just because of sign propagation but also because LH fetched four or eight bytes from storage two or six of which then had to be discarded. Analogously, there are z/Architecture situations in which eight-byte (64-bit) instructions are faster than their four-byte (32-bit) variants. Are you sure? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
So assuming you could use the whole drive, the number of these current generation drives that you would need to back a single address space is (2**64)/(2**38) = 2**(64-38) = 2**26 = 67,108,864 Back in my old life I once did a presentation at an IBM customer meeting trying to illustrate how much 2**64 is. Besides a similar DASD device calculation, I also did a simpified swap time calculation. At 100MB/s sustained transfer speed, it takes 5850 years to transfer all bytes of a single 64bit AS. Make that 10GB/s and use 100 devices in parallel it still takes 210+ days. According to Word, the PoP has about 4'000'000 characters and is roughly 5cm thick. So 4 of them fit into one 16MB AS and this corresponds to a pile of paper of 20cm height. Going to 31bit multiplies these figures by 128: 512 PoPs and 25.6 meters. Going to 64bit from 31bit multiplies them by another 8 billions: 4400 billion PoPs and you can travel all the way from the Earth to the sun and half this distance further on on that bridge of PoPs. have good journey :-) History has shown all these this will sufficce forever statements have provben that forever is a relatively short period of time. So, I concluded my presentation stating that 64bit will do it for a couple of years. Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL and 64 bits was Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
On 18 Jul 2006 11:32:54 -0700, in bit.listserv.ibm-main you wrote: On Jul 18, 2006, at 6:26 AM, Veilleux, Jon L wrote: I always get blank looks when I ask what would happen if someone actually tried to exploit 64bit addressing to the fullest. How do we provide page space to back these requests? As someone responsible for keeping our mainframes up and running, it worries me that application type people have the ability to crash the system just by a stupid mistake. One STORAGE loop in a 64bit address space and the paging subsystem is toast. I know that there are other exposures that application folks can use to crash the system, but, to me, this looks like an accident waiting to happen. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Joe, You have reason to worry, IMO. I know COBOL types that really need the 64bit arch. Right now they are storing the tables in VSAM datasets and accessing them them as tables should be. They wanted 64 bits 10+years ago. They have gotten around the limitation of COBOL and wrote assembler subroutines to access the vsam datasets. They have updated the the subrountine for multiple VSAM datasets. Right now they ten extra DD statements for spill vsam files. One programmer used to call me up monthly to see if COBOL has finally kept up with the OS. When I left the business 5+ years ago they were begging for relief. Of course until IBM comes through with support for a large number of page datasets, cobol can sit still doing essentially nothing. COBOL as implemented by IBM is catching up with 31 bit in terms of maximum data area sizes. I believe that Microfocus will sell you a 64 bit capable COBOL for other platforms. They may even sell you one for z Linux. With the 64 bit usage by DB2 and Java, not providing 64 bit compile options for COBOL is telling what IBM really thinks of the future of COBOL (and for various reasons I would agree that the need for COBOL is dying). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL and 64 bits was Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
I am of two minds about whether the need for COBOL is dying. On one hand, it has served (and served well) for many years and is very well-suited for its original purpose. On the other hand, as time goes by there are fewer people around who know it. It is becoming increasingly marginalized in the workplace, and anything you can do with COBOL you can do with other more modern languages such as, say, Java. On the other other hand, though, I can run a COBOL program on z/OS with a region size of a few K, whereas I had to up my TSO region from 4MiB to 128MiB just to successfully execute java -version. On the other other other hand, many of the more modern languages are, to be charitable, not suited for non-psychotics. C++, in particular, is an abomination (in my not-as-humble-as-it-should-be opinion, of course). On yet another hand -- I'm up to five hands now -- as verbose as COBOL is, it is still reasonably simple to learn and use. So maybe the need for COBOL is dying, but its usefulness isn't. I haven't looked into any of its newer features, either, so I am hoping to be pleasantly surprised if I ever get around to boning up on it. Jon snip With the 64 bit usage by DB2 and Java, not providing 64 bit compile options for COBOL is telling what IBM really thinks of the future of COBOL (and for various reasons I would agree that the need for COBOL is dying). /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL and 64 bits was Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Brock I am of two minds about whether the need for COBOL is dying. On one hand, it has served (and served well) for many years and is very well-suited for its original purpose. Likewise Latin. On the other hand, as time goes by there are fewer people around who know it. It is becoming increasingly marginalized in the workplace, and anything you can do with COBOL you can do with other more modern languages such as, say, Java. And HLASM. :-) On the other other hand, though, I can run a COBOL program on z/OS with a region size of a few K, whereas I had to up my TSO region from 4MiB to 128MiB just to successfully execute java -version. I think that's called progress. :-| -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: COBOL and 64 bits was Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
I don't want to get into either the: Does IBM need to provide a 64-bit COBOL (for z/OS) compiler - because of business needs of programmers or - because of what it says to their customers about COBOL Nor What is the current need for and what is the future of COBOL in general. *** Personally, I don't hear of a LOT of new development being done in COBOL, but certainly do hear of a lot of applications continuing to run (and being maintained) in COBOL. Similarly, it would really surprise me if many sites were really interested in CHANGING logic to move from VSAM data to internal tables - but I do know of a reasonable number of software products written in COBOL for Unix/Linux that assume a 64-bit FILE system. *** As always (when these topics come up), when/if IBM hears (thru official channels) sufficient need from their PAYING customers for enhancements to COBOL, then I suspect they will (eventually) deliver them. Jon Brock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I am of two minds about whether the need for COBOL is dying. On one hand, it has served (and served well) for many years and is very well-suited for its original purpose. On the other hand, as time goes by there are fewer people around who know it. It is becoming increasingly marginalized in the workplace, and anything you can do with COBOL you can do with other more modern languages such as, say, Java. On the other other hand, though, I can run a COBOL program on z/OS with a region size of a few K, whereas I had to up my TSO region from 4MiB to 128MiB just to successfully execute java -version. On the other other other hand, many of the more modern languages are, to be charitable, not suited for non-psychotics. C++, in particular, is an abomination (in my not-as-humble-as-it-should-be opinion, of course). On yet another hand -- I'm up to five hands now -- as verbose as COBOL is, it is still reasonably simple to learn and use. So maybe the need for COBOL is dying, but its usefulness isn't. I haven't looked into any of its newer features, either, so I am hoping to be pleasantly surprised if I ever get around to boning up on it. Jon snip With the 64 bit usage by DB2 and Java, not providing 64 bit compile options for COBOL is telling what IBM really thinks of the future of COBOL (and for various reasons I would agree that the need for COBOL is dying). /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
On Wed, 2006-07-19 at 13:44 -0500, Ed Gould wrote: The Largeness of the numbers just floored me back then, so I am not impressed with 64 bits at all. I remember once being at a SHARE where an IBMer was talking about the OfficeVision product. Someone commented from the audience about the large amount of memory that the thing required. That's okay, the presenter replied offhandedly, in a couple of years you'll have 16 megabytes on the planar. A SIXTEEN MEGABYTE PC? IS HE OUT OF HIS MIND? How could you possibly justify having that large a memory on your desktop computer? I walked out of the ballroom, figuring that OfficeVision was a dead duck. (Turns out that it was, but not for the reasons I guessed.) 4 megabytes should be enough for anyone -- Me. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL and 64 bits was Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
For a few years, we were presumably in no new COBOL -- just maintain what you have mode. Oddly enough, our code base seemed to keep growing. Apparently, some things just write themselves. For that matter, the whole concept that maintenance is something that could be performed by mindless drones is only rarely true. When I look at what is considered maintenance in the software business, I frequently see complex entities -- added functionality, entire new subsystems, new interfaces. If I maintained my house like that, I would have maintained myself into a 35-room mansion with a sauna and a drawbridge by now. But it's maintenance programming -- it shouldn't take so long. Jon snip Personally, I don't hear of a LOT of new development being done in COBOL, but certainly do hear of a lot of applications continuing to run (and being maintained) in COBOL. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
On Tue, 18 Jul 2006 08:33:37 -0500, McKown, John [EMAIL PROTECTED] wrote: [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Subject: Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) What's the point if you don't have that much memory and can't back it on DASD? It's just an exercise with no practical value until you can back it. Why, bragging rights, of course! Planning for the future. Perhaps some weird need for a sparse file? -- John McKown Ummm. Bragging right for sure. But ask the architects of the OS/400 (iSeries?) Their Single-store design is architecturally set to 2**128 addressability, but they started out their implementation at 2**48, now at 2**64, (next 2**96? or 2**128). Maybe if you have a plan, you can actually use your designed upper limits? gr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[Fwd: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)]
Be careful with like terms between the PC(intel) world and the mainframe world. When someone says they have a 64-bit Intel server (Intel, Solaris, AMD, etc.), it does not mean that the server can access an address 64-bits long, the 64-bits refers to the width of the bus. So it can transfer 64-bits in parallel. Leif John KcKown wrote: And, just for fun, Sun has implemented a 128-bit filesystem in Solaris! That means that a single filesystem can contain 2**128 bytes of data. Good heavens! I think that most UNIX filesystems are either 32 or 64 bit at present. But don't quote me on that. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited.=20 =20 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
I always get blank looks when I ask what would happen if someone actually tried to exploit 64bit addressing to the fullest. How do we provide page space to back these requests? As someone responsible for keeping our mainframes up and running, it worries me that application type people have the ability to crash the system just by a stupid mistake. One STORAGE loop in a 64bit address space and the paging subsystem is toast. I know that there are other exposures that application folks can use to crash the system, but, to me, this looks like an accident waiting to happen. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Tuesday, July 18, 2006 1:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) AFAIK, the total capacity of all DASD ever manufactured is still insufficient to fully back even ONE 64-bit address space At the rate 80 - 200 gigabyte drives and higher have been produced and sold, is the statement being made for only mainframe DASD? I realize that no z box could handle that much DASD space and wonder if either i or p boxes could in theory. Nothing could. Let's make a few simplifying assumptions to make the math easy. First let's use 256GiB as the drive size. Yeah, that is way bigger than any MF drive ever shipped, or ever thought of, but it's about the size of the drive in my PC and you can buy bigger drives now for a few hundred bucks. snicker Anyway, one of those puppies is (2**8)*(2**30) = 2**38 bytes And a single 64-bit address space is, well 2**64 bytes. So assuming you could use the whole drive, the number of these current generation drives that you would need to back a single address space is (2**64)/(2**38) = 2**(64-38) = 2**26 = 67,108,864 Ok, so on that basis I was a little pessimistic about the time we would need to build enough disk to back one address space. It is becoming plausible that some time in the relatively near future there will be enough disk storage capacity on Earth to map a single 64-bit address space. Of course, housing, powering, wiring, configuring, initializing and addressing that much disk storage would be somewhat of a problem and doing it all over again to map that second address space will be a real b1tch! In other words, 2**64 is a phenomenally large number. In terms of actual usable storage, it is wildly beyond the limits of our current technology and certainly beyond my feeble imagination about what one might actually fill it up with. An RFID for every star and galaxy perhaps? Endless re-runs of I Love Lucy in HD? Hell if I know. And for a real giggle-fest, take a look through your own JCL libraries and see how many jobs are still running with REGION=something_really_small. I am glad that the wizards have made it all work out, but in terms of functional needs, 64-bit addressing is overkill on a cosmic scale. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
That is the reason that IBM allows installations to set the MEMLIMIT. While it is true that even a reasonable limit can be abused by multiple jobs, you would have the same exposure in a 31 bit world if you allow jobs to use REGION=0M. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Sent: Tuesday, July 18, 2006 6:26 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) I always get blank looks when I ask what would happen if someone actually tried to exploit 64bit addressing to the fullest. How do we provide page space to back these requests? As someone responsible for keeping our mainframes up and running, it worries me that application type people have the ability to crash the system just by a stupid mistake. One STORAGE loop in a 64bit address space and the paging subsystem is toast. I know that there are other exposures that application folks can use to crash the system, but, to me, this looks like an accident waiting to happen. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Tuesday, July 18, 2006 1:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) AFAIK, the total capacity of all DASD ever manufactured is still insufficient to fully back even ONE 64-bit address space At the rate 80 - 200 gigabyte drives and higher have been produced and sold, is the statement being made for only mainframe DASD? I realize that no z box could handle that much DASD space and wonder if either i or p boxes could in theory. Nothing could. Let's make a few simplifying assumptions to make the math easy. First let's use 256GiB as the drive size. Yeah, that is way bigger than any MF drive ever shipped, or ever thought of, but it's about the size of the drive in my PC and you can buy bigger drives now for a few hundred bucks. snicker Anyway, one of those puppies is (2**8)*(2**30) = 2**38 bytes And a single 64-bit address space is, well 2**64 bytes. So assuming you could use the whole drive, the number of these current generation drives that you would need to back a single address space is (2**64)/(2**38) = 2**(64-38) = 2**26 = 67,108,864 Ok, so on that basis I was a little pessimistic about the time we would need to build enough disk to back one address space. It is becoming plausible that some time in the relatively near future there will be enough disk storage capacity on Earth to map a single 64-bit address space. Of course, housing, powering, wiring, configuring, initializing and addressing that much disk storage would be somewhat of a problem and doing it all over again to map that second address space will be a real b1tch! In other words, 2**64 is a phenomenally large number. In terms of actual usable storage, it is wildly beyond the limits of our current technology and certainly beyond my feeble imagination about what one might actually fill it up with. An RFID for every star and galaxy perhaps? Endless re-runs of I Love Lucy in HD? Hell if I know. And for a real giggle-fest, take a look through your own JCL libraries and see how many jobs are still running with REGION=something_really_small. I am glad that the wizards have made it all work out, but in terms of functional needs, 64-bit addressing is overkill on a cosmic scale. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Tuesday, July 18, 2006 12:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) snip In other words, 2**64 is a phenomenally large number. In terms of actual usable storage, it is wildly beyond the limits of our current technology and certainly beyond my feeble imagination about what one might actually fill it up with. An RFID for every star and galaxy perhaps? Endless re-runs of I Love Lucy in HD? Hell if I know. snip CC And, just for fun, Sun has implemented a 128-bit filesystem in Solaris! That means that a single filesystem can contain 2**128 bytes of data. Good heavens! I think that most UNIX filesystems are either 32 or 64 bit at present. But don't quote me on that. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
What's the point if you don't have that much memory and can't back it on DASD? It's just an exercise with no practical value until you can back it. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, July 18, 2006 9:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Tuesday, July 18, 2006 12:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) snip In other words, 2**64 is a phenomenally large number. In terms of actual usable storage, it is wildly beyond the limits of our current technology and certainly beyond my feeble imagination about what one might actually fill it up with. An RFID for every star and galaxy perhaps? Endless re-runs of I Love Lucy in HD? Hell if I know. snip CC And, just for fun, Sun has implemented a 128-bit filesystem in Solaris! That means that a single filesystem can contain 2**128 bytes of data. Good heavens! I think that most UNIX filesystems are either 32 or 64 bit at present. But don't quote me on that. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Sent: Tuesday, July 18, 2006 8:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64) What's the point if you don't have that much memory and can't back it on DASD? It's just an exercise with no practical value until you can back it. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Why, bragging rights, of course! Planning for the future. Perhaps some weird need for a sparse file? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
Sparse? Ah, the final frontier Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Everything comes to him who hustles while he waits. ? Thomas A. Edison -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
Chris Craddock writes: | | . . . I am glad that the wizards have made it all work out, but in terms of functional needs, | 64-bit addressing is overkill on a cosmic scale. | Let us hope so. Computing---informatique, informatica, whatever---is a fairly new discipline; but one red thread that runs through its brief history is that nothing is ever big enough for long. External names at most eight characters in length, DDNAME values at most 44 characters in length, varying (halfword current-length prefixed) strings at most 32767 bytes in length, fullword values not larger than 2147483647, etc., etc., have all proved to be too small. Moreover, address spaces first 24 and then 31 mibibytes in size have quickly proved to be too small, not for every application but for some crucial ones. The moral of this anecdotage is that notionally reasonable maxima have in our history always been outgrown much too soon. Another obvious point to make is that this storage is virtual not real storage. All of it need not be backed up, and what is backed up need not even be connected (contiguous); and still another perhaps not quite so obvious one is that when four-byte addresses are inadequate, there are compelling architectural reasons for moving to eight- and not five-, six-. or seven-bye ones. Those of you who have not used the 'new' 64-bit facilities need to learn to do so. Moreover, time spent mastering them will have been used to better advantage than time spent dismissing them as unrealistically sized. John Gilmore Ashland, MA 01721-1817 USA _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
I am not opposed to large address spaces but I need to make sure that my systems stay up. Until someone comes up with a way to back large address spaces then we are in a dangerous situation. It may be 'virtual', but if anyone tries to use it there had better be SOMETHING backing it up! Coding IEFUSI to limit its use is defeating the purpose of having large address spaces in the first place. I remember losing a system when we went to 31 bit addressing because a smart application programmer wrote a program that did a GETMAIN for all available storage and then referenced every page, which killed our paging subsystem. 64 and 128 bit addressing only exacerbate this problem. You may have 64bit addressing, but you only really have the amount of real storage on your system plus the amount of paging space available. Try to use any more and its CRASH. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Tuesday, July 18, 2006 10:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 64-bits is a really big number! Chris Craddock writes: | | . . . I am glad that the wizards have made it all work out, but in | terms of functional needs, | 64-bit addressing is overkill on a cosmic scale. | Let us hope so. Computing---informatique, informatica, whatever---is a fairly new discipline; but one red thread that runs through its brief history is that nothing is ever big enough for long. External names at most eight characters in length, DDNAME values at most 44 characters in length, varying (halfword current-length prefixed) strings at most 32767 bytes in length, fullword values not larger than 2147483647, etc., etc., have all proved to be too small. Moreover, address spaces first 24 and then 31 mibibytes in size have quickly proved to be too small, not for every application but for some crucial ones. The moral of this anecdotage is that notionally reasonable maxima have in our history always been outgrown much too soon. Another obvious point to make is that this storage is virtual not real storage. All of it need not be backed up, and what is backed up need not even be connected (contiguous); and still another perhaps not quite so obvious one is that when four-byte addresses are inadequate, there are compelling architectural reasons for moving to eight- and not five-, six-. or seven-bye ones. Those of you who have not used the 'new' 64-bit facilities need to learn to do so. Moreover, time spent mastering them will have been used to better advantage than time spent dismissing them as unrealistically sized. John Gilmore Ashland, MA 01721-1817 USA _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
On Tue, 18 Jul 2006 11:28:16 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: Coding IEFUSI to limit its use is defeating the purpose of having large address spaces in the first place. I don't agree. It can protect you from shotting yourself in the foot while still allowing legitimate usage that is planned and sized for properly. 64-bit doesn't really change this at all except that no one seems to know what sort of defaults are good at this point for MEMLIMIT. I remember losing a system when we went to 31 bit addressing because a smart application programmer wrote a program that did a GETMAIN for all available storage and then referenced every page, which killed our paging subsystem. 64 and 128 bit addressing only exacerbate this problem. You just illustrated my point. IEFUSI could have protected your system in the above example. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
When we lost our system we had an IEFUSI exit coded and active. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Tuesday, July 18, 2006 12:02 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 64-bits is a really big number! On Tue, 18 Jul 2006 11:28:16 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: Coding IEFUSI to limit its use is defeating the purpose of having large address spaces in the first place. I don't agree. It can protect you from shotting yourself in the foot while still allowing legitimate usage that is planned and sized for properly. 64-bit doesn't really change this at all except that no one seems to know what sort of defaults are good at this point for MEMLIMIT. I remember losing a system when we went to 31 bit addressing because a smart application programmer wrote a program that did a GETMAIN for all available storage and then referenced every page, which killed our paging subsystem. 64 and 128 bit addressing only exacerbate this problem. You just illustrated my point. IEFUSI could have protected your system in the above example. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
Veilleux wrote: When we lost our system we had an IEFUSI exit coded and active. I'm sorry, but I find this whole discussion a bit overblown. The ability to crash a system certainly didn't surface with 64-bit addressing. Since this is hardly a mainstream' storage allocation method, it is no more risky than allowing programmers to code privileged code, or create thousands of dataspaces (or for that matter allowing systems programmers to do so). There is quite obviously no programming need to hold 64-bits worth of code, so the amount of storage available is ultimately based on holding data buffers. There isn't necessarily any need to back large virtual storage allocations with paging data sets. This was amply illustrated by using hiperspaces (ESO), that simply caused data misses and retrieved the data from the data set. There was no need for paging support. As for an IARV64 loop ... it's no more risky than a DSPSERV loop. End of rant Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
On Tue, 18 Jul 2006 12:45:15 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: When we lost our system we had an IEFUSI exit coded and active. Programmer: What do you mean my code doesn't work? I got RC=0 when I assembled it. Either the code was not adequate for the environment or the environment was not adequate (paging subsystem), or both. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
John said; The moral of this anecdotage is that notionally reasonable maxima have in our history always been outgrown much too soon. True enough, but we have oscillated around a curve that is less than one additional bit of addressability every few years and because each bit represents a doubling in size, that curve has flattened dramatically, even though our overall usage continues to grow at a good clip. Another obvious point to make is that this storage is virtual not real storage. All of it need not be backed up, and what is backed up need not even be connected (contiguous); It is possible to construct useful applications that sparsely use very large virtual storage areas as you yourself have done. Those are not a problem. There is not now and never has been a problem with allocating a large block of virtual storage. The problem only arises when you actually try to put data into it. At that point you have data and there are only two places it can be; in real memory, or on disk. In practice, neither of those places can currently store more than O(1*TiB) which is 2**40 bytes or roughly 1 sixteen-millionth of the capacity of a single address space. Call it at least 24 year's worth of room for growth if we could actually grow at a bit per year which we can't - at least not yet anyway. Not even the G-men are growing that fast because it costs real money to back virtual storage. and still another perhaps not quite so obvious one is that when four-byte addresses are inadequate, there are compelling architectural reasons for moving to eight- and not five-, six-. or seven-bye ones. I have no complaint with the clean-ness of the architecture. I happen to agree that 64-bits is the right answer. All I've done is put the numbers into perspective. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)
On Jul 18, 2006, at 6:26 AM, Veilleux, Jon L wrote: I always get blank looks when I ask what would happen if someone actually tried to exploit 64bit addressing to the fullest. How do we provide page space to back these requests? As someone responsible for keeping our mainframes up and running, it worries me that application type people have the ability to crash the system just by a stupid mistake. One STORAGE loop in a 64bit address space and the paging subsystem is toast. I know that there are other exposures that application folks can use to crash the system, but, to me, this looks like an accident waiting to happen. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 Joe, You have reason to worry, IMO. I know COBOL types that really need the 64bit arch. Right now they are storing the tables in VSAM datasets and accessing them them as tables should be. They wanted 64 bits 10+years ago. They have gotten around the limitation of COBOL and wrote assembler subroutines to access the vsam datasets. They have updated the the subrountine for multiple VSAM datasets. Right now they ten extra DD statements for spill vsam files. One programmer used to call me up monthly to see if COBOL has finally kept up with the OS. When I left the business 5+ years ago they were begging for relief. Of course until IBM comes through with support for a large number of page datasets, cobol can sit still doing essentially nothing. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
I'm sorry, but I find this whole discussion a bit overblown. The ability to crash a system certainly didn't surface with 64-bit addressing. I agree! I've already made my opinion known on this, specifically the fact that DB2 V8 ignores the exits and controls for memory. This, in and of itself, is not a bad thing! But, I, as a capacity/performance person should know better! The day you install DB2 V8 is not the day you suddenly use up all your storage. In general, the total memory increase will be about 200MB (results may vary), but all of your HIPERPOOLs will move inside the DB2 address space. That is why you can't afford to limit it! All the other arguments about command and control should be re-examined. SYSPROGs don't always know better. I've seen too many control freak outages caused because a SYSPROG-Defined limit caused something to not be able to initiate. The exits and controls should set reasonable defaults, but if (especially a sub-system) something needs resources, they should be available. Looping getmains, looping tasks, and the like happen. But, in general, resource consumption grows much more slowly than everybody is p*ssing and moaning about on this thread. When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bits is a really big number!
On Tue, 18 Jul 2006 11:28:16 -0400, Veilleux, Jon L [EMAIL PROTECTED] wrote: snip! You may have 64bit addressing, but you only really have the amount of real storage on your system plus the amount of paging space available. Try to use any more and its CRASH. You can monitor storage usage like mSYS/Operations does and deal with address spaces that use too much. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
