In <[EMAIL PROTECTED]>, on 07/08/2005
   at 11:58 PM, Joe Zitzelberger <[EMAIL PROTECTED]> said:

>I didn't write ISPF -- I wrote "viewed through the eyes of ISPF, with 
> a spool dataset listing".

Then why did you write "viewed through the eyes of ISPF, with  a spool
dataset listing" when you meant "viewed through the eyes of SDSF"? The
ISPF facility for viewing SPOOL output has nothing to do with SDSF.

>It was in the context of a discussion of  
>IBM supplied development tools available to view spool listings.

Yes. ISPF is one such tool. SDSF is a totally different one.

>Without considering the cool new options like WSAD or WSED, or even 
> the slightly moldy options, like WSA, just plain vanilla ISPF Edit/
> Browse is going to be the application that displays your data when 
> you view a spool dataset listing.

No. SDSF is going to be the application.

>See, this is the problem that occurs when you take one small piece
>of   something, perhaps a partial quote of an email, or perhaps the 
> message number of a syntax error, and try to understand it without 
> its context.

PKB. I understood it just fine; you were wrong, and don't seem to
understand the difference between a facility of ISPF and a similar
facility in SDSF.

>Words mean things in relation to the other words around them,

But ISPF never means SDSF.

>There is a section of the LRM named "SHIFT-IN" and another section  
>named "SHIFT-OUT" that appear in the LRM Table of Contents.

That's nice. What is there in the message to suggest that SHIFT-IN is
a COBOL reserved word rather than a generic term? Why would it be such
a burden for the compiler writers to point to the description of
SHIFT-IN as part of the error message?

>You think this is not enough?

The emperical data demonstrate that it was not enough.

>You can rely on the "compiler used to translate out non- 
>displayables".

You're evading the question. You claimed that the message already
includes everything that I asked for, and it clearly doesn't. Whether
you believe that what I asked for is appropriate has nothing to do
with whether it is there. The message does *not* include the
hexadecimal value of the text in error.

>But when Bill K. says 

Bill K did not say that the message includes the hexadecimal value of
the text in error. He did, however, say that the message could be
improved. Perhaps you should pay closer attention to what he actually
says instead of the spin that you wish to put upon it.

>The value is clearly there in the listing.

No. It is clearly possible to extract it from the listing, but that is
a separate issue and requires training that a COBOL programmer
normally wouldn't have.

>You say that Cobol programmers are clueless about what hexadecimal  
>data are or how to view them.

I did *not* however, say that they were incapable of understanding an
explanation should the compiler writers condescend to provide one. Nor
did I use the term "clueless"; there is normally no need for them to
know.

>But here, you say that the hexadecimal value is helpful to resolving 
> the problem and should be made available

Which part of "and explain" don't you understand?

>If the Cobol programmer in question is so completely ignorant, as
>you   suggest in the first case -- what makes you think the value
>you asked   for in the second case would be of any use at all?

Because I also suggested providing an explanation.

>Why do you assume any knowledge of DBCS is needed at all?  Knowing  
>that the Cobol reserved words SHIFT-IN/SHIFT-OUT are a pair that
>must appear together

Where does the message say that those are COBOL reserved words?
 
-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
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

Reply via email to