In <[EMAIL PROTECTED]>, on 06/30/2005
at 10:55 PM, Joe Zitzelberger <[EMAIL PROTECTED]> said:
>TSO/ISPF is about as least common denominator as you can get.
The Sun rises in the East. ISPF is not the issue. The issue is the
contents of the listing file. Which, by the way, is normally a SYSOUT
file viewed through SDSF.
>The compiler doesn't translate out nondisplayable.
It used to. Whcih is why I kept asking you whether that has changed.
>Here is a brief example of the problem, viewed through the eyes of
>ISPF, with a spool dataset listing:
That's not something that a COBOL programmer would be likely to do;
he's either direct it to DASD or view it with SDSF. Further, if he
didn't know about DBCS, he'd have no idea what SI and SO were and
wouldn't know to use a hexadecimal editor.
>The shift is included in the literal in the listing and the messages
> are shown following the offending line and the column is clearly
>described.
I don't what the column clearly described, and want the error and
programmer response clearly described.
>What more could possibly be said in a message manual?
Can you read? I've repeatedly explained what more could be included in
the message. The message could provide context for a programmer who
doesn't know about DBCS. The message could provide the bad text in
hexadecimal. For that matter, the message could point to the SI
instead of expecting a COBOL program to properly offset it in a
hexadecimal display. You do understand that the column in the listing
is not generally the same as the column in the source, don't you?
>The questioner was not necessarily conversant with Cobol at all.
Many people writing COBOL (not Cobol) are not conversant with COBOL;
they're part of the target audience.
>If the audience included people that were conversant in CICS
>development and in Cobol development, I would expect them to
>understand the message in context, even without DBCS knowledge.
Yes, as did the compiler developers. That expectation is based on
wishful thinking rather than empirical data.
>There are a number of 'names' for chars (NUL, NAK, ACK, LF, BS, CR,
>etc) that do not mean much to a Cobol programmer in a z/OS
>environment, but an unexpected x'??' is pretty clear.
ITYM that it is pretty clear that the error message did not say
"unexpected x'??'"
>I'm not sure if non-Cobol programmers would qualify as a
>representative sample of people who should understand Cobol compiler
> messages. If they do, then all messages should be annotated --
>"programmer response: learn Cobol".
That would be singularly unhelpful, which is no surprise. Programmers,
including COBOL programmers, typically learn only the parts of the
language that they use. They are often unprepared for error messages
referring to language features that they did not intend to use or
don't even know about.
>Again, I would ask, how much more documentation would you put on it?
Why? Will you read the answer this time after having ignored it
before?
>The message points you to the exact byte in error and says "this
>looks funny to me, but I'll trust you want it there and accept it as
> written". What could you say about it?
Any competent technical writter could tell you that.
>"Read the LRM" seems like the only polite thing that could be written.
Indeed, to one who doesn't understand how to do documentation. I and
others have described other things that could be written, e.g.,
1. Brief explanations of DBCS and related compiler options
2. Suggestion to read the literal in hexadecimal
--
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
