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
