Re: AMODE 32

[R.S.]

What about 33-bit and 25-bit addressing modes?
Can we discuss it?

(I couldn't resist)

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Gord Tomlin]

On 2019-04-06 16:19, Joel C. Ewing wrote:

Not worth the effort and risk for a
measly doubling of virtual address space.


In fact, given the availability of 64-bit addressing, the 2 GB 
difference between 31-bit and 32-bit is just a blip. It's like attaching 
a garden shed to the Empire State Building. It's hard to imagine IBM 
seeing a compelling reason to do this instead of concentrating on 
exploiting 64-bit.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Lennie Dymoke-Bradshaw]

Another reason for separating CICS workloads is security. CICS transaction 
separation can only really be achieved through separate address spaces.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Martin Packer
Sent: 07 April 2019 07:51
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] AMODE 32


I dodged the “why multiple CICS regions?” aspect as this thread has already got 
complex enough. The “CICS topology” topic is wonderfully complex, of course, 
and it’s one of the things my workshops with customers delve into.

I would say “QR TCB Constraint” is still a live issue, but less of one.
Certainly lots of things got offloaded to other TCBs, but lots didn’t. I also 
think Threadsafe plays into this quite a bit.

But, to try to bring it back to the OP’s line of thinking a little, I would not 
consider 31-bit or 42-bit virtual storage to be a frequent issue in CICS estate 
design. It’s the sort of thing you check for, of course. Your point - “QR TCB 
Constraint” - is more prevalent.

Cheers, Martin

Sent from my iPad

> On 6 Apr 2019, at 21:19, Joel C. Ewing  wrote:
>
> It used to be, most of a single CICS region other than some 
> DB2-related work was single threaded.  Don't know if that has improved 
> in the last five years, but am sure there must still be significant parts of 
> CICS
> that are single thread.   The only way to give more CPU to a CICS that
> was CPU-constrained, required splitting the load to multiple CICS
Regions.
>
> Over the years, the main reasons we used multiple CICS regions under 
> MVS was for application isolation, downtime isolation, and increased 
> CPU resources -- not merely because of virtual memory constraints.
>
> I know some of our application code relies on the VL bit to detect end 
> of parameter lists.  You cannot depend on existing code being trivial 
> to convert.  Like Y2K, it is not that individual fixes are 
> complicated, but there can be massive amounts of code to review to find where 
> the fixes
> are required.   There would inevitably be bugs introduced in both
> application code and the OS.   Not worth the effort and risk for a
> measly doubling of virtual address space.
> Joel C. Ewing
>
>> On 4/5/19 11:43 PM, Mike Schwab wrote:
>> Actually, they started under MVS with 8MiB user memory or so.  Plus 
>> splitting different applications into their own regions to isolate, 
>> close certain partition at specified times for batch and backup 
>> processing, etc.
>>
>>> On Fri, Apr 5, 2019 at 11:55 AM Paul Edwards 
wrote:
>>> Hi Mike.
>>>
>>> I'm trying to understand why some sites are running multiple CICS 
>>> regions because
>>> 2 GiB is not enough. Yet they haven't gone to AM64. I want to know 
>>> if they would be interested in going to AM32 instead, if it were 
>>> available. Can you elaborate? If AM32 was more practical for them, 
>>> they would be able to halve the number of CICS regions they have.
>>>
>>> BTW, Rob Prins recently updated his
>>> 47,000-line RPF assembler program to make it AM32-clean, and it 
>>> required very little effort. He was using "VL" in a variety of 
>>> places, but the things he was calling were not actually variable 
>>> parameter functions, so he just needed to delete the VL. No rewrite 
>>> was necessary, as would be required if moving to AM64.
>>>
>>> Thanks. Paul.
>>>
>>>
>>>
>>>
 On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab
 wrote:

 If you are wanting to run in AM64 and use 32 bit constants, that is 
 certainly possible.  You will then be limited to incrementing 
 registers by 4GiB or less.  Just establishing addressability will 
 need to set all 64 bits.

> On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards 
wrote:
>> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer
 wrote:
>>
>> They will be (running 64-bit). However, apart from Db2*, much of
their
>> virtual storage components can't tolerate being above the bar.
> Which virtual storage components can't tolerate being above the 
> bar, and why is that and what would need to change?
>
> Thanks. Paul.
>
> ...
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> ...
>
>
> --
> Joel C. Ewing
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,  send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 

Re: AMODE 32

[Martin Packer]

I dodged the “why multiple CICS regions?” aspect as this thread has already
got complex enough. The “CICS topology” topic is wonderfully complex, of
course, and it’s one of the things my workshops with customers delve into.

I would say “QR TCB Constraint” is still a live issue, but less of one.
Certainly lots of things got offloaded to other TCBs, but lots didn’t. I
also think Threadsafe plays into this quite a bit.

But, to try to bring it back to the OP’s line of thinking a little, I would
not consider 31-bit or 42-bit virtual storage to be a frequent issue in
CICS estate design. It’s the sort of thing you check for, of course. Your
point - “QR TCB Constraint” - is more prevalent.

Cheers, Martin

Sent from my iPad

> On 6 Apr 2019, at 21:19, Joel C. Ewing  wrote:
>
> It used to be, most of a single CICS region other than some DB2-related
> work was single threaded.  Don't know if that has improved in the last
> five years, but am sure there must still be significant parts of CICS
> that are single thread.   The only way to give more CPU to a CICS that
> was CPU-constrained, required splitting the load to multiple CICS
Regions.
>
> Over the years, the main reasons we used multiple CICS regions under MVS
> was for application isolation, downtime isolation, and increased CPU
> resources -- not merely because of virtual memory constraints.
>
> I know some of our application code relies on the VL bit to detect end
> of parameter lists.  You cannot depend on existing code being trivial to
> convert.  Like Y2K, it is not that individual fixes are complicated, but
> there can be massive amounts of code to review to find where the fixes
> are required.   There would inevitably be bugs introduced in both
> application code and the OS.   Not worth the effort and risk for a
> measly doubling of virtual address space.
> Joel C. Ewing
>
>> On 4/5/19 11:43 PM, Mike Schwab wrote:
>> Actually, they started under MVS with 8MiB user memory or so.  Plus
>> splitting different applications into their own regions to isolate,
>> close certain partition at specified times for batch and backup
>> processing, etc.
>>
>>> On Fri, Apr 5, 2019 at 11:55 AM Paul Edwards 
wrote:
>>> Hi Mike.
>>>
>>> I'm trying to understand why some sites
>>> are running multiple CICS regions because
>>> 2 GiB is not enough. Yet they haven't
>>> gone to AM64. I want to know if they
>>> would be interested in going to AM32
>>> instead, if it were available. Can you
>>> elaborate? If AM32 was more practical
>>> for them, they would be able to halve
>>> the number of CICS regions they have.
>>>
>>> BTW, Rob Prins recently updated his
>>> 47,000-line RPF assembler program to
>>> make it AM32-clean, and it required
>>> very little effort. He was using "VL" in
>>> a variety of places, but the things he
>>> was calling were not actually variable
>>> parameter functions, so he just needed
>>> to delete the VL. No rewrite was
>>> necessary, as would be required if
>>> moving to AM64.
>>>
>>> Thanks. Paul.
>>>
>>>
>>>
>>>
 On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab
 wrote:

 If you are wanting to run in AM64 and use 32 bit constants, that is
 certainly possible.  You will then be limited to incrementing
 registers by 4GiB or less.  Just establishing addressability will need
 to set all 64 bits.

