Oppolzer - Informatik / Blog

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 R.
> From: Bernd Oppolzer<bernd.oppolzer@t-online.de>
> Date: Saturday, 11 February 2012 3:36
>
>
>> My 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).
>
>