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@...
