On 4 June 2018 at 12:58, Seymour J Metz <[email protected]> wrote: > PER uses program interrupts, not an SVC.
To say PER "uses" program interrupts is of course true, but sounds slightly odd. PER interrupts are a specific subclass of program interrupts that can occur concurrently with "normal" ones; it's very different from debuggers that insert an invalid opcode in order to produce a program interrupt. > That said, calling an SVC does not normally alter R14; the SVC would have to > do something unusual. > Paul Gilmartin <[email protected]> wrote: >> How does PER work? I believe it's nondisruptive. And I believe VM gives the >> end user control over PER. Yes. VM does. And because virtualization is so cool, you can have virtual PER events taking place within z/OS while "real" PER events within z/OS (or of course other guests) are being handled by z/VM. All for some values of "virtual" and "real". And z/OS could surely have something like VM/s PER-using commands, but it has chosen to give ownership of PER to SLIP, which makes for a very poor debugger. A privileged program could easily enough set up PER on its own, but catching and handling any resulting interrupts without seriously annoying SLIP would be the trick. Is there an interface to SLIP to tell it that someone else is using PER too, I wonder. Is anyone here old enough to remember DSS (the MVS Dynamic Support System), which was a system level debugger that predates SLIP? *It* used to own PER, but I believe it was removed in MVS 3.6 or so. There are one or two remnants of it in current control blocks. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
