Re: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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, and so far nobody has been willing to state that it has changed. As previously indicated the FLAG(I,I) option became the default at the same time as DBCS. As previously indicated, that is irrelevant. 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 problem). What good does that do when the message lacks the necessary data to diagnose the problem and is unintelligible to the target audience? If a CICS application programmer can't recognize a translator inserted line with Move alphanumeric literal to DFH field as being inserted by the translator Straw dummy. The CICS programmer can recognize it; what he can't do is to guess what nondisplayable data are in the text. and/or if that same programmer can't recognize that the column that the message is pointing to is within an alphanumeric literal, Another straw dummy. then NO messages and codes manual is ever going to help that programmer (IMHO) A combination of a messages manual and a better message would. Starting with displaying the message text in hexadecimal, explaining what SI and SO are and giving their hexadecimal values. [1] Have they stopped translating out nondisplayable characters? -- 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
Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 problem). If a CICS application programmer can't recognize a translator inserted line with Move alphanumeric literal to DFH field as being inserted by the translator and/or if that same programmer can't recognize that the column that the message is pointing to is within an alphanumeric literal, then NO messages and codes manual is ever going to help that programmer (IMHO) Shmuel Metz , Seymour J. [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... In [EMAIL PROTECTED], on 06/28/2005 at 08:48 AM, Joe Zitzelberger [EMAIL PROTECTED] said: While column 50 might look blank iff you are using a printed listing (a rarity in the days of syntax highlighting editors Editors? It doesn't exist in the source file, so the editor doesn't see it. and a waste of trees) The term listing also includes DASD files with A or M carriage control. Have they stopped translating out nondisplayable characters? the surrounding columns would have something like: Move 'a 0d 2 ic$k34 d pd e,x d' to DFHEI1234 Why would you get the error message for alphanumeric text? I don't see a SI or SO there. That should be enough for anyone to realize it is a translator problem. It would if the compiler were complaining about one of those characters. -- 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
Re: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 tells the column where the problem exists, it should be pretty obvious where the problem was. (Again - or at least it would be to me) Okay, so you look at column 50 in the listing and you see a blank? Now what? It would help if the message included the offending literal text, in hexadecimal, and explained SI and SO for the benefit of those who have no reason to understand DBCS. If I didn't know what DBCS was I would have found the message to be totally opaque, and as is I still wouldn't have known what the offending data were. -- 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
Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 compilers, then SOMEONE (application programmer or systems programmer) SHOULD have the sense to check in the Migration Guide. Furthermore, IMHO, anyone (systems programmer) who does a migration of compilers and does NOT look at what compiler options are DOCUMENTED as changing and figuring out what implications this has for their shop, isn't doing their job. If the complain was (which is NOT true) that this isn't documented as a CHANGE in both the Migration and Installation manuals, then I would say - yes, there is a problem, but this one just isn't in that category. -- 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
Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 to: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3c120/2.18 which should show you where your customization went wrong. You state, IBM message is supposed to have a response documented, like this: ... Where did you get this idea? Some products certainly do that, but certainly NOT all (and it isn't just the COBOL compiler that doesn't). *** In the days of hard-copy only manuals, there MIGHT have been a need for more explanation, but I am not convinced that the COBOL messages along with an online search of the COBOL bookshelves using the keywords from the message won't get you to the correct place. P.S. This specific problem would have been solved by changing to NODBCS. HOWEVER, the real problem (as pointed out elsewhere) was the change in CICS and differences between how the COBOL2 translator option worked and now works - versus how the COBOL3 translator works. Do you REALLY think that a COBOL messages manual would have helped you with this? Thomas Conley [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... - Original Message - From: Joe Zitzelberger [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, June 22, 2005 7:58 PM Subject: Re: Another OS/390 to z/OS 1.4 migration question (COBOL) On Jun 22, 2005, at 7:04 PM, Steve Comstock wrote: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. Not if he was not using DBCS. No reason to expect this message. Apparently it was caused by the change if default compiler option settings, which does seem a little obscure, don't you think? 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.. 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. 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. Regards, Tom Conley -- 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
Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 in message news:[EMAIL PROTECTED]... Hum, there appears to be an apparent need/desire for this documentation, despite IBM's protestations. What I think would be interesting would be a Wikipedia like setup. That's where all these messages could be documented and then users could post their observations and helpful hints. Unfortunately, a Wikipedia is subject to defacing by kids, and others, who have nothing better to do. It also requires a hosting web site. Hum, I wonder if Marist would be interested? -- John McKown -- 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
Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 FLAG(I,I) so that these messages SHOULD have appeared in the source code exactly by the line that had the problem. FYI, What the change from NODBCS to DBCS means is that *if* you have hex OD and OE in your alphanumeric literals, they are treated as DBCS control characters. NOTE WELL: COBOL compiler messages (IGY) are *not* documented; they are self-documenting. If your application programmers can't figure out these specific messages, I would suggest additional training for them. If they don't know WHY they are getting the messages now (but not before), then I suggest you provide them references to the COBOL Migration Guide which does talk about such changes (NODBCS to DBCS). Finally, it does sound as if you may want to switch your site default to NODBCS - unless you also have DBCS applications. The difference between COBOL2 and COBOL3 compiler options MAY influence some of this, but isn't the real problem with these messages. Perryman, Brian [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] i.com... Hi folks Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL program on z/OS 1.4 in Enterprise Cobol of z/OS and OS/390 V3.2. I can't find these blasted messages documented anywhere!! Is there some convoluted format for decoding them? I suspect it's just a COBOL options member problem, but I need to see the message description. It only seems to happen when the CICS precompiler (CICS 4.1.0) is included first. The texts of the messages are: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. IGYPS0158-E A nonnumeric or national literal containing double-byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line -- 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
Re: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 change from FLAG(I) to FLAG(I,I) so that these messages SHOULD have appeared in the source code exactly by the line that had the problem. FYI, What the change from NODBCS to DBCS means is that *if* you have hex OD and OE in your alphanumeric literals, they are treated as DBCS control characters. 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 of US shops do not even use DBCS data? NOTE WELL: COBOL compiler messages (IGY) are *not* documented; they are self-documenting. If your application programmers can't figure out these specific messages, I would suggest additional training for them. Thanks, Bill, I think. But I agree with another poster who suggested perhaps some messages are not as self-documenting as the compiler writers think they are. Maybe some training on English? I guess the kind of training we (and, presumably other training vendors) offer on COBOL would provide the background for programmers to be more likely to understand the messages. If they don't know WHY they are getting the messages now (but not before), then I suggest you provide them references to the COBOL Migration Guide which does talk about such changes (NODBCS to DBCS). Finally, it does sound as if you may want to switch your site default to NODBCS - unless you also have DBCS applications. The difference between COBOL2 and COBOL3 compiler options MAY influence some of this, but isn't the real problem with these messages. Again, why the IBM-supplied compiler default was changed to DBCS is a mystery. Or at least a curiosity. Kind regards, -Steve Comstock The Trainer's Friend, Inc. http://www.trainersfriend.com -- 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
DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 of US shops do not even use DBCS data? NSYMBOL(National) *requires* (forces on) DBCS, so actually having/allowing the DBCS option is a pre-requisite for having Unicode support. There are some long and painful internal discussions (between myself and the IBM ANSI COBOL rep) and within the J4 group about exactly what is Standard conforming behavior when you have control characters within an alphanumeric literal. I won't go into them here, but I semi-understand the IBM position that ALLOWING national character strings within an alphanumeric literal is a good thing when you MAY use X0E type notation *if* you want to have those x'0d' and x'0e' within literals. The change in defaults WAS highlighted in announcements, migration guides, and installation material - but what its IMPLICATIONS were - are probably unclear to most programmers (application or systems). As stated in another note, if you use the COBOL3 CICS translator option, you will never have a problem with this (for CICS generated code) and the amount of user code with hex 0E and 0D intentionally within NON-DBCS alphanumeric literals is so small that I suspect this should not be a major problem. -- 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
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
I think you're confusing the DBCS value of the NSYMBOL option with the
DBCS option.
Don Imbriale
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Steve Comstock
Sent: Wednesday, June 22, 2005 2:36 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DBCS 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 by NATIONAL (Unicode). Any
idea why the default was changed? Especially since
the vast majority of US shops do not even use
DBCS data?
NSYMBOL(National) *requires* (forces on) DBCS, so actually
having/allowing
the DBCS option is a pre-requisite for having Unicode support.
Ah. Now that is just flat out wrong. The doc says it is
NSYMBOL({NATIONAL|DBCS}) - that is, one or the other.
Ahh, but wait. Same doc under Conflicting Compiler Options,
it says NSYMBOL(NATIONAL) forces on the DBCS compiler option.
Now I'm really confused. Why would you set up a choice of
NSYMBOL({NATIONAL|DBCS}) when setting NATIONAL forces on DBCS?
Very nice.
There are some long and painful internal discussions (between
myself and
the IBM ANSI COBOL rep) and within the J4 group about exactly what is
Standard conforming behavior when you have control characters
within an
alphanumeric literal. I won't go into them here, but I
semi-understand the
IBM position that ALLOWING national character strings within an
alphanumeric literal is a good thing when you MAY use X0E type
notation
*if* you want to have those x'0d' and x'0e' within literals.
The change in defaults WAS highlighted in announcements, migration
guides,
and installation material - but what its IMPLICATIONS were - are
probably
unclear to most programmers (application or systems).
Yup.
***
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***
--
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
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 doesn't make any sense. Of course, it probably
is not a good practice to have standalone options the
same as choices for other options.
Kind regards,
-Steve Comstock
Don Imbriale
[snip]
NSYMBOL(National) *requires* (forces on) DBCS, so actually
having/allowing
the DBCS option is a pre-requisite for having Unicode support.
Ah. Now that is just flat out wrong. The doc says it is
NSYMBOL({NATIONAL|DBCS}) - that is, one or the other.
Ahh, but wait. Same doc under Conflicting Compiler Options,
it says NSYMBOL(NATIONAL) forces on the DBCS compiler option.
Now I'm really confused. Why would you set up a choice of
NSYMBOL({NATIONAL|DBCS}) when setting NATIONAL forces on DBCS?
Very nice.
There are some long and painful internal discussions (between
myself and
the IBM ANSI COBOL rep) and within the J4 group about exactly what is
Standard conforming behavior when you have control characters
within an
alphanumeric literal. I won't go into them here, but I
semi-understand the
IBM position that ALLOWING national character strings within an
alphanumeric literal is a good thing when you MAY use X0E type
notation
*if* you want to have those x'0d' and x'0e' within literals.
The change in defaults WAS highlighted in announcements, migration
guides,
and installation material - but what its IMPLICATIONS were - are
probably
unclear to most programmers (application or systems).
Yup.
--
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
DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 IBM-specific-DBCS codes). The NSYMBOL compiler option determines - What the default USAGE is for PIC N data items (NATIONAL (aka UNICODE) or DISPLAY-1 (aka DBCS)) - Whether Nliterals (and NXliterals are DBCS or UNICODE format (on output) Therefore, it is logically possible to have any combination of NODBCS/DBCS and NSYMBOL(NATIONAL)/(DBCS). IBM, however, at roughly the same time they changed the default to DBCS decided (for political reasons - I believe, not syntactic reasons) NOT to support the combination of NODBCS ,NSYMBOL(NATIONAL) Clearer -- Bill Klein wmklein at ix.netcom.com Steve Comstock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 doesn't make any sense. Of course, it probably is not a good practice to have standalone options the same as choices for other options. Kind regards, -Steve Comstock -- 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
Re: DBCS as the default (was: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL)
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 Unicode *or* to IBM-specific-DBCS codes). The NSYMBOL compiler option determines - What the default USAGE is for PIC N data items (NATIONAL (aka UNICODE) or DISPLAY-1 (aka DBCS)) - Whether Nliterals (and NXliterals are DBCS or UNICODE format (on output) Therefore, it is logically possible to have any combination of NODBCS/DBCS and NSYMBOL(NATIONAL)/(DBCS). IBM, however, at roughly the same time they changed the default to DBCS decided (for political reasons - I believe, not syntactic reasons) NOT to support the combination of NODBCS ,NSYMBOL(NATIONAL) Clearer Yup. Thanks. Kind regards, -Steve Comstock -- 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
