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
