Hi
I have a amode 64 rmode 31 program I would like to do I/O So I have to have
the DCB below 16mb So I have LOAD a module amode 64 rmode 24
After loading I turn the 1 bit to the right off now I have a clean half
address when I BASR to it bombs and the PSW has the one bit on
A funny thin
The paucity of detail makes answering your inquiry a matter of
inductive supposition. Maybe you should post additional information such as:
Source code?Assembly listing?ABEND code?SysLog?
Keven
On Thu, Nov 21, 2019 at 9:26 PM -0600,
Or maybe a question instead of a musing?
Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.
On Fri, Nov 22, 2019, 1:00 AM Keven wrote:
>
>
>
>
> The paucity of detail makes answering your inquiry a matter of
> inductive supposition. Maybe you should post additional information suc
Ref: Your note of Thu, 21 Nov 2019 22:26:07 -0500
BASR doesn't switch AMODE. If you want to switch AMODE you need
to use BASSM (and return using BSM, as the return address will
be odd for AMODE 64).
If you BASR staying in AMODE 64, the high word of the register
needs to be zero. If you're not
I understand haven’t program that much in amode 64
Thanks
Joe Reichman
170-10 73 rd ave
Fresh meadows NY 11366
> On Nov 22, 2019, at 5:50 AM, Jonathan Scott
> wrote:
>
> Ref: Your note of Thu, 21 Nov 2019 22:26:07 -0500
>
> BASR doesn't switch AMODE. If you want to switch AMODE you n
I continue not to understand why you repeatedly fail to provide the
information necessary for the good folks on this list to help you.
So I have LOAD a module amode 64 rmode 24
Your module does not need to match the RMODE of your DCB unless your DCB
is physically resident in the module, namely
My mistake was jumping the gun and not looking at the reason code
It clearly stated that S0C4 Reason code 38
Had to do with AMODE 64 when the high order bit of a 31 bit pointer ( which is
not part of the address in amode 31 but is in amode 64 ) it is best practice to
do a LLGTR RX before basri
ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as
the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we
were in 24-bit or 31-bit.
So the 64-bit guys decided that the easiest fix was to completely disallow
any address from 800 through to 8FFF, which
The original "dead zone" was x'8000 ' to x' '. I think I
remember my first IARVx giving me address x' 0001 ', but that
was long ago. This has been expanded up to the 32gb uh... border (x'
0008 ') some years ago. Rumor is Java uses this area to have 32gb
of a
On Fri, 22 Nov 2019 15:14:13 +, Dougie Lawson wrote:
>ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as
>the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we
>were in 24-bit or 31-bit.
>
>So the 64-bit guys decided that the easiest fix was to complete
On 2019-11-22, at 08:14:13, Dougie Lawson wrote:
>
> ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as
> the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we
> were in 24-bit or 31-bit.
>
> So the 64-bit guys decided that the easiest fix was to completel
The “dead zone” is an OS-specific restriction. Processes running under
Linux on z/Architecture see the whole 64-bit address space, for example.
Keven
On Fri, Nov 22, 2019 at 4:23 PM -0600, "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ
Am 22.11.2019 um 23:23 schrieb Paul Gilmartin:
Do I understand correctly that enforcement is entirely by
software; those addresses are quite acceptable to the hardware?
the translation of the virtual addresses to real addresses is not done
by software only; there is some hardware support.
The
Yes, hardware translation uses the translation tables maintained by the
software. If the translation tables indicate a specific virtual page
does not have a corresponding real memory frame, it returns a program
check; it is up to the software how to respond to the program check:
assign a frame, pa
On Mon, Nov 25, 2019 at 10:04 AM Gary Weinhold wrote:
> Yes, hardware translation uses the translation tables maintained by the
> software. If the translation tables indicate a specific virtual page
> does not have a corresponding real memory frame, it returns a program
> check; it is up to the
On Sat, 23 Nov 2019 at 01:11, Bernd Oppolzer
wrote:
> As others have pointed out, the different OSes have different strategies;
> z/OS does never allocate virtual addresses from 0x8000 to 0x.
>
I sometimes wish the Principles of Operation would along those lines avoid
to allocate so
> On 2019-11-25, at 09:37:13, John McKown wrote:
>
> On Mon, Nov 25, 2019 at 10:04 AM Gary Weinhold wrote:
>> ...
>> There's more to it than that, of course. But the developers of z/OS
>> decided that 31-bit programs should be minimally impacted by 64-bit
>> addressability.
>>
> I'd much perfer
z/OS does never allocate virtual addresses from 0x8000 to 0x.
Not quite true. Never say never :-) .
History: XA architecture in effect introduced the "line", an obvious
differentiating point between 24-bit and 31-bit storage at 16M.
z/OS (not z/Architecture) introduced the "bar", a
I believe the greater accommodation was the hardware architecture's
expanding from 24-bit addressing to only 31 rather than 32 because software
so pervasively uses the sign bit for a flag.
My guess was that "2 GB of addressability is all that anyone could ever
possibly need!"
Charles
On Tue, 26 Nov 2019 10:29:32 -0700, Paul Gilmartin wrote:
>I believe the greater accommodation was the hardware architecture's
>expanding from 24-bit addressing to only 31 rather than 32 because
>software so pervasively uses the sign bit for a flag.
I don't think so. I don't have any information
metz3
From: IBM Mainframe Assembler List on behalf
of Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu>
Sent: Wednesday, November 27, 2019 11:41 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
On Tue, 26 Nov 2019 10:
On Wed, 27 Nov 2019 17:26:35 +, Seymour J Metz wrote:
>TSS/360 used an explicit length at offset -4 from the parameter list, so the
>end-of-list bit wasn't an issue.
>The addresses transition from 7FFF_ to 8000_ is a z/OS
>issue rather than an architectural issue.
I
Good grief. I really wonder why the BX* instructions don't use logical
compares, like I assumed they did. In any case, that quote is almost
nonsense, as address wrap-around has been a feature since the dawn of
time. 2^31-1 + 1 = 0, for addressing purposes. And yet the BX*
instructions treat add
On Wed, 27 Nov 2019 12:47:44 -0500, Steve Smith wrote:
>Notwithstanding all the expert opinions, from my point of view, XA would
>have better gone to 32-bit addressing from the get-go. I don't see the
>benefit of the amode being part of the address. Seems to me it's been a
>lot of unnecessary co
On 2019-11-27, at 10:26:35, Seymour J Metz wrote:
>
> TSS/360 used an explicit length at offset -4 from the parameter list, so the
> end-of-list bit wasn't an issue.
>
> The addresses transition from 7FFF_ to 8000_ is a
> z/OS issue rather than an architectural issue.
>
I must fall back on "I know very little about Intel architecture". They do
have different modes, which are actually more involved than just
addressing. I get the impression some of the older ones have been
abandoned.
They have far less assembler code to worry about carrying forward.
Regardless,
Actually, my real point is that XA could have been the transition that got
us completely away from "dirty" addresses.
And btw, a 'LLG24' instruction would be nice to have. The total cost of
changing GET/PUT/READ/WRITE to using SR/ICM must world-wide represent the
waste of dozens of dollars in ext
Ref: Your note of Wed, 27 Nov 2019 13:16:33 -0500
> My point is that XA took away 7 bits that were used for various purposes.
> Taking all 8 wouldn't have been a lot more painful.
>
> sas
Are you serious? The main problem with going from 24-bit to
32-bit addressing was that the standard linkage
there's a little-known "mini-bar" at the high-end of the 31-bit address
space
True. The x'7000' page of the address space is intentionally not
mapped in virtual and accessing that location in an address space
(assuming AMODE 31 or 64) will always program check. Maybe some day we'll
do th
On 2019-11-28, at 07:08:16, Peter Relson wrote:
>
>
> there's a little-known "mini-bar" at the high-end of the 31-bit address
> space
>
>
(I'd be grateful if citations of earlier plies included the
Sender and Date so I might consult the entire text. And if
the (old-fashioned) ">" quotation i
> On 2019-11-27, at 11:24:20, Jonathan Scott wrote:
>
> Ref: Your note of Wed, 27 Nov 2019 13:16:33 -0500
>
>> My point is that XA took away 7 bits that were used for various purposes.
>> Taking all 8 wouldn't have been a lot more painful.
>>
>> sas
>
> Are you serious?
>
He's serious. Duri
Yep, serious, at least as far as a moot & hypothetical discussion of
history goes. There are (hypothetically) other ways to handle those issues.
Having R15 as the incoming EPA has never been more than a convenience
anyway. The first example program in my first assembler class (long before
MVS/XA,
On Mon, Dec 2, 2019 at 8:31 AM Steve Smith wrote:
> Yep, serious, at least as far as a moot & hypothetical discussion of
> history goes. There are (hypothetically) other ways to handle those
> issues.
>
> Having R15 as the incoming EPA has never been more than a convenience
> anyway. The first e
Or
LR 12,15
USING entrypointname,12
On Mon, 2 Dec 2019 at 10:03, John McKown
wrote:
> On Mon, Dec 2, 2019 at 8:31 AM Steve Smith wrote:
>
> > Yep, serious, at least as far as a moot & hypothetical discussion of
> > history goes. There are (hypothetically) other ways to handle thos
On 12/2/2019 7:58 AM, Kerry Liles wrote:
Or
LR 12,15
USING entrypointname,12
And, of course, R15 is not even loaded with the entry point address for
programs given control in AMODE(64) :-\
These days, one is expected to issue LARL/USING to your program
constants. There is gener
Point taken! Thanks for clarification and I agree about base registers in
general.
On Dec 2, 2019 11:48 AM, "Ed Jaffe" wrote:
> On 12/2/2019 7:58 AM, Kerry Liles wrote:
>
>> Or
>>
>> LR 12,15
>> USING entrypointname,12
>>
>
>
> And, of course, R15 is not even loaded with the entry poi
I just had that discussion on a different forum with a guy who converted a
program to AMODE 64 and got surprised by that. "Why was my program loaded
at x'FF02', and why do I get a S0C4?"
However, that really only applies to system-controlled linkage. Normal
linkage can be, and often is used
From: IBM Mainframe Assembler List on behalf
of Ed Jaffe
Sent: Monday, December 2, 2019 11:48 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
On 12/2/2019 7:58 AM, Kerry Liles wrote:
> Or
>
> LR 12,15
>
On 2019-12-02, at 09:48:39, Ed Jaffe wrote:
>
> On 12/2/2019 7:58 AM, Kerry Liles wrote:
>> Or
>>
>> LR 12,15
>> USING entrypointname,12
>
> And, of course, R15 is not even loaded with the entry point address for
> programs given control in AMODE(64) :-\
>
That strikes me as thoughtl
From: IBM Mainframe Assembler List on behalf
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Monday, December 2, 2019 5:42 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
On 2019-12-02, at 09:48:39, Ed Jaffe wrote:
>
> On 12/2/2019 7:
ument with your assertion that small is good.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Monday, December 2, 2019 11:08 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
Ob
Steve Smith wrote
I found that a couple of
IBM AMODE 64 callable routines expect R15 to be set to their EPA, although
most do not. I discovered these when I made the calls using JASL (
I trust you are aware that "callable" really does mean using "CALL"
(whether in a HLL or, in assembler, by the
On Tue, 3 Dec 2019 09:10:42 -0500, Peter Relson wrote:
>I suggest that you look up what the value in reg 15
>means for this case (it should be documented somewhere), and for the other
>system-assisted linkage cases.
It is documented. For example:
https://www.ibm.com/support/knowledgecenter/SSLT
...inline...
On Tue, Dec 3, 2019 at 9:10 AM Peter Relson wrote:
> Steve Smith wrote
>
> I found that a couple of
> IBM AMODE 64 callable routines expect R15 to be set to their EPA, although
> most do not. I discovered these when I made the calls using JASL (
>
> I trust you are aware that "ca
On 2019-12-03, at 07:10:42, Peter Relson wrote:
>
> ... And, yes, there are cases were relocation applies even to
> use of relative branches. I'll leave that teaser as an exercise for the
> readers.
>
Are cross-CSECT relative branches supported? That feels like an
invitation to disaster: erro
On 12/3/2019 11:07 AM, Paul Gilmartin wrote:
Are cross-CSECT relative branches supported? That feels like an
invitation to disaster: errors that can not be detected before
execution.
They have been supported since z/OS 1.7 or 1.8. Very handy to have!!!
--
Phoenix Software International
Edw
2019 2:07 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
On 2019-12-03, at 07:10:42, Peter Relson wrote:
>
> ... And, yes, there are cases were relocation applies even to
> use of relative branches. I'll leave that teaser as an exercise for the
> readers.
>
J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Charles Mills
Sent: Monday, December 2, 2019 10:54 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
What does CSECT size have to do with base regis
Gil wrote
>
> ... And, yes, there are cases were relocation applies even to
> use of relative branches. I'll leave that teaser as an exercise for the
> readers.
>
Are cross-CSECT relative branches supported? That feels like an
invitation to disaster: errors that can not be detected before
exe
Branch Relative handles an offset up to 4 GiB.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Seymour J Metz
Sent: Tuesday, December 3, 2019 2:28 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
With a signed offset.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Charles Mills
Sent: Wednesday, December 4, 2019 11:22 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
>From: IBM Mainframe Assembler List on behalf
>of Charles Mills
>Sent: Wednesday, December 4, 2019 11:22 AM
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>Subject: Re: BASR to AMODE 64
>
>Branch Relative handles an offset up to 4 GiB.
>
>Charles
ttle of
aspirins.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Ed Jaffe
Sent: Monday, December 2, 2019 11:48 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64
On 12/2/2
On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote:
>Even when using "baseless" code, I like to keep ONE register
>as the base/entry point of the module (plus what ever is
>needed for constant/data areas beyond the first 4K).
Locating your constants at the beginning of the program allows
you t
On 12/2/2019 12:02 PM, Tom Marchant wrote:
Locating your constants at the beginning of the program allows
you to do that without sacrificing a register.
Prezactly! That's what we do (using LOCTRs)...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90
On 12/2/2019 12:02 PM, Tom Marchant wrote:
Locating your constants at the beginning of the program allows
you to do that without sacrificing a register.
Prezactly! That's what we do (using LOCTRs)...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 9
On 2019-12-02, at 13:02:39, Tom Marchant wrote:
>
> On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote:
>
>> Even when using "baseless" code, I like to keep ONE register
>> as the base/entry point of the module (plus what ever is
>> needed for constant/data areas beyond the first 4K).
>
> Loca
On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> In the source? Branch around them or use LOCTR? What difference
> does it make as long as instructions plus data do not exceed 4Ki?
For programs that don't use a base r
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Monday, December 2, 2019 2:56 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64 (Baseless code)
On 2019-12-02, at 13:02:39, Tom Marchant wrote:
>
> On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote:
>
-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64 (Baseless code)
Even when using "baseless" code, I like to keep ONE register as the base/entry
point of the module (plus what ever is needed for constant/data areas beyond
the first 4K). Having a register thus set makes looking at a dump
bject: Re: BASR to AMODE 64 (Baseless code)
On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> In the source? Branch around them or use LOCTR? What difference
> does it make as long as instructions plus da
ason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List on behalf
of Ngan, Robert
Sent: Tuesday, December 3, 2019 4:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: BASR to AMODE 64 (Baseless code)
We use TWO LOCTR's, one for constants required to be within 4K of the ba
Subject: Re: BASR to AMODE 64 (Baseless code)
On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> In the source? Branch around them or use LOCTR? What difference
> does it make as long as instructions plus data d
63 matches
Mail list logo