I was trying to implement the trap instruction I located the duct at first via STCBDUCV and when that didn’t work I tried control register 2
I had the trap control block at offset 2C from the duct with bit 0 turned on The trap program was at off set x’14’ in the trap control block the save area was the trap save area was at offset x’0C’ All storage was from subpool 252 on a page boundary Joe Reichman On Thu, Feb 6, 2025 at 6:48 PM Peter Relson < 0000056a472f7cb4-dmarc-requ...@listserv.ua.edu> wrote: > Did the OP ever determine/explain why he got PIC 4 while in key 0? The > only architectural case that comes to mind of this happening is if the > store is into DAT-protected storage (think PGSER PROTECT, such as for the > read-only nucleus or for PLPA). And that likely means that the wrong > address was used for an attempted store operation. > Looking at the time of error PSW (to understand the failing instruction) > and the regs and what the regs pointed at would have allowed the OP to do > this simple diagnosis himself, as surely he should be expected to be able > to do. > TCBPKF has nothing to do with the "issue". It does have to do, for > example, with what key you get back to with something like MODESET KEY=PROB. > > By the away, I disagree strongly with Shmuel's thought that it was a bad > idea to have 0C4 with reason codes rather than unique completion codes for > every program interrupt. It is hardly a hardship to have to work with > abend/completion code and abend reason code as a "pair", although I'll > grant that there are some messages that display only the abend/completion > code, instead of the abend/completion code and abend reason code, and that > is not nice (and hasn't been nice since abend reason codes were introduced > decades ago). And I'll bet that the use of reason codes for 0C4 led to a > bunch of code never having to be changed with the introduction of PIC 10 > and PIC 11 (and the 64-bit virtual PICs) because that code looked simply > for 0C4 as "my data address is not appropriate" (very little code would > have wanted to get the fine level of detail of "my data address is not > appropriate because I do not have read/write access). > > Peter Relsonz/OS Core Technology Design (retired) > > ---------------------------------------------------------------------- > 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
