Wait a minute ...
Two flaws with the below.
1. MVS 3.8j is unsupported. Well, I suppose it is unsupported in the same sense
the Linux is unsupported -- the publisher, the owner of the IP rights, does not
support it. Third parties support it. I suppose if enough companies ran MVS
3.8j there is no reason that a vendor could not come along and provide support
for MVS 3.8j, like Red Hat does for Linux. But I still think you run into a
massive "unsupported!!!" objection.
2. It's not just your compiled executable that has to fit into 16MB. It's your
compiled executable, all of the operating system components that it needs
direct addressability on, and all of its in-memory data ("buffers"). For some
applications that in-memory data could be voluminous.
And maybe the IT industry is wrong to expect more than 16 MB but you don't make
sales by arguing with the customer.
Charles
On Fri, 31 Oct 2025 09:39:51 -0500, Paul Edwards <[email protected]> wrote:
>And MVS 3.8J can be run. Sure - you're restricted to 16 MiB -
>but - so what? Perhaps that's part of the problem with the IT
>industry - people expecting more than 16 MiB of memory.
<snip>
>The biggest actual executable with what I consider to be
>"genuine" code is gcc 3.2.3. It is 400,000 lines of C code,
>that translates into 700,000 lines of assembler code, and
>produces a 3 MB executable. Easily fits within 16 MiB.
>
>Is your startup going to produce a 400,000 line application?
>
>After how many decades?
>
>Can you even maintain that? What if you lose the one guy
>who can actually maintain that?
>
>By the time you get anywhere near that, I would expect you
>to have moved to genuine IBM hardware.
>
>My own code - written over 3 decades - and not completely
>alone - comes to something like 70,000 lines of code, and
>fits on a 360k floppy as main executables.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
