Very much a newcomer here but have been following this discussion with interest, and appreciate both sides of the discussion, but I don't think the program should be updated.
If it WAS, and tomorrow (somehow) you stumbled across an old 1980's era mainframe in a barn, you should be able to install and run MVS 3.8j on it. If this program were updated to use the TPROT instruction, that wouldn't work.
I don't know how many instructions there are, or when new instructions were added, but it would be pretty cool if (say) Hercules could be started to run with the 01-May-1980 CPU instruction set, 01-July-1990 CPU instruction set, etc.
doug
toggle quoted message
Show quoted text
On 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@...
