On 2017-10-09, at 22:21, Ed Jaffe wrote: > Like most ISVs writing HLASM code, we use OPTABLE to ensure our programmers > don't accidentally use instructions that aren't available on older machines > that we must still support. > > Currently, we're using OPTABLE(YOP) because our minimum supported OS is z/OS > 1.12. (It's not until z/OS 2.1 that we can leap ahead to the z9 machines.) > > We recently terminated a reckless/destructive/rogue/cowboy programmer who > would routinely and subversively insert "land mines" into our code without > anyone knowing. Someone found another one this week: > > | DO UNTIL=NO Until all chars processed > | * Until we break free from OPTABLE(YOP), the ORG game must be used > | TROT R14,R2 Convert to hex > | ORG *-2 ORG back to set M3 field > | DC X'10' M3 = 1 to suppress stopper > | ORG , ORG back > | ENDDO , EndDo TROT > > Obviously, the right way to code this would have been to use ACONTROL OPTABLE > with surrounding PUSH/POP to get the newer TROT function. ... > Why would that be right? It's still inserting an instruction unsupported at a hardware level you intend to support. Or is it dual-path at execution time?
> ... But, doing so could raise the visibility of the sabotage to the level > where someone might notice. So, he chose to alter the instruction via ORG/DC. > (IMHO, ORGing back to change an instruction is a form of self-modifying code, > which we don't allow.) > Suppose he coded the whole thing in hex? You should probably prohibit that also. > It might be nice if the assembler could generate an error or warning message > if an instruction is modified at compile time. > Does HLASM know whether you're changing an instruction or data? Should it simply notify of all negative ORGs? -- gil
