On May 27, 2012, at 01:11, Paul Gilmartin wrote:
>
> On May 27, 2012, at 00:18, Jon Perryman wrote:
>
>> I think that John is asking for an example where the existing BIF's do not
>> satisfy your situation and what length would expect it to return.
>>
> Largely, I was puzzled by the complexity of John's solution:
>
> Macro
> &Lab MVC2 &Target,&Source
> &Lab CLC 0(0,0),&Source X'D500 0000',S(&Source)
> Org *-6 Back up to first byte of instruction
> LA 0,&Target.(0) X'4100',S(&Target),S(&Source)
> Org *-4 Back up to first byte of instruction
> DC AL1(X'D2',L'&Source-1) First 2 bytes of instruction
> Org *+4 Step to next instruction
>
> ... What's accomplished by overwriting the instruction 3 times,
> and using a hex opcode? (And I believe this would allow modifying
> the literal pool which we agree is a Bad Thing. Safer to use ST
> in place of the LA.)
>
> AIF (L'&Target ge L'&Source).Done
> MNote *,'MVC2: Length of ''&Source'' greater than length of ''&*
> Target''.'
> .Done MEnd
>
Oops. I (and perhaps others) overlooked the possibility that
the target could be coded explicitly as D1(,B1). This is likely
if the programmer is building an output record piecemeal. So
(Mansell's solution):
MACRO
&L SS2 &OP,&A1,&A2
&L &OP &A1,&A2
ORG *-5
DC AL1(L'&A2-1) Overlay target length.
ORG *+4
MEND
In the D1(,B1) case, the length check is pointless, likely harmful.
And the programmer might want an enhanced version that increments
the base register by the length of the source operand. There are
enough variants that macros which handle each well are preferable
to an enhancement to HLASM which might deal with only one of them.
-- gil
