In [EMAIL PROTECTED], on 06/28/2005
at 09:27 PM, Bill Klein [EMAIL PROTECTED] said:
I don't understand your comment.
Because you ignored part[1] of it and are are assuming that what
appears in the listing is identical to what appears in the source
code. That certainly didn't use to be true,
I don't understand your comment.
As previously indicated the FLAG(I,I) option became the default at the same
time as DBCS.
Therefore, the compiler error message WILL appear in the listing IMMEDIATELY
after the line inserted by the translator (indicating the column in that
line with the
In [EMAIL PROTECTED], on
06/23/2005
at 01:33 PM, Bill Klein [EMAIL PROTECTED] said:
With FLAG(I,I) which became the default at the same time as DBCS, the
message *does* appear exactly AFTER the line (inserted by the
preprocessor) which follows the originally coded line. As the mesage
also
Perryman, Brian [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
i.com...
SNIP
snip
What is not self-describing about these is why they suddenly started
appearing when the programmer hadn't changed any of his code, that's what!
If messages start appearing after a migration of
Sorry to disagree on this one (again), but the error message tells you
exactly WHERE (what line and what column in that line) has the problem. a
VERY simple search of either the COBOL LRM or APG for the term shift-in
will tell you what this means and again, a search of the manual SHOULD take
you
So far, I haven't received any off-list or online replies to my pointing out
my work-in-progress web page at:
http://home.comcast.net/~wmklein/IBM/ErrMsg.htm
Would this type of web-page be of use to those who can't figure out the
COBOL compiler messages?
McKown, John [EMAIL PROTECTED] wrote
If you didn't upgrade your COBOL as well as z/OS, then I would be REALLY
surprised in this change occurring. The COBOL documentation talks about the
change from NODBCS to DBCS as the default compiler option - in newer
releases of Enterprise COBOL. There should ALSO be a change from FLAG(I) to
Bill Klein wrote:
If you didn't upgrade your COBOL as well as z/OS, then I would be REALLY
surprised in this change occurring. The COBOL documentation talks about the
change from NODBCS to DBCS as the default compiler option - in newer
releases of Enterprise COBOL. There should ALSO be a
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
snip
And I can't figure out why they made that change,
since DBCS is, supposedly, on its eventual way
out, to be replaced by NATIONAL (Unicode). Any
idea why the default was changed? Especially since
the vast majority
as the default (was: Fw: Another OS/390 to z/OS 1.4
migration question (COBOL)
Bill Klein wrote:
Steve Comstock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
snip
And I can't figure out why they made that change,
since DBCS is, supposedly, on its eventual way
out, to be replaced
Imbriale, Donald (Exchange) wrote:
I think you're confusing the DBCS value of the NSYMBOL option with the
DBCS option.
Well, it certainly is confusing. But I tried to make it
clear what I was saying is choosing the NATIONAL value
for the NSYMBOL option forces on the DBCS option. And
it still
OK, to explain ...
*ALL* the DBCS (or NODBCS) compiler option does is to determine how
X'0E' and
X'0D' are treated when they appear WITHIN an alphanumeric literal. When
it is
turned on, then they are treated as SHIFT-OUT/IN control characters (and
this
may be shifting to Unicode *or* to
Bill Klein wrote:
OK, to explain ...
*ALL* the DBCS (or NODBCS) compiler option does is to determine how
X'0E' and
X'0D' are treated when they appear WITHIN an alphanumeric literal. When
it is
turned on, then they are treated as SHIFT-OUT/IN control characters (and
this
may be shifting to
13 matches
Mail list logo