> On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards 
wrote:
>> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer
 wrote:
>>
>> They will be (running 64-bit). However, apart from Db2*, much of
their
>> virtual storage components can't tolerate being above the bar.
> Which virtual storage components can't tolerate
> being above the bar, and why is that and what
> would need to change?
>
> Thanks. Paul.
>
> ...
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> ...
>
>
> --
> Joel C. Ewing
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Joel C. Ewing]

It used to be, most of a single CICS region other than some DB2-related
work was single threaded.  Don't know if that has improved in the last
five years, but am sure there must still be significant parts of CICS
that are single thread.   The only way to give more CPU to a CICS that
was CPU-constrained, required splitting the load to multiple CICS Regions.

Over the years, the main reasons we used multiple CICS regions under MVS
was for application isolation, downtime isolation, and increased CPU
resources -- not merely because of virtual memory constraints.

I know some of our application code relies on the VL bit to detect end
of parameter lists.  You cannot depend on existing code being trivial to
convert.  Like Y2K, it is not that individual fixes are complicated, but
there can be massive amounts of code to review to find where the fixes
are required.   There would inevitably be bugs introduced in both
application code and the OS.   Not worth the effort and risk for a
measly doubling of virtual address space.
    Joel C. Ewing

On 4/5/19 11:43 PM, Mike Schwab wrote:
> Actually, they started under MVS with 8MiB user memory or so.  Plus
> splitting different applications into their own regions to isolate,
> close certain partition at specified times for batch and backup
> processing, etc.
>
> On Fri, Apr 5, 2019 at 11:55 AM Paul Edwards  wrote:
>> Hi Mike.
>>
>> I'm trying to understand why some sites
>> are running multiple CICS regions because
>> 2 GiB is not enough. Yet they haven't
>> gone to AM64. I want to know if they
>> would be interested in going to AM32
>> instead, if it were available. Can you
>> elaborate? If AM32 was more practical
>> for them, they would be able to halve
>> the number of CICS regions they have.
>>
>> BTW, Rob Prins recently updated his
>> 47,000-line RPF assembler program to
>> make it AM32-clean, and it required
>> very little effort. He was using "VL" in
>> a variety of places, but the things he
>> was calling were not actually variable
>> parameter functions, so he just needed
>> to delete the VL. No rewrite was
>> necessary, as would be required if
>> moving to AM64.
>>
>> Thanks. Paul.
>>
>>
>>
>>
>> On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab  
>> wrote:
>>
>>> If you are wanting to run in AM64 and use 32 bit constants, that is
>>> certainly possible.  You will then be limited to incrementing
>>> registers by 4GiB or less.  Just establishing addressability will need
>>> to set all 64 bits.
>>>
>>> On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards  wrote:
 On Thu, 4 Apr 2019 19:32:01 +, Martin Packer 
  wrote:

> They will be (running 64-bit). However, apart from Db2*, much of their
> virtual storage components can't tolerate being above the bar.
 Which virtual storage components can't tolerate
 being above the bar, and why is that and what
 would need to change?

 Thanks. Paul.

 ...

 --
 Mike A Schwab, Springfield IL USA
 Where do Forest Rangers go to get away from it all?

 ...


-- 
Joel C. Ewing

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Mike Schwab]

Actually, they started under MVS with 8MiB user memory or so.  Plus
splitting different applications into their own regions to isolate,
close certain partition at specified times for batch and backup
processing, etc.

On Fri, Apr 5, 2019 at 11:55 AM Paul Edwards  wrote:
>
> Hi Mike.
>
> I'm trying to understand why some sites
> are running multiple CICS regions because
> 2 GiB is not enough. Yet they haven't
> gone to AM64. I want to know if they
> would be interested in going to AM32
> instead, if it were available. Can you
> elaborate? If AM32 was more practical
> for them, they would be able to halve
> the number of CICS regions they have.
>
> BTW, Rob Prins recently updated his
> 47,000-line RPF assembler program to
> make it AM32-clean, and it required
> very little effort. He was using "VL" in
> a variety of places, but the things he
> was calling were not actually variable
> parameter functions, so he just needed
> to delete the VL. No rewrite was
> necessary, as would be required if
> moving to AM64.
>
> Thanks. Paul.
>
>
>
>
> On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab  
> wrote:
>
> >If you are wanting to run in AM64 and use 32 bit constants, that is
> >certainly possible.  You will then be limited to incrementing
> >registers by 4GiB or less.  Just establishing addressability will need
> >to set all 64 bits.
> >
> >On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards  wrote:
> >>
> >> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer 
> >>  wrote:
> >>
> >> >They will be (running 64-bit). However, apart from Db2*, much of their
> >> >virtual storage components can't tolerate being above the bar.
> >>
> >> Which virtual storage components can't tolerate
> >> being above the bar, and why is that and what
> >> would need to change?
> >>
> >> Thanks. Paul.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >--
> >Mike A Schwab, Springfield IL USA
> >Where do Forest Rangers go to get away from it all?
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Joe Monk]

At minimum, a recompile/reassemble. Takes machine time and programmer time.

Amode 32 doesn't exist so I'm not worried about that.

Joe

On Fri, Apr 5, 2019, 4:03 PM Paul Edwards  wrote:

> On Fri, 5 Apr 2019 15:55:42 -0400, Joe Monk  wrote:
>
> >> I'm trying to understand why some sites
> >> are running multiple CICS regions because
> >> 2 GiB is not enough. Yet they haven't
> >> gone to AM64..."
> >
> > Who is going to pay for programmer time to convert applications to
> 64-bit?
> > The cost of running mulitple 2GB regions is less than the cost to convert
> > the applications, debug and test them.
>
> Ok, thanks for that. So what programming
> effort would be required to convert them
> to AM32? What language are these programs
> likely to be written in?
>
> Thanks. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Gibney, Dave]

