Re: GETMAIN LOC=32

[somitcw]

Reading to cure insomnia:

There may be a real reason why Paul's wording of an
RFE "perhaps" "might" "possibly" be a non-started?

The requests had no suggestions for 32-bit programs.
Non-U.S. based Paul just has issues with English.
There were no suggestions for AMODE 32.
Non-U.S. based Paul just has issues with English.
There is no issue with non-AMODE 64 parameter lists.
There is no issue with writing or rewriting code.
The wild tangents dreamed up to claim why
GETMAIN LOC=2GB.to.4GB-1 is an issue are dreamed
up wild tangents.
ELSQA memory fragmentation is a minor inconvenience
for people using the requested feature only.
IARV64 REQUEST=GETSTOR losing 2GB out of 16XB or
JAVA area losing 2GB is sad but I'm not crying.

But there is a real reason why GETMAIN LOC=32 may
have an issue.

Dr. Gene claimed that the reason that IBM dropped
from AMODE 32 to AMODE 31 was because of a typo in
the Principals of Operation for BXH/BXLE.

Translated, even S360-24bit used algebraic 32 bit
addresses for BXH/BXLE to allow negative displacements.
Algebraic indexing from 2GB-1 to 2GB gives the higher
address a negative number so it is lower than the low
address.
There should be logical BXH/BXLE equilavants but are not.
Was IBM switching from AMODE 32 to AMODE 31 better than
just adding logical equivalents for BXH/BXLE ?

Of course, the data area is requested for AMODE 64
programs so using BXH/BXLE in AMODE 31 has no
relavances to the GETMAIN change request.

But I checked the manuals.  See below.
You can skip to the last note which is for the
zArch for BXH/BXHG/BXLE/BXLEG to see the issue.
I had to change the format for exponentiation
because I post in plain text.  Sorry.
Copy/Paste from OCRed .pdf file could also
introduce some errors.  Sorry again.

Of course, Paul will say that all is AMODE 64 with
all 64 bits registers so both switching to AMODE 31
and using BXH/BXLE on the 2GB to 4GB-1 memory
should cause the issue the programmer asked for.
Using the proper AMODE 64 or the proper AMODE 64
instructions BXHG/BXLEG does not have the issue
with 32 bit algebraic values.

I can't fix the problem with Paul calling the using
of addresses from zero to 4GB-1 a 32-bit system.
It's AMODE 64, it works no difference than
GETMAIN LOC=24 or GETMAIN LOC=31 when used by an
AMODE 64 program.  No difference than a 24 bit
address being stored in an 8 byte register.
Yes, the high order 5 bytes are zero but that is
a given.  Can't fix Paul.

A22-6821-0
IBM System/360 Principles of Operation
Really old and not dated
Pages 64 and 65

Branch On Index High
BXH RS
The second operand is added to the first operand, and 
the sum is compared algebraically with the third op-
erand. Subsequently, the sum is placed in the first 
operand location, regardless of whether the branch is 
taken. When the sum is high, the instruction address 
is replaced by the branch address. When the sum is 
low or equal, instruction sequencing proceeds with the 
updated instruction address. 
 The first and the second operands are in the registers 
specified hy Rl and R3. The third operand register ad-
dress is odd and is either one larger than R3 or equal 
to R3. The branch address is determined prior to the 
addition and comparison.
 Overflow caused by the addition is ignored and does
not affect the comparison. Otherwise, the addition and
comparison proceed as in fixed-point arithmetic. All
32 bits of the general registers participate in the opera-
tions, and negative quantities are expressed in two's-
complement notation. When the first and third oper-
and locations coincide, the original register contents
are used as third operand. 
 Condition Code: The code remains unchanged. 
 Program Interruptions: None.
Programming Note 
The name "branch on index high" indicates that one 
of the major purposes of this instruction is the incre-
menting and testing of an index value. The increment 
may be algebraic and of any magnitude.


SA22-7832-10
z/Architecture Principles of Operation
March 2015
Pages 7-39 and 7-40

BRANCH ON INDEX HIGH 
BXH R1,R3,D2(B2) [RS-a]
BXHG R1,R3,D2(B2) [RSY-a]

BRANCH ON INDEX LOW OR EQUAL 
BXLE R1,R3,D2(B2) [RS-a]
BXLEG R1,R3,D2(B2) [RSY-a]

An increment is added to the first operand, and the
sum is compared with a compare value. The result of
the comparison determines whether branching
occurs. Subsequently, the sum is placed at the first-
operand location. The second-operand address is
used as a branch address. The R3 field designates
registers containing the increment and the compare
value. 

For BRANCH ON INDEX HIGH, when the sum is
high, the instruction address in the current PSW is
replaced by the branch address. When the sum is
low or equal, normal instruction sequencing pro-
ceeds with the updated instruction address. 

For BRANCH ON INDEX LOW OR EQUAL, when the
sum is low or equal, the instruction address in the
current PSW is replaced by the branch address.
When the sum is high, normal instruction sequencing
proceeds with the updated 

Re: GETMAIN LOC=32

[somitcw]

I never ran a S/360-32bit system, but
different users logged on to TSS in different modes.
An IPL of the entire computer complex every time
that every user logged on was probably not done.
i.e. It was a bi-modal architecture.
An LPSW or other instruction would have made
more sense.

I also believe, but have no experience, that memory
from 2GB to 4GB-1 was avoided because there were
no logical versions of BXH and BXLE and some
programmers like to index.

- - - old post - - -

Subject: Re: GETMAIN LOC=32
From: Joe Monk 
Date: Fri, 11 May 2018 11:57:19 -0500

"How did that work? Did a high bit in BASR
cause AM32 to be activated?"

No ... the 360-67 had to be IPL'd in extended PSW mode to activate
AM32. Otherwise it was a BC mode PSW machine...

