Oppolzer - Informatik / Blog

There was a little misunderstanding on my part; I thought that R. suggested
the decrement by one should be done using a macro, which made no sense to me.

Of course, a macro which does the whole VARCHAR move makes much more sense.

But still: as J.G. pointed out, such a macro should offer many options,
to be useful in the special situations. For example, are the lengths of the
operands known at compile time or not, how to handle differing lengths (fill
with blanks etc., or leave the rest untouched). In some special situations, such
a commonly usable macro will probably generate some unnecessary instructions,
compared to hand coded machine instructions. You will probably have to pay for
the convenience.

On the other hand: the pattern

LTR Rx,Rx
IF (P)
BCTR Rx,0
EX Rx,MVCCMD
EIF

which I would normally use to handle the situation (if the VARCHAR is known to
be of length less than 256) does not seem enough complicated or error-prone to
me, that the use of a macro would be justified.

My error (BALR instead of BCTR) is an exception - that kind of error happened to
me only once in 30 years of ASSEMBLER experience, and I hope it will never
happen again. After the module containing this error was fixed in 1997, it ran
without modification until 2010, when it was serviced again due to a change
request by the customer.

Kind regards

Bernd


Am 12.02.2012 17:01, schrieb J.G.:
> Again, context is all.  Bernd's point,
>
> Man muss übrigens nicht mit Kanonen auf Spatzen schießen.
>
> is well taken (Bowdlerized, it is overkill to launch a torpedo at a
> canoe, even if you sink it.)
>
> Still, I do have a MOVECHRS macro that optimizes, generates MVC, MVC
> loops, MVCLE, etc., as appropriate.  In some situations I use it; in
> others I code an MVC; it all depends.
>
> For the situation under discussion, that of a (halfword current-length
> prefixed)  PL/I VARYING CHARACTER value, a test for a nul string, one
> of length zero, is clearly required, as it would be for a
> nul-delimited C string.  Moreover, that test needs to be in close
> proximity to the top of the loop.  The decision where exactly to put
> it would require examination of all of the code involved.  In some
> cases any competent person would take the same decision; in others
> not.
>
> On 2/13/12, R. wrote:
>> From: G.P.
>> Date: Sunday, 12 February 2012 13:45
>>
>>> On 2/12/2012 5:44 PM, R. wrote:
>>>> 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).
>>> You're drawing an unwarranted conclusion. It is quite possible
>>> that the length was tested earlier on in the code, and the
>>> author knows better than you that the BCTR is safe.
>> The programming world is littered with "it can't happen" cases.
>> Everyone knows Murphy's Law ("If anything can go wrong, it will").
>> But not many have heard of Robert's Law? ("Even if it can't go wrong, it
>> will".)
>>
>> So, even it the length were tested prior, one can't assume that all
>> will be well when the EX is reached.
>> The MVC can be destructive, and the only case where it isn't is when
>> the destination is of length 256.
>>
>> The intended use of BCTR suggests to me that the author has not allowed for
>> the
>> length being zero.
>>
>> What it also suggests to me that the code is not bulletproof.
>>
>> Setting up for a variable-length move (or compare) using EX
>> involves decrementing a length.  That is part and parcel of the move
>> (compare), and is best kept as a unit in order to avoid bugs.
>>
>> For such a routine operation as a variable move, a macro
>> would offer many advantages.
>>
>>
>
> --
> J.G.
>