Unknowable and various ((Cobol, HLASM, pl/1, RPG  )

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Paul Edwards
> Sent: Friday, April 05, 2019 1:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AMODE 32
> 
> On Fri, 5 Apr 2019 15:55:42 -0400, Joe Monk 
> wrote:
> 
> >> I'm trying to understand why some sites are running multiple CICS
> >> regions because
> >> 2 GiB is not enough. Yet they haven't gone to AM64..."
> >
> > Who is going to pay for programmer time to convert applications to 64-bit?
> > The cost of running mulitple 2GB regions is less than the cost to
> > convert the applications, debug and test them.
> 
> Ok, thanks for that. So what programming effort would be required to
> convert them to AM32? What language are these programs likely to be
> written in?
> 
> Thanks. Paul.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Fri, 5 Apr 2019 15:55:42 -0400, Joe Monk  wrote:

>> I'm trying to understand why some sites
>> are running multiple CICS regions because
>> 2 GiB is not enough. Yet they haven't
>> gone to AM64..."
>
> Who is going to pay for programmer time to convert applications to 64-bit?
> The cost of running mulitple 2GB regions is less than the cost to convert
> the applications, debug and test them.

Ok, thanks for that. So what programming
effort would be required to convert them
to AM32? What language are these programs
likely to be written in?

Thanks. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Joe Monk]

"I'm trying to understand why some sites
are running multiple CICS regions because
2 GiB is not enough. Yet they haven't
gone to AM64..."

Who is going to pay for programmer time to convert applications to 64-bit?
The cost of running mulitple 2GB regions is less than the cost to convert
the applications, debug and test them.

Joe

On Fri, Apr 5, 2019 at 12:55 PM Paul Edwards  wrote:

> Hi Mike.
>
> I'm trying to understand why some sites
> are running multiple CICS regions because
> 2 GiB is not enough. Yet they haven't
> gone to AM64. I want to know if they
> would be interested in going to AM32
> instead, if it were available. Can you
> elaborate? If AM32 was more practical
> for them, they would be able to halve
> the number of CICS regions they have.
>
> BTW, Rob Prins recently updated his
> 47,000-line RPF assembler program to
> make it AM32-clean, and it required
> very little effort. He was using "VL" in
> a variety of places, but the things he
> was calling were not actually variable
> parameter functions, so he just needed
> to delete the VL. No rewrite was
> necessary, as would be required if
> moving to AM64.
>
> Thanks. Paul.
>
>
>
>
> On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab 
> wrote:
>
> >If you are wanting to run in AM64 and use 32 bit constants, that is
> >certainly possible.  You will then be limited to incrementing
> >registers by 4GiB or less.  Just establishing addressability will need
> >to set all 64 bits.
> >
> >On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards  wrote:
> >>
> >> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer <
> martin_pac...@uk.ibm.com> wrote:
> >>
> >> >They will be (running 64-bit). However, apart from Db2*, much of their
> >> >virtual storage components can't tolerate being above the bar.
> >>
> >> Which virtual storage components can't tolerate
> >> being above the bar, and why is that and what
> >> would need to change?
> >>
> >> Thanks. Paul.
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
> >
> >--
> >Mike A Schwab, Springfield IL USA
> >Where do Forest Rangers go to get away from it all?
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Mohammad Khan]

No, no, no, he is NOT trying to solve or prove anything. He is merely trying to 
save the world just like his namesake from around 2000 years ago. History is 
repeating itself again in that he is not having much success with his 
contemporaries. Neither the ordinary folks (IBM-MAINers) nor the Roman Empire 
(IBM) is giving him his due. But remember what happened to that other Paul 250 
years after his death.

MKK

PS: Sorry, it's Friday and I could not resist.


On Fri, 5 Apr 2019 06:52:53 -0500, Elardus Engelbrecht 
 wrote:

>Paul Edwards wrote:
>
>>I was thinking that z/Arch and z/OS could be updated to support AMODE 32.
>
>I am not sure what you want to solve or prove, but I think you should startup 
>a new company and then invent/patent a brand new mainframe which can address 
>all your needs. If you have a good business case, you may become a formal IBM 
>Partner.
>
>I am very sure based by all those replies in this and last year threads, 
>you're not going to achieve what you want from IBM and members of IBM-MAIN.
>
>Also, you asked twice in this thread "I don't understand this technical 
>question." while you are comtemplating very technical things.
>
>Did IBM accepted your RFE you want to submit last year? I would be surprised 
>if IBM accepted that, because Jim Mulder said No.
>
>Groete / Greetings
>Elardus Engelbrecht
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

Hi Mike.

I'm trying to understand why some sites
are running multiple CICS regions because
2 GiB is not enough. Yet they haven't
gone to AM64. I want to know if they
would be interested in going to AM32
instead, if it were available. Can you
elaborate? If AM32 was more practical
for them, they would be able to halve
the number of CICS regions they have.

BTW, Rob Prins recently updated his
47,000-line RPF assembler program to
make it AM32-clean, and it required
very little effort. He was using "VL" in
a variety of places, but the things he
was calling were not actually variable
parameter functions, so he just needed
to delete the VL. No rewrite was
necessary, as would be required if
moving to AM64.

Thanks. Paul.




On Fri, 5 Apr 2019 02:41:15 -0500, Mike Schwab  wrote:

>If you are wanting to run in AM64 and use 32 bit constants, that is
>certainly possible.  You will then be limited to incrementing
>registers by 4GiB or less.  Just establishing addressability will need
>to set all 64 bits.
>
>On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards  wrote:
>>
>> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer  
>> wrote:
>>
>> >They will be (running 64-bit). However, apart from Db2*, much of their
>> >virtual storage components can't tolerate being above the bar.
>>
>> Which virtual storage components can't tolerate
>> being above the bar, and why is that and what
>> would need to change?
>>
>> Thanks. Paul.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>Mike A Schwab, Springfield IL USA
>Where do Forest Rangers go to get away from it all?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Elardus Engelbrecht]

Paul Edwards wrote:

>I was thinking that z/Arch and z/OS could be updated to support AMODE 32.

I am not sure what you want to solve or prove, but I think you should startup a 
new company and then invent/patent a brand new mainframe which can address all 
your needs. If you have a good business case, you may become a formal IBM 
Partner.

I am very sure based by all those replies in this and last year threads, you're 
not going to achieve what you want from IBM and members of IBM-MAIN.

Also, you asked twice in this thread "I don't understand this technical 
question." while you are comtemplating very technical things.

Did IBM accepted your RFE you want to submit last year? I would be surprised if 
IBM accepted that, because Jim Mulder said No.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Mike Schwab]

If you are wanting to run in AM64 and use 32 bit constants, that is
certainly possible.  You will then be limited to incrementing
registers by 4GiB or less.  Just establishing addressability will need
to set all 64 bits.

