The length in R3 was the length of a CHAR VARYING passed as a parameter, and it was tested to be positive and not zero before issuing the BCTR (was BALR, should be BCTR).
In fact, I believe that BCTR Rx,0 is the most natural choice to do the length reduction by one before issuing an EXed MVC, because there is no need to access memory to fetch a literal etc. At least before AHI. AHI is 4 bytes, BCTR only 2. The whole episode was in 1997, and the hardware we used then did probably not have AHI. To use a macro to do this seems like "Kanonen auf Spatzen" to me (I hope you understand this German idiom). Kind regards Bernd Am 12.02.2012 23:44, schrieb robin:
From: Bernd Oppolzer<[email protected]> Date: Saturday, 11 February 2012 3:36My favourite one is: BALR R3,0 SUBTRACT 1 FROM R3 Obviously, the opcode is wrong, should be BCTR. But: it took me three months (!!!) to find the error, because I always looked at the comment - at least 20 times - and never realized that the operation did something totally different than the subtraction suggested by the comment. This was a length calculation before an EXed MVC, and the program crashed sometimes due to the wrong length - but not always. The testers told me over and over again, that there must be something wrong with this module, but I simply didn't realize it.Macros provide the means to automate common tasks and avoid mistakes like that. In this case, BCTR is inappropriate, because the length can be zero, and use of SH provides the means to test for negative and to skip the MVC (or CLC).
