Shmuel You may have committed yourself to the rather rude intention not to read any reply but there may be some who are interested in the few responses worth making. Naturally, for the rest, especially the points where you refuse to understand, I disagree without reservation - but that's to be expected. One common tendency I can see in your refusal to understand is a persistence in assuming I'm talking about the Assembler's ability to understand when I so very clearly mean the person reading the code. This is perverse because I remember, even if you refuse to, that you chastised the OP for using code she did not understand.[1]
Selected comments are embedded. Chris Mason ----- Original Message ----- From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Thursday, 09 November, 2006 5:17 PM Subject: Re: Assembler question > In <[EMAIL PROTECTED]>, on 11/06/2006 > at 01:37 PM, Chris Mason <[EMAIL PROTECTED]> said: > > ... > > What is clear is that you are a pompous ignoramus with delusions of > adequacy. I wasn't sure about Phil's criticism but now I am and I trust all those who took issue with Phil over his criticism will now withdraw their censure. He was spot on. > ... > > ... The fact that it {an UNPK instruction} > is also useful for binary to hex conversions is gravy. Just occasionally you come up with something which shows there's hope and contributes to the point I was trying to make. "Gravy" or "cream on the cake" - but mixing these metaphors ends up with something less than appetising! > ... I'll indulge myself by pointing out the most blatant blind spot misunderstanding: > > >we have the messy "+1" in the length fields > > All of the SS instructions have lengths offset by one. That allows you > to specify larger lengths, at the cost of not being able to specify a > length of zero. You must be the only person still bothering to read who imagined I was taking about how the instruction worked rather than how it was coded. Here's actually your instruction again - corrected with the part you - I will charitably assume by accident - missed out in the post where you introduced it[1]: UNPK HEXWORK(L'HEXWORK+1),BINWORK(L'BINWORK+1) ** ** By copying the two lines above into a text file and setting a non-proportional font you will be able to see to which "+1"s I was referring. > ... > > >Now isn't it blindingly obvious that there's a bit of > >anthropomorphising going on here, a familiar dodge for someone > >attempting to teach in a picturesque way? > > Yes, almost as blindingly obvious as the programming errors that such > anthropomorphisms invariably lead to. But you knew that. Many years ago, before the mechanism was changed, I found that I was able to explain the way NCP handled element addresses when performing dynamic reconfiguration by using an analogy with swimming trunks. I dare say I could reconstruct the idea if I really wanted to but, since the mechanism was changed from something which was nowhere near intuitive to one - with the help of VTAM as I recall - which was just about intuitive, it's not worth the bother. The point is however that my anthropomorphic explanation gave the students a chance to know how to make a good estimate of the NCP BUILD statement RESOEXT[2] operand. Thus, quite the contrary, an anthropomorphic explanation can lead to programming success - even if I need ancient NCP macros to illustrate the point! > ... > > >Here is some text and a table > > How about quoting instead the text from the decimal instructions as to > which signs they are capable of generating? Or would that damage the > point that you are ineptly trying to make? I quoted from that part of the current Principles of Operation which supported very precisely the point I wanted to make. My point was *not* what sign half-byte codes packed instructions generated, "wrote", but what sign half-byte codes they are prepared to use, "read". > ... And you had the temerity too call me dishonest just because > you were too dunderheaded to understand my point. [1] Post of Fri 27 Oct 2006 21:40 according to the Google timestamp. [2] I had a quick Google just to see if RESOEXT has made it onto the web's radar. It has in the form of an APAR which quite inadequately tries to deal with the complexity - they need my swimming trunks - and I remember now that the key point was related to the fact that the trunks get wet if you go into the water so, if you want dry trunks you need to get another pair. It's an information APAR, II03610, which is supposed to be a clarification - and it dates from 1988. The only other hit is a reference to its disappearance - thankfully. ---------------------------------------------------------------------- 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