Do they really exist?  Yes (sort of).  In about 1990 we converted a big
application program from 24-bit to 31-bit.  Basically we just divided our
load modules into two halves.  One part ran below the 16M line to do all
the 24-bit I/O code and the rest was 31-bit AMODE(31), RMODE(ANY).
That code is still running fine today on z/OS 2.3.   I'm sure we'd have
more options today, but that worked in 1990.


On Mon, Nov 27, 2017 at 6:05 PM, Charles Mills <[email protected]> wrote:

> It would be awesome if 24-bit would just go away. But are you volunteering
> to convert all those 24-bit programs? (Do they really exist? Heck, there's
> a
> current thread on IBM-MAIN about compatibility with OS/390 1.5.")
>
> IBM has made the philosophical decision that slavish upward compatibility
> is
> non-negotiable, except when that principle conflicts with the principle of
> integrity. I think IBM over-learned the lesson of the "Future System"
> (https://en.wikipedia.org/wiki/IBM_Future_Systems_project#Project_end,
> last
> paragraph of section) but that is just IMHO.
>
> Charles
>
>
> -----Original Message-----
> From: IBM Mainframe Assembler List [mailto:[email protected]
> ]
> On Behalf Of Paul Gilmartin
> Sent: Monday, November 27, 2017 4:19 PM
> To: [email protected]
> Subject: Re: BDAM files
>
> On 2017-11-27, at 14:09:56, Charles Mills wrote:
>
> > You've got to do a little bit more hoop-jumping for AMODE(31) -- separate
> storage for the DCBs, and remembering the extra parameters on the various
> macros. Not prohibitive, but a little more to remember, and a few more
> possibilities for gotchas.
> >
> Wouldn't it be great if a single SET symbol setting could condition all the
> system macros to generate 24/31/64 bit expansions?
>
> Better if 24-bit just went away and never came back.  And the horse it rode
> in on.
>
> > I have not mentioned this in a while, but I wrote a paper on converting
> an
> xMODE(24) xSAM program to xMODE(31). If anyone wants a copy, just write me
> off-line. Not a sales pitch for anything; no salesman will call.
>
> -- gil
>

Reply via email to