Really amazing! Anyway, take the DUMP and check the 2048. KEY. Are you under a VM or something similar?"
El vie, 1 ago 2025 a las 19:08, Philippe Leite (< 0000086a789d3d38-dmarc-requ...@listserv.ua.edu>) escribió: > It doesn't matter if CR0 bit 38 is on or off in this case. If this bit is > on, It only allows read access to address 0-2047. The PSA part 2048-4095 is > ALWAYS protected. This is expected. > The problem I'm facing is that I can view the protected PSA part 2048-4095 > when I'm in a z/OS 3.1 on a z14. > > When I run a simple program (User key 8) like this: > > psatest csect > psatest amode 31 > psatest rmode any > bakr r14,r0 > lr r12,r15 > using psatest,r12 > l r15,2048 > xr r15,r15 > pr > end psatest > > - On z/OS 3.1 running on a z15 this program ABEND S0C4-4 -> This is the > expected result. > - On z/OS 3.1 running on a z14 this program executes normally. -> This is > NOT the expected result !! > > > > On Fri, Aug 1, 2025 at 1:23 PM salva <sa...@rczero.com> wrote: > > > At the very least, take the dumps and compare bit 38 of CR0. > > > > El vie, 1 ago 2025 a las 18:09, Philippe Leite (< > > 0000086a789d3d38-dmarc-requ...@listserv.ua.edu>) escribió: > > > > > As I said to Rob, I already knew this POP rule for a long time, but it > > > doesn't answer this situation I'm facing. > > > It's exactly the same z/OS 3.1 version (same source and PTF level) but > > it's > > > working differently on a z14 and z15. > > > > > > Philippe Leite > > > z/OS System Programmer > > > > > > On Fri, Aug 1, 2025 at 1:04 PM salva <sa...@rczero.com> wrote: > > > > > > > From the POP: > > > > > > > > "Fetch-Protection-Override Control > > > > Bit 38 of control register 0 is the fetch-protection- > > > > override control. When the bit is one, key-controlled > > > > fetch protection is ignored for locations at effective > > > > addresses 0-2047." > > > > > > > > I don't know why it's different in your cases. > > > > > > > > El vie, 1 ago 2025 a las 16:40, Philippe Leite (< > > > > 0000086a789d3d38-dmarc-requ...@listserv.ua.edu>) escribió: > > > > > > > > > Interestingly, I am experiencing the same situation here. > > > > > In an LPAR running z/OS 3.1 on a z14, when I send the command “TSO > > > ISRDDN > > > > > B 800.”, I can view the contents of PSA 2048-4095. > > > > > But when I am in another LPAR with the same z/OS 3.1 on a z15, the > > same > > > > > command “TSO ISRDDN B 800.” shows me an error message “Storage > > > > unavailable.” > > > > > > > > > > > > > > > Philippe Leite > > > > > z/OS System Programmer > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > 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 > > > > ---------------------------------------------------------------------- > 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
