Better (more formal, more thorough) MVCOS instruction test needed

[Fish-Git]

This issue is closely related to Issue #349.

---

Because the bug described in GitHub Issue #349 was triggered by the MVCOS instruction, it would be nice if we had a formal MVCOS instruction test that could be used to verify that it is now working properly (once a fix for it has been devised for it of course (which it hasn't yet)).  EDIT: issue was fixed by commit 7c686d5c59b671b2542a5280f24248b3e7c891b7

There is an existing manual test script called "mvcos.txt" in the tests subdirectory, but it appears to only test 2 specific variations of MVCOS (move from primary and move from secondary) and the #349 bug is triggered by an Access-register mode move, so it (mvcos.txt) can't by itself help us any in this particular case.

I'd like to have a more formal runtest quality assurance .tst test written that would, but unfortunately I'm lacking the necessary skills required to write access-register assembler code. My mainframe background was limited to simple System/370 page/segment table DAT. I never had the opportunity to acquire any experience writing AR mode code.   :(

Nevertheless, I shall try to take our existing mvcos.txt script and convert it to a more formal runtest .tst script instead (and maybe TRY to add an AR mode test too!), but if there's someone out there that actually has experience writing AR mode code that could help me out (or volunteer writing such a test themselves!), I'd be VERY grateful!

Thanks.

---

This issue is closely related to Issue #349.

[wably]

Hey Fish (@Fish-Git )

I'd be willing to take this on, as long as you are not in a hurry for it. It could be several weeks before I could get to it. And once started it will take quite a while to implement. Setting up the DAT blocks for multiple address spaces, the ASCEs, the DUCT access list and the Primary address space access list (the DU-AL and PASN-AL, respectively) is quite exacting and tedious. The access lists are what the ALET values inside the Access Registers refer to. Besides moving data between address spaces in the various access mode combinations, MVCOS also can take into account PSW keys vs. storage protection keys, further adding to the complexity by adding yet more combinations to be tested. So I could see that writing a full test suite would be quite a haul.

If you decide that you might like to try to do it yourself, I'd be happy to write up for you "an intro to AR mode programming", which would probably not be a ridiculous sized email. The programming is the easy part. But whoever does this, pouring over the minute and technical details in the Principles of Operation to set up the various control blocks previously mentioned will be the lengthy part.

If you want me to do it and are not needing it quick, you can assign it to me. If you care to try it yourself and need help, just ask.

Regards, Bob

[Fish-Git]

I'd be willing to take this on, as long as you are not in a hurry for it. It could be several weeks before I could get to it. And once started it will take quite a while to implement.

Thank you! That's fine. I'm in no real rush. I've already developed a (temporary quick) fix that gets us around the immediate problem, so at the moment, there's no immediate need for such a test.

I'm just trying to think long term here, that's all. Long term, we really should IMHO have some type of stand-alone quality assurance test (i.e. a Hercules runtest .tst) to more thoroughly test Hercules's address translation logic, and using the MVCOS instruction to do that seems to be just the ticket. It appears, by its very design, to be able to test virtually all architecturally available addressing modes, which sounds extremely handy IMO!

But as I said, it's not something we need RIGHT NOW! It's just something I would like to eventually have.

So if you want to take a stab at it, then YES! PLEASE! I would very much appreciate that!

Setting up the DAT blocks for multiple address spaces, the ASCEs, the DUCT access list and the Primary address space access list (the DU-AL and PASN-AL, respectively) is quite exacting and tedious. The access lists are what the ALET values inside the Access Registers refer to. Besides moving data between address spaces in the various access mode combinations, MVCOS also can take into account PSW keys vs. storage protection keys, further adding to the complexity by adding yet more combinations to be tested. So I could see that writing a full test suite would be quite a haul.

Indeed! Which is why I added the "Help" label to this GitHub Issue: I don't believe I'm qualified for such an endeavor. I don't have the knowledge or skills. Hence the plea for help from someone who feels they do have the required skills.

If you decide that you might like to try to do it yourself, I'd be happy to write up for you "an intro to AR mode programming", which would probably not be a ridiculous sized email.

Without committing to trying to tackle this endeavor myself, I would nevertheless be very interested in such a write up! Thank you! I'm always interested in trying to learn new things. Especially new mainframe things as it relates to Hercules.   :)

If you want me to do it and are not needing it quick, you can assign it to me.

Done!

If you care to try it yourself and need help, just ask.

Can I ask questions anyway even if I don't try doing it myself?   ;-)

Thanks, Bob! You're a pal.

[wably]

Fish (@Fish-Git ),

Here is my write-up to introduce AR mode programming:

• ARMODE.pdf

It is a little longer than I expected but still only 5 pages. There is also a reference for more information at the end.

In order to remember this stuff, I'd recommend you dink around with it a bit and try to execute a few instructions and see the results. You could use the existing MVCOS test case, which already has the DAT tables for three address spaces. By altering that test slightly, you could use ALETs 0, 1 and 2 for those spaces and switch into AR mode and try to execute various instructions as you desire in order to see the execution results. After you read the Intro document of course! Good luck.

Regards, Bob

[Peter-J-Jansen]

Thanks Bob,

A most useful read for me!

Cheers, and a Merry Christmas to All

Peter

[Fish-Git]

Thanks, Bob! I'll give it a read ASAP. Can't say how soon I'll be able to dink around, but I will definitely do that when I get the time. It's a great way to learn. Thanks again for offering to write the new/improved MVCOS test. I think it will help us a lot. Take care!

[Fish-Git]

FYI:  In your closing "Recommended Further Reading" remarks, you recommended downloading and reading Chapter 5 of the manual "z/OS Extended Addressability Guide", SA22-7614.

However, after searching for it by that publication number and not being able to find it, I then searched for "z-OS Programming Extended Addressability Guide" and found:

• SA23-1394-40: "z/OS V2R4 MVS Programming - Extended Addressability Guide"

which appears to be the most current version of the same thing. Just wanted to pass that on.

Anyway, thanks again for your write-up! Like Peter I too found it to be a very useful read! VERY helpful! Thanks!

[wably]

Sorry. The copy of this manual that I had on hand was for z/OS 1.13. I didn't anticipate that the publication number might have changed.

[wably]

Hey Fish (@Fish-Git ),

I've been thinking about this test suite for MVCOS and getting re-familiarized with the instruction itself. There is a slew of individual bits in register 0 that control this instruction's behavior, plus slightly different behavior depending on the length moved, problem state or supervisor state, and more. What I am getting at is that this is a large number of combinations to test every possibility. For example, just the address space control bits in R0 gives 4 possible tests, but you can also opt to use the PSW address space control setting instead of R0's bits, so its really 5 tests. And that's just for operand 1. You can do the same for operand 2. So that's 5 times 5 tests for each possible other bit setting, key setting, or state setting, and so on. To the point, it looks to be something greater than 1024 possible tests. This high number does not lend itself well to coding the runtest conditions of 'want this', 'got that', which is a manual process setting those up. So, I see two other choices.

One choice would be to create a giant looping repeating test suite that does MVCOS one at a time for each possible address space and control bit setting, and if the total test loop succeeds then that is a single runtest want/got satisfied (even though perhaps 1000 or more tests were run). A big disadvantage would be if it fails, then trying to find out why - especially if someone else is looking at the test suite code. But it would cover every case.

The other choice is is to do a representative sampling of relevant tests that exercise core functions. For example do two tests that operate on the length variation and establish that it works. Then do a few tests that use storage keys or PSW keys and establish that it works, not involving any further length or address space variations. Then perhaps a test for each address space mode in both directions, perhaps a few with keys enabled and a few not. This could keep the number of tests to a bearable level, perhaps 20-25 tests maybe. Each one could be a want/got runtest 'official' test with a results line. Its easier to see and find the failure if there is one. The downside is that there is always the remote possibility that for example and hypothetically, when the K bit in R0 is one and you are in Home space mode that MVCOS didn't honor the storage key as it should. Then this kind of error in the MVCOS emulation code might be missed because that combination was never tested. Or some other weird arrangement like that.

Do you have a preference here? A complete and total test that is more complex but hard to debug in the event of a future failure, or a smaller but targeted test suite?

Regards, Bob

[Fish-Git]

How about both?   ;-)

