Re: BASR to AMODE 64
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 software (the OS) decides, which virtual addresses are valid (and which are not), simply by putting entries for the valid page numbers into the translation tables. The translation itself is supported in part by the hardware (for example: translation lookaside buffers etc.). As others have pointed out, the different OSes have different strategies; z/OS does never allocate virtual addresses from 0x8000 to 0x. The reason is that in AMODE 31 addresses often have the leftmost bit on, which has no meaning, but with AMODE 64, this bit is part of the address and should be zero with valid 31 bit addresses. IBM wanted that nobody uses a valid 31 bit address with the leftmost bit on with AMODE 64 and gets a wrong access (to the address + 0x8000) undetected ... that is, a module that works with AMODE 31 must be fixed to use clean 31 bit addresses to work with AMODE 64, too; it is not sufficient to zero only the left half of the address register. HTH, kind regards Bernd
Re: BASR to AMODE 64
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...@listserv.uga.edu> wrote: 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 completely disallow > any address from 800 through to 8FFF, which is an extremely good > idea to avoid breaking 31-bit code. > Do I understand correctly that enforcement is entirely by software; those addresses are quite acceptable to the hardware? > They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and > we've seen a few of those with Db2). -- gil
Re: BASR to AMODE 64
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 completely disallow > any address from 800 through to 8FFF, which is an extremely good > idea to avoid breaking 31-bit code. > Do I understand correctly that enforcement is entirely by software; those addresses are quite acceptable to the hardware? > They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and > we've seen a few of those with Db2). -- gil
Re: BASR to AMODE 64
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 completely disallow >any address from 800 through to 8FFF, which is an extremely good >idea to avoid breaking 31-bit code. Yes, that was true initially for MVS. Some people have erroneously thought that meant that a valid 64-bit address could not have bit 32 on. I have seen code that tested bit 32 as part of a test to determine whether a 64-bit address was valid. Later, the area from 2G to 32G, and still later 2G to 64G was reserved for Java. IIRC the first of these was documented in an announcement letter. > >They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and >we've seen a few of those with Db2). More precisely, PIC 39, 3A and 3B are region translation exceptions. >You'll soon learn you're in the wrong addressing mode with a PIC38. Reset >the 32nd bit before mode switching to 64 and you won't fail that way. That won't help you much. If you are referencing addresses below the bar while running AMODE 64, you need to clear bits 0-32 of your base registers. -- Tom Marchant
Re: BASR to AMODE 64
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 addressability using 32-bit (3-bit shifted) pointers. But it was (and is) very wise to avoid using that range. In non-AMODE64 bit 32 is used as a flag, and as the AMODE bit for linking. sas On Fri, Nov 22, 2019 at 10:14 AM 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 completely disallow > any address from 800 through to 8FFF, which is an extremely good > idea to avoid breaking 31-bit code.
Re: BASR to AMODE 64
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 is an extremely good idea to avoid breaking 31-bit code. They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and we've seen a few of those with Db2). You'll soon learn you're in the wrong addressing mode with a PIC38. Reset the 32nd bit before mode switching to 64 and you won't fail that way. You'll find one of the other prog 0004 interrupt codes. Regards, Dougie On Fri, 22 Nov 2019, 13:42 Joseph Reichman, wrote: > 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 basring a 31 bit pointer in amode 64 > > My fault I gave to slow down look at the doc before I send an e-mail :( > > > > Joe Reichman > 170-10 73 rd ave > Fresh meadows NY 11366 > > > On Nov 22, 2019, at 7:51 AM, Peter Relson wrote: > > > > 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 your module is not > reentrant. > > > > > > > > After loading I turn the 1 bit to the right off now I have a clean half > > address > > > > Perhaps you didn't do what you thought you did. > > > > > > when I BASR to it bombs and the PSW has the one bit on > > > > > > Show the symptom dump. Show the registers at the time of the error. Show > > the information from the program check. Show something... > > > > Peter Relson > > z/OS Core Technology Design >
Re: BASR to AMODE 64
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 basring a 31 bit pointer in amode 64 My fault I gave to slow down look at the doc before I send an e-mail :( Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Nov 22, 2019, at 7:51 AM, Peter Relson wrote: > > 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 your module is not reentrant. > > > > After loading I turn the 1 bit to the right off now I have a clean half > address > > Perhaps you didn't do what you thought you did. > > > when I BASR to it bombs and the PSW has the one bit on > > > Show the symptom dump. Show the registers at the time of the error. Show > the information from the program check. Show something... > > Peter Relson > z/OS Core Technology Design
Re: BASR to AMODE 64
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 your module is not reentrant. After loading I turn the 1 bit to the right off now I have a clean half address Perhaps you didn't do what you thought you did. when I BASR to it bombs and the PSW has the one bit on Show the symptom dump. Show the registers at the time of the error. Show the information from the program check. Show something... Peter Relson z/OS Core Technology Design
Re: BASR to AMODE 64
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 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 clearing it, the effect will > depend on what the caller had in it, which may well be different > in the TEST environment. > >> 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 thing under TEST making a breaking point at the basr it doesn't >> happen > > Jonathan Scott, HLASM > IBM UK, Hursley
Re: BASR to AMODE 64
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 clearing it, the effect will depend on what the caller had in it, which may well be different in the TEST environment. > 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 thing under TEST making a breaking point at the basr it doesn't > happen Jonathan Scott, HLASM IBM UK, Hursley
Re: BASR to AMODE 64
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 such > as: > Source code?Assembly listing?ABEND code?SysLog? > > Keven > > > > > > > > > > > > > On Thu, Nov 21, 2019 at 9:26 PM -0600, "Joe Reichman" < > reichman...@gmail.com> wrote: > > > > > > > > > > > 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 thing under TEST making a breaking point at the basr it doesn't > happen > > > > >
