When using Program Event Recording (PER) to trap general register alteration events, Hyperion does not provide a program check PER interruption when register alteration is selected in the PER event mask. Other PER events, such as instruction fetch, do provide the proper program check interruptions as expected.
This has implications for VM users. VM uses PER to facilitate tracing and stepping in virtual machines, including VM/370 with the Waterloo PER package installed. That's when I noticed that PER G was not triggering on any register alteration.
To track this down further and eliminate the possibility of a bug in the Waterloo PER code, or in CP, I simply reduced some PER tests to the bare minimum and placed them into short scripts that can be run from the Hercules console to recreate the problem.
The first script is "perif.txt". It loads the control registers for a PER instruction fetch test. If PER triggers, the program check new PSW is loaded with a disabled wait code 1. This works as expected and demonstrates that the emulator does provide PER interruptions, and that I have the script set up correctly, and that the PER Control Registers 9-11 are correct. The script sets you up in single step mode, and after the execution of the fourth instruction, the PER interruption occurs as expected.
The second script is "perg.txt" and this demonstrates the problem. It uses the exact same code as the first script, except that CR 9 is slightly different to instead set up a register alteration PER event instead of instruction fetch. It's an easy verification to check a S/370 yellow card to see that CR 9 is set up correctly in the script (at location 2F0). In any case, PER should trigger a program check interruption after the fourth instruction (when GR 5 is modified by a BALR 5,0), but it does not. Two instructions later R6 is modified and it also does not trigger.
When using Program Event Recording (PER) to trap general register alteration events, Hyperion does not provide a program check PER interruption when register alteration is selected in the PER event mask. Other PER events, such as instruction fetch, do provide the proper program check interruptions as expected.
This has implications for VM users. VM uses PER to facilitate tracing and stepping in virtual machines, including VM/370 with the Waterloo PER package installed. That's when I noticed that PER G was not triggering on any register alteration.
To track this down further and eliminate the possibility of a bug in the Waterloo PER code, or in CP, I simply reduced some PER tests to the bare minimum and placed them into short scripts that can be run from the Hercules console to recreate the problem.
The first script is "perif.txt". It loads the control registers for a PER instruction fetch test. If PER triggers, the program check new PSW is loaded with a disabled wait code 1. This works as expected and demonstrates that the emulator does provide PER interruptions, and that I have the script set up correctly, and that the PER Control Registers 9-11 are correct. The script sets you up in single step mode, and after the execution of the fourth instruction, the PER interruption occurs as expected.
The second script is "perg.txt" and this demonstrates the problem. It uses the exact same code as the first script, except that CR 9 is slightly different to instead set up a register alteration PER event instead of instruction fetch. It's an easy verification to check a S/370 yellow card to see that CR 9 is set up correctly in the script (at location 2F0). In any case, PER should trigger a program check interruption after the fourth instruction (when GR 5 is modified by a BALR 5,0), but it does not. Two instructions later R6 is modified and it also does not trigger.
Regards, Bob
perif.txt perg.txt