Pat I think you're correct; it's a matter of style. Probably the programmer is abiding by some sort of house rule that says if you can't rely upon the referenced variables to provide the correct length then use the length attribute in order to show the relationship between the length of the referenced variable and the desired length by using a plus or a minus and a constant. Where you have an MVC and a literal, it looks a bit stupid but a house rule is a house rule. It's my opinion that a simple number suffices because the length of the literal is obviously the length that has to be used and it's right there in front of you. When the same house rule is applied to the UNPK instruction it makes more sense because it helps to describe/explain the fiddle that's being performed.
And you're right again, this use of the length attribute is the sort of technique you are more likely to need in a macro where you are having to adjust to the macro parameters. In this case, I guess you'd have three parameters: the destination field, the source field and the mask. The first point is that I'd insist that the destination field allowed for the "fill byte" since "writing" outside your defined field is really something of a "no-no". Then it would be possible to check that the destination field was the size of the mask - or - the user of the macro would be expected to know that the full mask was used so the generated code would always use the length of the mask as the length to move. Finally, if it was really a fancy macro, it might verify that the source field, assumed to be in packed decimal format, was capable of satisfying the selection bytes in the mask field. Naturally the field would need to be specified in such a manner that it could be analysed using macro logic, simply string of hexadecimal numbers, for example. I used to do stuff like this years ago - for fun. <g> I found macro language quite a good preparation for text processing languages such as, eventually, REXX. I think I saw a post in this thread fly by which said that this whole discussion (a) belonged in the Assembler list - which, given the title - is right and was (b), in any case, tedious, which is also a matter of opinion. Nevertheless the post in question went on to espouse the "house style" idea and perhaps was intended to be the last word on the subject. Chris Mason ----- Original Message ----- From: "Patrick O'Keefe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, 06 November, 2006 10:01 PM Subject: Re: Assembler question > On Mon, 6 Nov 2006 13:37:50 +0100, Chris Mason <[EMAIL PROTECTED]> > wrote: > > >... > >I was commenting on the following instruction: > > > > MVC M1CC-1(L'M1CC+1),=X'402120202020' MOVE IN EDIT MASK > >... > >The task is to move a 6-character string into a storage area. There needs > to > >be some symbolic reference to the storage area so the M1CC variable is > used. > >... > > I'm afraid I don't understand what the issue is. Seems to be a matter of > style. I see the task as moving a edit mask into a field that starts one > byte prior to M1CC and extends to the end of M1CC. I have to build the > mask so have to know that the length is 6 but M1CC-1(L'M1CC+1)explains > why it is 6. Is that bad? > > Actually, if I had to do that more than once or twice I'd probably write > a macro that builds both the MVC and the mask, and would (hopefully) > comment it well enough that a neophyte would understand. > > Pat O'Keefe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