Seriously!

Do your second suggestion (quick test) to verify nothing is obviously broken, and then do the more thorough all-possible(?) combinations test afterwards.

I should add that (and please correct me if I'm wrong!) your major concern seems to be centered around having to code many, many runtest script *Want xxx + r xxx statements. Yes? If so, might I suggest that you NOT do it that way, and instead simply verify each individual test's results from within your test code itself?

I'm thinking something table driven, along the lines of my CLCL-et-al.asm test (but done better!), wherein you design a table containing the various hard coded test parameters/flags and expected results for each test, along with a simple function to processes each table entry (i.e. performs each test), verifying the correct expected results afterwards.

As each test is started, you move the "test number" (and perhaps "subtest" number, depending on how you design it) to a field at a fixed location, and abort as soon as you detect any unexpected result.

The .tst runtest script then reduces to a single *Want, with the "want" value being the a "test/subtest" value of all zeros. Anything other than all zeros would indicate a failure, with the "test/subtest" field identifying exactly which test it was that failed.  <shrug>

Does that sound doable?

Because in all honesty, I would really, really, REALLY like to have as thorough of a test as possible. I suspect we might have some type of subtle bug in our ART logic somewhere, that only occurs under specific unusual/uncommon situations (see e.g. OPTION_SIE_PURGE_DAT_ALWAYS, which is a bodge/kludge to workaround an unknown problem we were having with DAT/ART).

So I'd really like to have as thorough a test as possible if possible, and hopefully the suggestions I've made above might help to make things easier for you.

I realize that's asking a lot and recognize how easy it is for me to sit here and "demand" something when I don't have to do any of the work involved. I'm not blind to that, and I'm NOT trying to be bossy or anything. I'm NOT the boss here. NONE of us are. I'm NOT trying to hand out work assignments or anything. That's not my job. We're all our OWN bosses. We take orders from no one but OURSELVES. We each do what we want. This is an all volunteer effort.

But if you could find it in your heart....   :)

