That's only partly true. Of the three such languages that I'm familiar with,
they all write the numbers so that higher order digits are to the left of lower
order digits but not all of them read in left to right order. One of them reads
the numbers right to left i.e. units tens hundreds order.
On Wed, 3 Jul 2019 17:14:12 +, Seymour J Metz wrote:
>> I think the cultures that read from right to left number the pages that way
>> also.
>
>The cultures that read from right to left still read Arabic numerals (not to
>be confused with the numerals in the Arabic script) from left to
smetz3
From: IBM Mainframe Discussion List on behalf of
Charles Mills
Sent: Tuesday, July 2, 2019 7:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc
inconsistency?
You are right of course: pr
Charles Mills wrote:
>Absent a total re-engineering of the hardware, that will never
>change on a Z box. And if it somehow magically did change, every
>bit of Z software would have to be examined and tested and in
>many cases re-coded.
There are many "bi-endian" processors, including Power
Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Harminc
Sent: Tuesday, July 2, 2019 4:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Endianness and bit numbering Was RE: STORAGE OBTAIN doc
inconsistency?
On Tue, 2 Jul 2019 at 17:33, Char
mbering are mostly not.
Tony H.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Harminc
> Sent: Tuesday, July 2, 2019 10:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: STORAGE OBTAIN doc inconsistency?
>
Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Harminc
Sent: Tuesday, July 2, 2019 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE OBTAIN doc inconsistency?
On Mon, 1 Jul 2019 at 15:06, Charles Mills wrote:
>
> You're right, of course. Not to start
ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tony Harminc
Sent: Tuesday, July 2, 2019 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE OBTAIN doc inconsistency?
On Mon, 1 Jul 2019 at 15:06, Charles Mills wrote:
>
> You're right, of course. Not to start a religious war, but
On Mon, 1 Jul 2019 at 15:06, Charles Mills wrote:
>
> You're right, of course. Not to start a religious war, but even on a
> big-endian machine, it seems to me to make sense to number
> the bits from LSB to MSB. Bit n then represents 2^n -- in an 8-, 16-, 32-,
> 64- or 128-bit integer. What
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Smith
Sent: Monday, July 1, 2019 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE OBTAIN doc inconsistency?
The notation that would be clearest is to number the bits from
Steve,
Absolutely, clarification always helps.
Scott
On Mon, Jul 1, 2019 at 9:41 AM Steve Smith wrote:
> The notation that would be clearest is to number the bits from right to
> left. However, that may well cause other logical problems on a big-endian
> architecture. And obviously, such a
The notation that would be clearest is to number the bits from right to
left. However, that may well cause other logical problems on a big-endian
architecture. And obviously, such a change would be ludicrous at this point.
I don't think there's any way to support the old 32-bit numbering that
Peter,
I always liked to see the macro, with the options and then examples.
Maybe because I am a visual learner, but this is easier for me..
Just a thought...
Scott
On Thu, Jun 27, 2019 at 7:49 AM Peter Relson wrote:
> I (to some extent "unfortunately") expect such inconsistency across the
>
I (to some extent "unfortunately") expect such inconsistency across the
suite of books (imagine if we still supported both ESA/390 and z
Architectures as options -- what "notation" would we use)? The effort to
change every 32-bit-register bit reference to its "appropriate"
64-bit-register bit
:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE OBTAIN doc inconsistency?
On Wed, 26 Jun 2019 09:36:26 -0700, Charles Mills wrote:
Is this worthy of an RFC or am I missing something?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.ieaa400
On Wed, 26 Jun 2019 at 13:21, Charles Mills wrote:
>
> Yep. A typo in my typo complaint.
https://en.wikipedia.org/wiki/Muphry's_law
Tony H.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to
Yep. A typo in my typo complaint.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Tom Marchant
Sent: Wednesday, June 26, 2019 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: STORAGE OBTAIN doc inconsistency?
On Wed, 26
On Wed, 26 Jun 2019 09:36:26 -0700, Charles Mills wrote:
>Is this worthy of an RFC or am I missing something?
>
>https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
>.ieaa400/iea3a4_STORAGE_OBTAIN.htm says
>
>,SP=subpool number
>Specifies the subpool number for the
On Wed, Jun 26, 2019 at 11:36 AM Charles Mills wrote:
> Is this worthy of an RFC or am I missing something?
>
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
> .ieaa400/iea3a4_STORAGE_OBTAIN.htm says
>
> ,SP=subpool number
> Specifies the subpool number for the
Is this worthy of an RFC or am I missing something?
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3
.ieaa400/iea3a4_STORAGE_OBTAIN.htm says
,SP=subpool number
Specifies the subpool number for the storage. (See z/OS MVS Programming:
Authorized Assembler Services Guide
20 matches
Mail list logo