On Thu, Apr 4, 2019 at 2:40 PM Paul Edwards  wrote:
>
> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer  
> wrote:
>
> >They will be (running 64-bit). However, apart from Db2*, much of their
> >virtual storage components can't tolerate being above the bar.
>
> Which virtual storage components can't tolerate
> being above the bar, and why is that and what
> would need to change?
>
> Thanks. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Martin Packer]

I’m not quite sure why you’re asking me this. However, there are ones that
would break compatibility and ones where there is no pressing need to
change. Sometimes the same thing. :-)

One has to view virtual storage as an evolution/journey - and some
destinations aren’t worth the candle. The “journey” bit is why I mentioned
the various versions of Db2.

Likewise, z/OS Development has captured its virtual (and real) storage
hills as needed. Not all at once.

Sent from my iPad

> On 4 Apr 2019, at 20:41, Paul Edwards  wrote:
>
>> On Thu, 4 Apr 2019 19:32:01 +, Martin Packer
 wrote:
>>
>> They will be (running 64-bit). However, apart from Db2*, much of their
>> virtual storage components can't tolerate being above the bar.
>
> Which virtual storage components can't tolerate
> being above the bar, and why is that and what
> would need to change?
>
> Thanks. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Charles Mills]

I certainly don't understand all of IBM's Z strategy, but I can tell you pretty 
good certainty that IBM has zero interest in investing 1¢ in z/OS enhancements 
to facilitate the use of pre-Z hardware.

Heck, V2R3 doesn't even support a z196!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Edwards
Sent: Thursday, April 4, 2019 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AMODE 32

On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen  
wrote:

>Sounds like a pretty narrow range of applications, where the existing above
>the line is not enough, but an extra 2G will be enough forever.

It's sometimes not a matter of "not enough"
so much as "capability". E.g. a 32-bit editor
is capable of editing either 2 GiB or 4 GiB
files, depending on whether it is compiled
AM31 or AM32. If you exceed the capability
you are forced to use your less-preferred
editor. I would like to give users the
maximum capability that 32 bits can give.

>Why do you feel 64bit is "overkill"?

Because it invalidates all old hardware. An
AM32 program can still run as AM31 on old
hardware, or even AM24 on very old
hardware.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 19:32:01 +, Martin Packer  
wrote:

>They will be (running 64-bit). However, apart from Db2*, much of their
>virtual storage components can't tolerate being above the bar.

Which virtual storage components can't tolerate
being above the bar, and why is that and what
would need to change?

Thanks. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Martin Packer]

They will be (running 64-bit). However, apart from Db2*, much of their 
virtual storage components can't tolerate being above the bar. Consider 
Db2's 64-bit evolution in V8 then V9 then V10.

* Even Db2 has some below-the-bar usage.

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Paul Edwards 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   04/04/2019 19:37
Subject:    Re: AMODE 32
Sent by:IBM Mainframe Discussion List 



On Thu, 4 Apr 2019 12:59:03 -0500, Mike Schwab  
wrote:

>A lot of installations run multiple CICS / IMS / DB2 regions because
>one or two 2GiB regions is not nearly enough.

Why are they not running as 64-bit?

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 12:59:03 -0500, Mike Schwab  wrote:

>A lot of installations run multiple CICS / IMS / DB2 regions because
>one or two 2GiB regions is not nearly enough.

Why are they not running as 64-bit?

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 18:14:48 +, Seymour J Metz  wrote:

>Existing programs will be using VL,

Not always. It is relatively rare to take
a variable number of parameters.

> so you're talking a total rewrite to exploit AMODE32.

No, fairly minor changes, not a rewrite.

> How is that short-term fix advantageous?

It allows the full 32-bit capability to be exploited.

> It's just as easy to go directly to 64 bit.

No, THAT is what requires a complete rewrite.
AND, that rules out running on older hardware,
or even newer hardware if someone comes
out with a cheap 32-bit S/390 chip.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Seymour J Metz]

Existing programs will be using VL, so you're talking a total rewrite to 
exploit AMODE32. How is that short-term fix advantageous? It's just as easy to 
go directly to 64 bit.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, April 4, 2019 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AMODE 32

On Thu, 4 Apr 2019 17:45:27 +, Seymour J Metz  wrote:

>> I don't agree. Existing applications can be
>> modified to be 32-bit clean
>
>Only if the never use storage above the line for parameters.

Or they don't use VL, the same requirement
that AM64 has.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Mike Schwab]

A lot of installations run multiple CICS / IMS / DB2 regions because
one or two 2GiB regions is not nearly enough.  JAVA does offer an
option to run from 2GiB to 8GiB using 4 bit pointers that are shifted
3 bits to a multiple of 8 bytes.  Almost no one uses this because the
shifting slow down every memory access, much cheaper to use more
memory for 64 bit pointers.

On Thu, Apr 4, 2019 at 10:31 AM Paul Edwards  wrote:
>
> On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen 
>  wrote:
>
> >Sounds like a pretty narrow range of applications, where the existing above
> >the line is not enough, but an extra 2G will be enough forever.
>
> It's sometimes not a matter of "not enough"
> so much as "capability". E.g. a 32-bit editor
> is capable of editing either 2 GiB or 4 GiB
> files, depending on whether it is compiled
> AM31 or AM32. If you exceed the capability
> you are forced to use your less-preferred
> editor. I would like to give users the
> maximum capability that 32 bits can give.
>
> >Why do you feel 64bit is "overkill"?
>
> Because it invalidates all old hardware. An
> AM32 program can still run as AM31 on old
> hardware, or even AM24 on very old
> hardware.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 17:45:27 +, Seymour J Metz  wrote:

>> I don't agree. Existing applications can be
>> modified to be 32-bit clean
>
>Only if the never use storage above the line for parameters.

Or they don't use VL, the same requirement
that AM64 has.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Tom Marchant]

On Thu, 4 Apr 2019 10:31:16 -0500, Paul Edwards wrote:

>Because it invalidates all old hardware. An
>AM32 program can still run as AM31 on old
>hardware, or even AM24 on very old
>hardware.

Oh, so you want to enhance the architecture on "very old hardware". 
And make a corresponding enhancement to z/OS in such a way that it 
will run on hardware that does not support z/Architecture.

That's absurd.

I'm done with you.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Seymour J Metz]

> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.

32 bit mode would have been a good idea in the initial S/360 design, and IMHO 
its lack was a serious blunder. Shoehorning it into the existing software at 
this point in time would be a kludge and a short term one at that. The long 
term model is 64 bits unless memory and DASD prices go down drastically.

> I don't agree. Existing applications can be
> modified to be 32-bit clean