[wably]

Fish,

I should add that (and please correct me if I'm wrong!) your major concern seems to be centered around having to code many, many runtest script *Want xxx + r xxx statements. Yes?

Yes, that was my concern. Since you are ok with checking the results internally and just having a single *want, then I will go that route.

Therefore, I will pursue the full test suite that checks every combination. It will likely be table driven and I will be sure to leave tracks internally so we'll know what test failed and have all the currently in effect values and registers. I also want to have deliberate failure tests, for example to make sure a PIC 4 is issued on a storage key mismatch, and stuff like that.

I realize that's asking a lot and recognize how easy it is for me to sit here and "demand" something when I don't have to do any of the work involved. I'm not blind to that, and I'm NOT trying to be bossy or anything. I'm NOT the boss here. NONE of us are. I'm NOT trying to hand out work assignments or anything. That's not my job. We're all our OWN bosses. We take orders from no one but OURSELVES. We each do what we want. This is an all volunteer effort.

I understand all of that. Its not a problem. In fact that was the reason I asked about what you wanted just to make sure we're on the same page. Its easier to do that first than not meet the expectation and have to fix it or adjust it later.

Regards, Bob

[Fish-Git]

Cool.   :)

[Fish-Git]

Just checking in to see how it's going.

[wably]

I set this aside for a while waiting for your fix to MVCOS but after your successful patch I can now continue. I've completed all of the supervisor-state tests and now need to add the problem-state tests and manipulate the PKM. And I need to add all of the block comments and test/use details into it. I'd say I'm probably ~70% complete.

[wably]

Tests added by commit 4ab568c6932cf1be854ba99ed9445449452f4753 and 3592c976859d2260837c6db4e76d3c66f2a6e58f