On Jun 23, 2005, at 12:09 AM, Thomas Conley wrote:
Not at all.
Just because you find a shift-in in your source doesn't mean the
error message is at fault. If you look at your listing and
actually see a shift in there, then you might want to complain
about the preprocessor that placed it there. But that would be
the preprocessors fault, not the message -- it means exactly what
it says.
If you will pardon the pun, this sound like a perfect example of
'shooting the messenger' instead of addressing the root cause.
Joe,
You are wrong here. Imagine a shop that has used COBOL for
decades, and can't even spell DBCS. All of a sudden this message
pops up after a compiler upgrade. The programmer asks "What's a
shift-in?" The systems programmer says "BTF outta me. Let's get
the message manual." Oops, no manual, now what? Open a PMR only
to be told by COBOL Level 2 what an idiot you are......
My shop can't spell DBCS. And I've never, ever, ever, used DBCS.
But I still know about the two figurative constants SHIFT-IN and
SHIFT-OUT. Shift-In and shift-out are fully documented in the
programmer reference and programmer guide. Two manuals that any
programmer should be familiar with.
And a look at the listing would clearly show a SI/SO actually in the
source.
And the location of the SI/SO is documented in the message to be
within a preprocessor command.
The problem is not with the compiler or the shift message -- it is
with the preprocessor. Until that is fixed the old garbage-in/
garbage-out. When one receives garbage upon output, it is a good
assumption that you will find garbage in the input.
Your assumption that this message tells the whole story is absurd.
Every IBM message is supposed to have a response documented, like
this:
Programmer response: If using DBCS support, be sure that your DBCS
character stream contains proper shift-in shift-out pairs. If you
are not using DBCS, be sure that you specify the NODBCS in your
compile.
The message was fully valid, improperly started or terminated
literals are improperly started or terminated literals. The message
clearly documented that. Why do you feel the need for a manual that
says:
Programmer response: Always use DBCS literal delimiters in pairs.
Problem solved. Expecting the user to know every option and
feature of the COBOL compiler, especially those features and
options that they're not even using, is ridiculous. That's why
every error message generated by an IBM product is supposed to be
fully documented with appropriate Response sections.
There is no need for the programmer to know how DBCS works, only that
one of the delimiters was plugged into their code by the
preprocessor. From there, the issue is not DBCS at all.
----------------------------------------------------------------------
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