Joe

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

Re: GETMAIN LOC=32

[somitcw]

SG24-7605-00
z/OS Version 1 Release 10 Implementation
April 2009
Pages 6 and 104
Claims that next to E-Nuc is ESQA, ELPA, ECSA, then E-private.

When did they move?
Are we requesting a feature that is already there?
IBM could do that real quick.

Paul's wanting SVC 120 to get memory up to 4GB-1 and
have IARV64 and IARST64 stick with 33 to 64bit addresses
would actually need a couple of code changes and a little
documentation.

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

Re: GETMAIN LOC=32

[somitcw]

Thank you, but I don't believe that that is what Paul trying to do?
Paul requested GETMAIN 
LOC=2GBto4GB-1.if.unavailable.16MBto4GB-1.if.unavailable.0Bto16MB-1
Moving extended common to put it near the common E-Nuc was not originally 
thought of.

Is there anyway the "already available" could block allocation in the 4GB to 
32GB-1 range.
Perhaps GETSTOR for all 30GB to get 2GB and not use the 28GB over 4GB-1 ?
Or an RFE to add IARV64 GETSTOR with Use2Gto4G=YES
Which still would not add what Paul said he was after and when full, might not 
drop to lower
memory addresses.

Or as most people would agree, kill the thread.

 - - - old notes below - - -

On Thu, 10 May 2018 18:58:41 -0400, Jim Mulder  posted:

  It would be a waste of time to submit such an RFE.

  GETMAIN will not be changed to manage addresses 
above 2GB.

  Extended common will not be moved.

  The interface to allocate the storage in the 2GB to 4GB-1 
address range is already available - 
IARV64 GETSTOR  with  USE2GTO32G=YES
 
Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY

> The request was for suggested wording for an RFE for AMODE 64 to change
> data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
> memory there.  To insure that only AMODE 64 programs that wanted the
> memory, the AMODE 64 program would specify something like
> GETMAIN LOC=32 in the source of the AMODE 64 program.
> 
> The RFE would double the addressable memory with an address
> storable in four bytes for data for an AMODE 64 program.
> That is an incredible enhancement allowed for AMODE 64 programs.
> If people wish to convert old programs from their existing AMODE to
> a different AMODE, that is fine.  If they want to use the AMODE 64
> enhancement that the RFE would request, then their program would
> need to be AMODE 64 or converted to AMODE 64.
> 
> Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
> S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
> ESA/370, and other totally off a tangent responses do not help
> address the RFE wording question.
> 
> Please help shorten this thread by helping with the wording needed to
> request an AMODE 64 enhancement for AMODE 64 programs that
> would double the 4-byte addressable for data.
> Moving extended common would be icing on the cake.

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

Re: GETMAIN LOC=32

[somitcw]

Tom Marchant  posted:
>On Thu, 10 May 2018 08:47:33 -0500, Paul Edwards wrote:
>This is a matter of defining "best programming
>>practices" and noting that you can't rely on the
>>BALR crap byte
> est for you perhaps. Using only a limited subset of the instruction set. 
>And you don't seem to understand the value of the linkage information 
>saved in R1 by BAL and BALR in AMODE(24).
> This is a pointless discussion.
> -- 
>Tom Marchant

The request was for suggested wording for an RFE for AMODE 64 to change
data addresses 2GB to 4GB-1 so AMODE 64 could use GETMAIN to get
memory there.  To insure that only AMODE 64 programs that wanted the
memory, the AMODE 64 program would specify something like
GETMAIN LOC=32 in the source of the AMODE 64 program.

The RFE would double the addressable memory with an address
storable in four bytes for data for an AMODE 64 program.
That is an incredible enhancement allowed for AMODE 64 programs.
If people wish to convert old programs from their existing AMODE to
a different AMODE, that is fine.  If they want to use the AMODE 64
enhancement that the RFE would request, then their program would
need to be AMODE 64 or converted to AMODE 64.

Posts about BAL, BALR, crap bytes, AMODE 24, AMODE 31, AMODE 32,
S/370-24bit, S/370-31bit, S/360-32bit, MVS 3.8j, PDOS, MVS/XA,
ESA/370, and other totally off a tangent responses do not help
address the RFE wording question.

Please help shorten this thread by helping with the wording needed to
request an AMODE 64 enhancement for AMODE 64 programs that
would double the 4-byte addressable for data.
Moving extended common would be icing on the cake.

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

Re: GETMAIN LOC=32

[somitcw]

One poster asked for recommendations for a RFE to request that SVC 120 be 
updated to
be compatible with what was needed for a S/360-67 that was announced on 
1965-08-16.
The discussion resulted in strange discussion about AMODE, unrelated 
architecture changes,
unrelated program changes, unrelated PARM list changes, unrelated motives, etc.

Yes, it was obvious that AMODE 64 would be require to use memory above 2GB.
But we already have AMODE 64 programs and that is what would be used.

Yes, we know the history of IBM S/360-24bit, S/360-16bit, S/360-32bit, etc.
But that doesn't change the SVC 120 update request.

Yes, we know that quad-modal is not wanted.
But, the SVC 120 request had nothing to do with quad-modal.

There was a hint that moving the location of extended common memory might be 
nice.
But that is not a requirement or even a stated request.
Knowing the requestor, I'm certain that he will request that and other 
strangeness later.

Suggesting different GETMAIN parameter list bits might be helpful.
Explaining that IBM doesn't like upward compatibility from S/360-32bit might be 
helpful.
Inventing architectural changes was not helpful.

The requested GETMAIN/FREEMAIN SVC 120 change would harm no one but would
only help IBM's income by adding marketing propaganda.
i.e. Hooray, IBM can again use 32-bit virtual memory, hooray.

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