Tom Regarding the more substantive point, we'll have to agree to disagree.
When you changed the instruction similar to MVC M1CC-1(L'M1CC+1),=X'402120202020' MOVE IN EDIT MASK you needed to recode the literal and, in doing so, you were very much aware of the length of the literal . Thus you could have specified the length in the instruction - and anyone looking at it would be more the wiser over what was going on - in my opinion. I would never code an address reference with a negative offset like this so I have no experience of the expressions of this type - maybe I've missed something all these years. However defining a field and then operating outside its bounds looks like a recipe for disaster - again only in my opinion. I am not suggesting that the Assembler should use the length of the literal as the length for the MVC as I clearly say that I expect "6" to be coded. Maybe the Assembler could spot that a literal was being used and that the length of the literal was not the value used in the instruction. If I were asked I could support a "warning" message in such circumstances. Maybe I'm being thick but I can't see where specifying a length attribute would ever be considered for the instruction MVC M1CC,=X'402120202020' MOVE IN EDIT MASK Regarding the length used in the instruction not being the length of the literal: - If the length in the instruction was *less*, this would possibly be just about sensible if the programmer was aware that the same literal was used elsewhere and so space would be conserved when the Assembler came to ORGanising the LiTerals (LTORG)[1]. - If the length in the instruction was *more*, this is where the stupidity comes in. Here you would be relying on the desired data being in a following literal that happened to be "organised" there. At least if this were so, the data would be something the programmer coded as a literal instead of who knows what. Probably this was so ridiculous an idea that you didn't see it at all. I can understand that - although I've obviously failed my challenge. <g> I hope you recall that the OP was taking code samples while not necessarily understanding what was going on. I believe that the OP probably found L'M1CC+1 - and also M1CC-1 - a bit outside what she heard about on her basic Assembler course[2] and my contention is that L'M1CC+1 was unnecessarily complicated and did not contribute to understanding - but that's just my opinion. [1] Personally - almost for aesthetic reasons - I have never liked literals. I much prefer defining all my constants and "organising" them myself. This way I can spot economies. Probably it's all a result of being "brought up" with Assembler using Model 30s with limited storage above the Supervisor and so that being economical was inbred - in tune with an "eat everything that's on your plate" upbringing. [2] I know I didn't learn about attributes and the like until I got myself interested in basic macro writing - sufficient to write a "sysgen" package involving sorting parameters in a sublist - what fun! - Now the less substantive point: You are invited to go through past exchanges I have had with Shmuel. There you will find a record of refusals to understand often by means of his trademark "No.". Some think this is a good technique in order to persuade the person on the receiving end of the "No" to go and "look it up". That may be appropriate when it comes to topics I don't know about - obviously not my posts - but when it concerns topics I do know about in my posts it's just exhausting - and time must be expended explaining why/how he has misunderstood or maybe is plain wrong - and a nose is penetrated - especially when red herrings are offered as merchandise. If you are going to be contrary in my opinion - just my opinion - you should make an effort to see the issue from the point of view of whomever you are contradicting and provide a suitable explanation - even if it is straight out of the manual - maybe a manual reference will do - although sometimes you just know that will not be sufficient. Actually if Shmuel had bothered to check the manual for his third "negative", he'd have discovered it didn't warrant a negative. If complaining can change behaviour, then the complaint was necessary. If it is unlikely that complaining - including implied complaints - will change behaviour then it's true the complaint is "unnecessary". So, regarding the less substantive point, we happen to agree! Chris Mason ----- Original Message ----- From: "Tom Marchant" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Monday, 06 November, 2006 2:42 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 > >I will now make my point "in words of one syllable" so it cannot be >misunderstood. Now there's a challenge. Unnecessary personal attack > >The task is to move a 6-character string into a storage area.... > >What I am taking issue with is going to the trouble of using a symbolic >expression for the length. That is, the use of the length attribute - albeit >modified because of the fancy footwork with the starting location - when the >instruction contains a literal which necessarily indicates the length. Are you saying that the assembler should be using the length of the literal for the length to move? Perhaps it would be nice if the assembler would flag the statement (as a warning) if the length that was used didn't match the literal. Would you have objected to the use of the length attribute if M1CC was a 6 byte field and it was coded as follows? MVC M1CC,=X'402120202020' MOVE IN EDIT MASK >And, >being a literal, it would be crass stupidity to be relying on data in a >following field in the case that the length used by the instruction didn't >precisely match the length of the literal. Maybe you'll think I'm stupid too. I've read the last sentence five times and I still don't understand what you're trying to say. >Sure, the Assembler uses the >length of the first operand if it is not specified explicitly but that's >not what I consider stupid. What I consider stupid is that the number 6, >consisting of one simple character, was not specified but something which >the Assembler has to work out is 6, consisting of 8 complicated characters. 8 complicated characters? L'M1CC+1? Complicated? Not to an assembler programmer. Indeed, I think it is as clear as can be, especially given the context of M1CC-1(L'M1CC+1). To me, the use of the length attribute is far preferable. >I'm not complaining on behalf of the Assembler, of course, but on behalf of >anyone looking at the source coding in times to come who will be slowed down >trying to work out what subtle benefit there might be in using "the length >attribute of M1CC + 1" rather than simply specifying "6". There is no >benefit; it's just stupid. I disagree. It is not stupid at all. I say that as someone who has recently had to modify some similar code to convert larger values to hex. Tom Marchant ---------------------------------------------------------------------- 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
