Considering IBM's practicing of OCO (if that was in place at the time of that APAR's release?), why would IEFBR14 have needed an APAR to add equates? Equates or no equates, the object code would have remained the same; 1BFF 07FE. It's a source code thing only.
The addition of setting the return code however, did add 2 bytes to the object code, and thus would have warranted an APAR/PTF. Pedant that I am; the second instruction is, per the PoP, "BCR 15,14". BR, BNZ, BZ, BNE, ... are shorthand for BCR with its different condition code masks, but are not instructions themselves. Regards, Jan >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of Mike Myers >Sent: donderdag 11 februari 2016 2:12 >To: [email protected] >Subject: Re: AW: Re: You thought IEFBR14 was bad? Try GNU's /bin/true code > >Robert and all: > >To set the record straight, I looked at the object code, which is: >1BFF07FE, or > SR 15,15 > BR 14 > >I believe the second APAR was the addition of equates for R14 and R15 >and to change the code to > SR R15,R15 > BR R14 > > because the former failed to meet programming standards. > >Mike Myers >Mentor Services Corporation ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
