开云体育

"But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem)."

Au contraire, mon ami poissonneux!

They "changed" it to TRY to use a TPROT first ... but if the TPROT would cause either a paging or translation exception, they still used compare and swap...

"If the TPROT instruction condition code indicates that a page or segment translation exception was encountered, the following processing?is?done:

• A recovery routine (FRR)?is?established to intercept any program checks

• The protection key?is?switched to the selected input protection key

• A compare and swap instruction?is?used to validate the storage area."

Joe

On Sat, Oct 29, 2022 at 11:28 PM Fish Fish <david.b.trout@...> wrote:

Joe Monk wrote:
> Tony Harminc wrote:

[...]
> > I really don't see that it's a bug. Maybe a less than ideal
> > implementation, but who's to judge that?
>
> Well, when it was implemented it was the only way!
>
>? ? ?MODULE NAME? ? ? = IEAVEVAL
>? ? ?CSECT NAME? ? ? ?= IEAVEVAL
>? ? ?DESCRIPTIVE NAME = VALIDITY CHECK
>? ? ?COPYRIGHT? ? ? ? = N/A
>? ? ?STATUS? ? ? ? ? ?= VS2-RELEASE2
>
> As we can see, it was implemented in OS/VS2 release 2. Long
> before MVS 3.8J and the TPROT instruction...

Yes, I can see that, and I can certainly understand it as well. As you say Joe, at the time, it was the *only* way it could be done, and thus cannot *technically* be classified (considered) as a bug. I agree 100% with that.

But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem).

If using 'CS' instead of 'TPROT' isn't (wasn't / shouldn't be considered) a bug, then why did they feel the need to "fix" (change) it in later versions? Why didn't they simply leave well enough alone? After all, if it ain't broke, don't fix it! Right?

If the version of MVS that's being used (3.8j) was only being run on the same/similar hardware that it originally ran on where the 'TPROT' instruction wasn't available, then it makes sense leaving it alone, as-is. But it's not. It's being run on "newer hardware" (Hercules) where the 'TPROT' instruction *is* available, thereby rendering what WAS "the proper/only way to do it" into "the improper way to do it for the hardware we're ALWAYS going to be running on".

I still say it's something that should be fixed.

I'll gladly retract my "bug" claim, but I'm NOT going to change my stance regarding it being something that SHOULD (IMHO) be fixed (changed).

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...