On Mon, 18 Aug 2025 19:06:54 -0500, Jon Perryman <[email protected]> wrote:
>On Mon, 18 Aug 2025 18:35:30 -0500, Paul Edwards <[email protected]> wrote: > >>Personally, I don't think people should be relying on 64-bit >>existing at all. >> >>It is funny that some people even complain about me using >>more than 16 MiB of combined OS, code and data for "my" >>(gcc 3.2.3) program > >GCC is for MVS 3.8J It's effectively NOT for MVS 3.8J. It realistically needs about 20 MiB, so MVS 3.8J is not suitable, so I created a different environment (which I called MVS/380). > which has a 16M (24-bit) optionally with a single 2GB (31 bit) > address space. 16MB is a requirement for this environment. >z/OS with IBM XL C does not have these restrictions. And I didn't want those restrictions either, so I targeted an environment that didn't have a hard limit of 16 MiB. And yet people insisted that I should instead change "my" code instead of seeking an alternative environment, because "my" code was inherently "wrong" for being "so" memory-hungry, where memory-hungry is defined as 16 MiB for combined OS+app code+data. >I suspect that z/OS DB2 is a heavy user of above the bar memory these days. That's probably optional data caching. They probably only have a few MB of actual executable code. Writing and maintaining code requires actual work by a skilled engineer, so there is a limit to how big it can be. BFN. Paul. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