Only if the never use storage above the line for parameters.

> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.

31 bit/2 GiB should be enough for almost all commercial applications. Those 
that need more will need lots more, and it is a pipe dream to believe that 
doubling the size of the address space will be enough for long.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, April 4, 2019 7:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AMODE 32

On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen  
wrote:

>What problem would this solve?

It would set the long-term model for the
mainframe, instead of being stuck with
24/31-bit software for eternity.

>This would be of zero use for existing applications,

I don't agree. Existing applications can be
modified to be 32-bit clean and have maximum
possible address space as per 32-bit.

> and new applications should simply use 64 bit.

I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Allan Staller]

I suggest we all stop feeding the Bear!


::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Vernooij, Kees (ITOP NM) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Binyamin Dissen
> Sent: 04 April, 2019 13:43
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AMODE 32
> 
> On Thu, 4 Apr 2019 06:19:50 -0500 Paul Edwards 
> wrote:
> 
> :>On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen
>  wrote:
> 
> :>>What problem would this solve?
> 
> :>It would set the long-term model for the
> :>mainframe, instead of being stuck with
> :>24/31-bit software for eternity.
> 
> 24/31 is required for downward compatibility.
> 

I would even like to formulate it stronger: it is not a disadvantage to be 
stuck with 24/31-bit software, it is an advantage to be compatible with 
24/31-bit software (for eternity). 
You might bring IBM on the idea to phase out all techniques that are more than 
a decade old.

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.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Seymour J Metz]

The question is not what people would like to see, but whether there is a 
reasonable way to get there. I would have like S/360 to have used 32 bit 
addresses with a must be zero (MBZ) reqirement on the high bits and a software 
convention for the end of the parameter list that did not involve turning on a 
high bit. Well, IBM didn't do it that way, and there is far to much invested in 
code to change it now. That bridge was burned half a century ago.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Paul Edwards 
Sent: Thursday, April 4, 2019 8:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AMODE 32

On Thu, 4 Apr 2019 07:46:59 -0400, Don Poitras  wrote:

> When you brought this up a year ago, I don't think you convinced anyone
> that this was a useful change or that IBM should reasonably spend
> dollars doing it. I doubt much has changed since then to improve your
> chances.

Last time I was trying to add a LOC=32
to GETMAIN for use by AMODE 64 programs.

This time I want to retain normal LOC=ANY
for GETMAIN, and introduce a new AMODE 32.

Previously I didn't have a practical way of
adding AM32. It is only recently that I
realized that bits 1-7 of a 32-bit register
could be used by BSM.

I thought more people would like to see a
long-term z/OS that ran purely 32-bit and
64-bit software like other platforms do.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Binyamin Dissen]

On Thu, 4 Apr 2019 10:31:16 -0500 Paul Edwards  wrote:

:>On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen 
 wrote:

:>>Sounds like a pretty narrow range of applications, where the existing above
:>>the line is not enough, but an extra 2G will be enough forever.

:>It's sometimes not a matter of "not enough"
:>so much as "capability". E.g. a 32-bit editor
:>is capable of editing either 2 GiB or 4 GiB
:>files, depending on whether it is compiled
:>AM31 or AM32. If you exceed the capability
:>you are forced to use your less-preferred
:>editor. I would like to give users the
:>maximum capability that 32 bits can give.

What hardware is this hypothetical end-user using, that does not support 64
bit?

:>>Why do you feel 64bit is "overkill"?

:>Because it invalidates all old hardware. An
:>AM32 program can still run as AM31 on old
:>hardware, or even AM24 on very old
:>hardware.

Well, you make it optional. Path1=24 bit. Path2=31bit. Path3=64bit.

I fail to see how your proposal would help IBM sell anything.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Joe Monk]

" As far as I am aware, if you do a:

CALL xxx,VL

to set the high bit to signify end of parameter
list, then if the target is operating in AM64, it
will fail with a S0C4."

Nope. You will get this error:

12,*** IHB280 VL INVALID WITH 8_BYTE_ENTRY_PLIST

Joe

On Thu, Apr 4, 2019 at 11:18 AM Paul Edwards  wrote:

> I'm sorry I don't understand your technical point.
> Could you rephrase?
>
> As far as I am aware, if you do a:
>
> CALL xxx,VL
>
> to set the high bit to signify end of parameter
> list, then if the target is operating in AM64, it
> will fail with a S0C4.
>
> BFN. Paul.
>
>
>
> On Thu, 4 Apr 2019 15:12:24 +, Gene Hudders  wrote:
>
> >Again I am sorry but at this point I believe you cannot issue a CALL for
> a program in 64 bits. I do nothing when switching back and forth with my
> CALLs.
> >
> >In a message dated 4/4/2019 11:09:16 AM Venezuela Standard Time,
> mutazi...@gmail.com writes:
> >
> >On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders 
> wrote:
> >> I'm sorry, but I don't have to make any changes> to my 31 bit programs
> using CALLs and using> 64-bit addressing. We have lots of programs> doing
> both AM31 and AM64 with the only change> is the instructions to change the
> addressing mode.
> >If you are changing addressing mode to31-bit, so that you can cope with
> thex'80' bit in a CALL, then you would needto do the same thing with an
> AM32program.
> >> Do you realize how many user programs that> have CALLs embedded in the
> code that would> require eliminating the HO X'80' bit?
> >A problem that exists when trying toconvert to pure AM64 too.
> >BFN. Paul.
> >--For
> IBM-MAIN subscribe / signoff / archive access instructions,send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >--
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 14:42:47 +0300, Binyamin Dissen  
wrote:

>Sounds like a pretty narrow range of applications, where the existing above
>the line is not enough, but an extra 2G will be enough forever.

It's sometimes not a matter of "not enough"
so much as "capability". E.g. a 32-bit editor
is capable of editing either 2 GiB or 4 GiB
files, depending on whether it is compiled
AM31 or AM32. If you exceed the capability
you are forced to use your less-preferred
editor. I would like to give users the
maximum capability that 32 bits can give.

>Why do you feel 64bit is "overkill"?

Because it invalidates all old hardware. An
AM32 program can still run as AM31 on old
hardware, or even AM24 on very old
hardware.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

I'm sorry I don't understand your technical point.
Could you rephrase?

As far as I am aware, if you do a:

CALL xxx,VL

to set the high bit to signify end of parameter
list, then if the target is operating in AM64, it
will fail with a S0C4.

BFN. Paul.



On Thu, 4 Apr 2019 15:12:24 +, Gene Hudders  wrote:

