Some issues are easier to deal with by non-technical methods. Publicizing the paragraph that precedes the code might demonstrate the desirability of following the rules to all but the most obnoxious.
Has your legal team considered the possibility of industrial sabotage? It would be pretty hard to argue that this defective code was accidental. > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > l...@listserv.uga.edu] On Behalf Of Ed Jaffe > Sent: Monday, October 09, 2017 9:22 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Detection of Compile-Time Self-Modifying Code > > 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. 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.) > > It might be nice if the assembler could generate an error or warning > message if an instruction is modified at compile time.