>Again I am sorry but at this point I believe you cannot issue a CALL for a 
>program in 64 bits. I do nothing when switching back and forth with my CALLs.
>
>In a message dated 4/4/2019 11:09:16 AM Venezuela Standard Time, 
>mutazi...@gmail.com writes:
>
>On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders  wrote:
>> I'm sorry, but I don't have to make any changes> to my 31 bit programs using 
>> CALLs and using> 64-bit addressing. We have lots of programs> doing both 
>> AM31 and AM64 with the only change> is the instructions to change the 
>> addressing mode.
>If you are changing addressing mode to31-bit, so that you can cope with 
>thex'80' bit in a CALL, then you would needto do the same thing with an 
>AM32program.
>> Do you realize how many user programs that> have CALLs embedded in the code 
>> that would> require eliminating the HO X'80' bit?
>A problem that exists when trying toconvert to pure AM64 too.
>BFN. Paul.
>--For 
>IBM-MAIN subscribe / signoff / archive access instructions,send email to 
>lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Gene Hudders]

Again I am sorry but at this point I believe you cannot issue a CALL for a 
program in 64 bits. I do nothing when switching back and forth with my CALLs.

In a message dated 4/4/2019 11:09:16 AM Venezuela Standard Time, 
mutazi...@gmail.com writes:

On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders  wrote:
> I'm sorry, but I don't have to make any changes> to my 31 bit programs using 
> CALLs and using> 64-bit addressing. We have lots of programs> doing both AM31 
> and AM64 with the only change> is the instructions to change the addressing 
> mode.
If you are changing addressing mode to31-bit, so that you can cope with 
thex'80' bit in a CALL, then you would needto do the same thing with an 
AM32program.
> Do you realize how many user programs that> have CALLs embedded in the code 
> that would> require eliminating the HO X'80' bit?
A problem that exists when trying toconvert to pure AM64 too.
BFN. Paul.
--For 
IBM-MAIN subscribe / signoff / archive access instructions,send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 15:03:43 +, Gene Hudders  wrote:

> I'm sorry, but I don't have to make any changes
> to my 31 bit programs using CALLs and using
> 64-bit addressing. We have lots of programs
> doing both AM31 and AM64 with the only change
> is the instructions to change the addressing mode.

If you are changing addressing mode to
31-bit, so that you can cope with the
x'80' bit in a CALL, then you would need
to do the same thing with an AM32
program.

> Do you realize how many user programs that
> have CALLs embedded in the code that would
> require eliminating the HO X'80' bit?

A problem that exists when trying to
convert to pure AM64 too.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Gene Hudders]

I'm sorry, but I don't have to make any changes to my 31 bit programs using 
CALLs and using 64-bit addressing. We have lots of programs doing both AM31 and 
AM64 with the only change is the instructions to change the addressing mode. Do 
you realize how many user programs that have CALLs embedded in the code that 
would require eliminating the HO X'80' bit? Maybe that is why IBM from the 
beginning only defined 31 bits instead of 32.
Gene
In a message dated 4/4/2019 10:37:13 AM Venezuela Standard Time, 
mutazi...@gmail.com writes:

On Thu, 4 Apr 2019 14:22:16 +, Gene Hudders  wrote:
> How is the system going to interpret the X'80'> used to indicate the end of a 
> CALL parameter list.
This is one of the 32-bit changes, the sameas needs to be done if using AM64.
There is a set of changes that need to bedone when going from AM24 to AM31.
There is a set of changes that need to bedone when going from AM31 to AM32.
There is a set of changes that need to bedone when going from AM32 to AM64.
BFN. Paul.
--For 
IBM-MAIN subscribe / signoff / archive access instructions,send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 09:33:46 -0500, Tom Marchant  
wrote:

>>The BSM instruction can use bit x'4000 '
>>to get/set AM32.
>
>No, it can't, for compatibility reasons.

What are you referring to? I don't see
any compatibility problem.

>>This introduces a 1 GiB
>>restriction where the module should not
>>be loaded above if it needs to switch
>>AMODEs to call READ etc.
>
>Yeah. You want to double the available storage,
>yet halve the storage available to programs.

The storage available to programs is
doubled, not halved.

It is just the load module that needs
to reside below 1 GiB, and even then,
that's only if READ hasn't been updated
to be AM32-clean.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 14:22:16 +, Gene Hudders  wrote:

> How is the system going to interpret the X'80'
> used to indicate the end of a CALL parameter list.

This is one of the 32-bit changes, the same
as needs to be done if using AM64.

There is a set of changes that need to be
done when going from AM24 to AM31.

There is a set of changes that need to be
done when going from AM31 to AM32.

There is a set of changes that need to be
done when going from AM32 to AM64.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Tom Marchant]

On Wed, 3 Apr 2019 18:17:46 -0500, Paul Edwards wrote:

>I was thinking that z/Arch and z/OS could
>be updated to support AMODE 32.

Not again.

You brought up something similar last year. It was a ridiculous idea then and 
it still is.

You were told then that your proposal would be rejected, and this one is a far 
bigger one.

It amounts to a very small enhancement to an old architecture that has already 
been enhanced far beyond what you are asking for. You are asking for a 
significant change to the architecture that provides minimal, if any, benefit. 
It would complicate the architecture, apparently only to the benefit of your 
ego.

>The BSM instruction can use bit x'4000 '
>to get/set AM32.

No, it can't, for compatibility reasons.

>This introduces a 1 GiB
>restriction where the module should not
>be loaded above if it needs to switch
>AMODEs to call READ etc.

Yeah. You want to double the available storage, yet halve the storage available 
to programs.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[zMan]

On Thu, Apr 4, 2019 at 10:17 AM Binyamin Dissen 
wrote:

> My guess is the OP is married to 4 byte pointers.


You've met his wife?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Gene Hudders]

How is the system going to interpret the X'80' used to indicate the end of a 
CALL parameter list. Today you just load it into a register and use it because 
it is interpreted as a 31 bit address. If you are using AM32, this address is 
not the one you want. and would require adding code to eliminate the X'80'.

Gene
In a message dated 4/4/2019 10:17:07 AM Venezuela Standard Time, 
bdis...@dissensoftware.com writes:

The issue is not the likeliness of it happening.

I don't really see a business case for this. If a program already needs 12.G
of data, why do special development which will have a hard cap of 3.2G
especially when the availability of much more is commonly available?

My guess is the OP is married to 4 byte pointers.

On Thu, 4 Apr 2019 13:27:06 + Allan Staller  wrote:

:>Prepare a business case and submit it to IBM.
:>I don’t think this list wants to spend a lot of time on something extremely 
unlikely to happen.
:>
:>Cheers,
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List  On Behalf Of 
Paul Edwards
:>Sent: Thursday, April 4, 2019 8:23 AM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: AMODE 32
:>
:>On Thu, 4 Apr 2019 13:19:03 +, Martin Packer  
wrote:
:>
:>>OK, I'll try...
:>>
:>>... Presumably you'd want this putative 32-bit address space to have
:>>access to all the stuff other address spaces have access to, such as
:>>Shared/Common areas above the bar.
:>
:>No, I'd like current data above the 2 GiB bar to be moved above the 4 GiB new 
bar, clearing the 2 GiB - 4 GiB region for GETMAIN LOC=ANY requests by an AM32 
program.
:>
:>BFN. Paul.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Binyamin Dissen]

The issue is not the likeliness of it happening.

I don't really see a business case for this. If a program already needs 12.G
of data, why do special development which will have a hard cap of 3.2G
especially when the availability of much more is commonly available?

My guess is the OP is married to 4 byte pointers.

On Thu, 4 Apr 2019 13:27:06 + Allan Staller  wrote:

:>Prepare a business case and submit it to IBM.
:>I don’t think this list wants to spend a lot of time on something extremely 
unlikely to happen.
:>
:>Cheers,
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List  On Behalf Of 
Paul Edwards
:>Sent: Thursday, April 4, 2019 8:23 AM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: AMODE 32
:>
:>On Thu, 4 Apr 2019 13:19:03 +, Martin Packer  
wrote:
:>
:>>OK, I'll try...
:>>
:>>... Presumably you'd want this putative 32-bit address space to have
:>>access to all the stuff other address spaces have access to, such as
:>>Shared/Common areas above the bar.
:>
:>No, I'd like current data above the 2 GiB bar to be moved above the 4 GiB new 
bar, clearing the 2 GiB - 4 GiB region for GETMAIN LOC=ANY requests by an AM32 
program.
:>
:>BFN. Paul.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Charles Mills]

+1

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@listserv..ua.edu] On
Behalf Of Don Poitras
Sent: Thursday, April 4, 2019 4:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AMODE 32

In article <8891162166296907.wa.mutazilahgmail@listserv.ua.edu> you
wrote:
> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen
 wrote:
> >What problem would this solve?
> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.
> >This would be of zero use for existing applications,
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
> > and new applications should simply use 64 bit.
> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.
> BFN. Paul.

When you brought this up a year ago, I don't think you convinced anyone
that this was a useful change or that IBM should reasonably spend 
dollars doing it. I doubt much has changed since then to improve your
chances.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Allan Staller]

Prepare a business case and submit it to IBM.
I don’t think this list wants to spend a lot of time on something extremely 
unlikely to happen.

Cheers,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Edwards
Sent: Thursday, April 4, 2019 8:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: AMODE 32

On Thu, 4 Apr 2019 13:19:03 +, Martin Packer  
wrote:

>OK, I'll try...
>
>... Presumably you'd want this putative 32-bit address space to have
>access to all the stuff other address spaces have access to, such as
>Shared/Common areas above the bar.

No, I'd like current data above the 2 GiB bar to be moved above the 4 GiB new 
bar, clearing the 2 GiB - 4 GiB region for GETMAIN LOC=ANY requests by an AM32 
program.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 13:19:03 +, Martin Packer  
wrote:

>OK, I'll try...
>
>... Presumably you'd want this putative 32-bit address space to have
>access to all the stuff other address spaces have access to, such as
>Shared/Common areas above the bar.

No, I'd like current data above the 2 GiB
bar to be moved above the 4 GiB new bar,
clearing the 2 GiB - 4 GiB region for
GETMAIN LOC=ANY requests by an AM32
program.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Martin Packer]

OK, I'll try...

... Presumably you'd want this putative 32-bit address space to have 
access to all the stuff other address spaces have access to, such as 
Shared/Common areas above the bar.



Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Paul Edwards 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   04/04/2019 14:12
Subject:    Re: AMODE 32
Sent by:IBM Mainframe Discussion List 



On Thu, 4 Apr 2019 12:54:28 +, Martin Packer 
 wrote:

> Plus, how would you map Shared or
> Common/System 64-Bit objects into such 
> an address space?

I don't understand this technical question.
Can you rephrase?

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 12:54:28 +, Martin Packer  
wrote:

> Plus, how would you map Shared or
> Common/System 64-Bit objects into such 
> an address space?

I don't understand this technical question.
Can you rephrase?

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Martin Packer]

And please don't tell me you'd want Db2, IMS, CICS, MQ, Websphere 
Application Server to have been 32-bit.

Many other things want scalability beyond 4GB (minus "common").

Plus, how would you map Shared or Common/System 64-Bit objects into such 
an address space?

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Joe Monk 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   04/04/2019 13:40
Subject:        Re: AMODE 32
Sent by:IBM Mainframe Discussion List 



" I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications."

"According to the analyst deck
<https://www.ibm.com/investor/att/pdf/IBM-2Q18-Earnings-Charts.pdf> 
circulated
with the latest set of quarterly financials, the IBM Z mainframe business,
listed under its ‘systems segment’ has doubled year-on-year, pulling in a
tidy US$2.2 billion ($2.96 billion)

Overall revenue rose nearly 4 percent to US$20 billion ($26.9 billion),
beating analysts’ average estimate of $19.85 billion ($26.7 billion),
according to Thomson Reuters I/B/E/S."

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.itnews.com.au_news_mainframe-2Dsales-2Ddouble-2Din-2Dlatest-2Dibm-2Dprofit-2D498679=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=pgxF-yzofWwOBNCorbSZ62a_LiKMJSrCnFacr93Bx6A=HG7JrzodsErEBgjKrvClvXYYI0qF0c1f_5S4P8wCIko=


Joe

On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards  wrote:

> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> wrote:
>
> >What problem would this solve?
>
> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.
>
> >This would be of zero use for existing applications,
>
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 07:46:59 -0400, Don Poitras  wrote:

> When you brought this up a year ago, I don't think you convinced anyone
> that this was a useful change or that IBM should reasonably spend
> dollars doing it. I doubt much has changed since then to improve your
> chances.

Last time I was trying to add a LOC=32
to GETMAIN for use by AMODE 64 programs.

This time I want to retain normal LOC=ANY
for GETMAIN, and introduce a new AMODE 32.

Previously I didn't have a practical way of
adding AM32. It is only recently that I
realized that bits 1-7 of a 32-bit register
could be used by BSM.

I thought more people would like to see a
long-term z/OS that ran purely 32-bit and
64-bit software like other platforms do.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Joe Monk]

" I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications."

"According to the analyst deck
 circulated
with the latest set of quarterly financials, the IBM Z mainframe business,
listed under its ‘systems segment’ has doubled year-on-year, pulling in a
tidy US$2.2 billion ($2.96 billion)

Overall revenue rose nearly 4 percent to US$20 billion ($26.9 billion),
beating analysts’ average estimate of $19.85 billion ($26.7 billion),
according to Thomson Reuters I/B/E/S."

https://www.itnews.com.au/news/mainframe-sales-double-in-latest-ibm-profit-498679

Joe

On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards  wrote:

> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> wrote:
>
> >What problem would this solve?
>
> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.
>
> >This would be of zero use for existing applications,
>
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Joe Monk]

" I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications."

The market disagrees with you, as shown by 64-bit z/arch sales.

Joe

On Thu, Apr 4, 2019 at 7:20 AM Paul Edwards  wrote:

> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> wrote:
>
> >What problem would this solve?
>
> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.
>
> >This would be of zero use for existing applications,
>
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
>
> > and new applications should simply use 64 bit.
>
> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Don Poitras]

In article <8891162166296907.wa.mutazilahgmail@listserv.ua.edu> you wrote:
> On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen 
>  wrote:
> >What problem would this solve?
> It would set the long-term model for the
> mainframe, instead of being stuck with
> 24/31-bit software for eternity.
> >This would be of zero use for existing applications,
> I don't agree. Existing applications can be
> modified to be 32-bit clean and have maximum
> possible address space as per 32-bit.
> > and new applications should simply use 64 bit.
> I don't agree that all new applications should
> be 64 bit. That is overkill. 32-bit/4 GiB should
> be enough for almost all commercial applications.
> BFN. Paul.

When you brought this up a year ago, I don't think you convinced anyone
that this was a useful change or that IBM should reasonably spend 
dollars doing it. I doubt much has changed since then to improve your
chances.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Binyamin Dissen]

On Thu, 4 Apr 2019 06:19:50 -0500 Paul Edwards  wrote:

:>On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen 
 wrote:

:>>What problem would this solve?

:>It would set the long-term model for the
:>mainframe, instead of being stuck with
:>24/31-bit software for eternity.

24/31 is required for downward compatibility.

If you need to change application and you need this much storage, go already
to 64bit. You will need it sooner or later.

:>>This would be of zero use for existing applications,

:>I don't agree. Existing applications can be
:>modified to be 32-bit clean and have maximum
:>possible address space as per 32-bit.

Sounds like a pretty narrow range of applications, where the existing above
the line is not enough, but an extra 2G will be enough forever.

:>> and new applications should simply use 64 bit.

:>I don't agree that all new applications should
:>be 64 bit. That is overkill. 32-bit/4 GiB should
:>be enough for almost all commercial applications.

Why do you feel 64bit is "overkill"?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Thu, 4 Apr 2019 13:55:30 +0300, Binyamin Dissen  
wrote:

>What problem would this solve?

It would set the long-term model for the
mainframe, instead of being stuck with
24/31-bit software for eternity.

>This would be of zero use for existing applications,

I don't agree. Existing applications can be
modified to be 32-bit clean and have maximum
possible address space as per 32-bit.

> and new applications should simply use 64 bit.

I don't agree that all new applications should
be 64 bit. That is overkill. 32-bit/4 GiB should
be enough for almost all commercial applications.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Binyamin Dissen]

What problem would this solve?

This would be of zero use for existing applications, and new applications
should simply use 64 bit.

On Wed, 3 Apr 2019 18:17:46 -0500 Paul Edwards  wrote:

:>I was thinking that z/Arch and z/OS could
:>be updated to support AMODE 32.

:>If a load module is marked AMODE ANY,
:>RMODE ANY it could signify that it is
:>32-bit clean. That combination is
:>currently not really used, and the linker
:>can be updated to accept this combination.

:>PSW bit 30 can be used to signify that an
:>application is running AM32.

:>The BSM instruction can use bit x'4000 '
:>to get/set AM32. This introduces a 1 GiB
:>restriction where the module should not
:>be loaded above if it needs to switch
:>AMODEs to call READ etc. But that's another
:>restriction that could be lifted in z/OS.
:>z/OS can instead switch to AM31 itself,
:>with the READ code being located below 1 GiB.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Joe Monk]

"PSW bit 30 can be used to signify that an
application is running AM32."

Whats the ROI to the customer for IBM spending the $$$ to research and
modify all of the micro/macro/OS code to allow bit 30 to be anything other
than 0?

You have to realize that the prices are going to increase to cover those
costs from IBMs point of view... Its not a one man job to allow that to
happen.

Joe

On Wed, Apr 3, 2019 at 7:18 PM Paul Edwards  wrote:

> I was thinking that z/Arch and z/OS could
> be updated to support AMODE 32.
>
> If a load module is marked AMODE ANY,
> RMODE ANY it could signify that it is
> 32-bit clean. That combination is
> currently not really used, and the linker
> can be updated to accept this combination.
>
> PSW bit 30 can be used to signify that an
> application is running AM32.
>
> The BSM instruction can use bit x'4000 '
> to get/set AM32. This introduces a 1 GiB
> restriction where the module should not
> be loaded above if it needs to switch
> AMODEs to call READ etc. But that's another
> restriction that could be lifted in z/OS.
> z/OS can instead switch to AM31 itself,
> with the READ code being located below 1 GiB.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Mike Schwab]

z/OS is already using the 2GiB to 4GiB area.

On Wed, Apr 3, 2019 at 7:51 PM Paul Edwards  wrote:
>
> On Wed, 3 Apr 2019 19:38:02 -0500, Paul Gilmartin  
> wrote:
>
> >>I was thinking that z/Arch and z/OS could
> >>be updated to support AMODE 32.
>
> >Cui bono?
>
> Combined with making GETMAIN LOC=ANY,
> when executed AM32, getting memory in the
> 2 GiB to 4 GiB region, it would allow a long
> term plan of having purely 32-bit and purely
> 64-bit software running on z/OS, with access
> to the full address space, the same as other
> platforms have. AM24 and AM31 software
> can be phased out.
>
> BFN. Paul.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Edwards]

On Wed, 3 Apr 2019 19:38:02 -0500, Paul Gilmartin  wrote:

>>I was thinking that z/Arch and z/OS could
>>be updated to support AMODE 32.

>Cui bono?

Combined with making GETMAIN LOC=ANY,
when executed AM32, getting memory in the
2 GiB to 4 GiB region, it would allow a long
term plan of having purely 32-bit and purely
64-bit software running on z/OS, with access
to the full address space, the same as other
platforms have. AM24 and AM31 software
can be phased out.

BFN. Paul.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: AMODE 32

[Paul Gilmartin]

On Wed, 3 Apr 2019 18:17:46 -0500, Paul Edwards wrote:

>I was thinking that z/Arch and z/OS could
>be updated to support AMODE 32.
> 
Cui bono?

Actually, Java uses 32-bit addressing.  In a way.  Simulated.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN