On 23 Jun 2005 07:16:02 -0700, in bit.listserv.ibm-main you wrote: >On Thu, 2005-06-23 at 09:16 -0400, Thomas Conley wrote: >> I bet you think that the BPX messages coming out of ISHELL are also >> self-documenting. > >Aw, c'mon Tom. There are some excellent decafs -- you should try one. > >The COBOL messages *are* (for the most) self-documenting. I can't >offhand think of an instance when I couldn't figure out what one meant. >If your programmers don't understand COBOL compiler messages then maybe >they *should* consider another line of work -- or at least some remedial >training.
Having programmed in COBOL since 1963 and having been a systems programmer who has submitted mods to the MVT tape, JES3 tape and CBT tape, I would have found the error message baffling. While someone should have caught the change in options (something I was normally paranoid about when going to a new release), the message is baffling if you aren't intentionally using shift-in and shift-out and this is the first time you've seen it. It becomes even more baffling to even an experienced COBOL programmer when the literal in question is generated by a preprocessor and the site doesn't intentionally use DCBS. Remember that the literal you see on the screen probably is not in hexadecimal so the shift-in may appear as a space. Normally the messages are fairly good but better help facilities for errors are needed. I suspect that the Integrated Development Environments provided by Microfocus and others on Unix and PC environments do a better job. > >It is reasonable for the compiler developers to assume some level of >competence on the user's part; COBOL isn't a 4GL after all. And it >would be IMO a waste of time to have a tech writer produce something >like: > > IGYOP3091-W Code from <source code 1> to <source code 2> > can never be executed and was therefore discarded > > Explanation: The compiler detected that some of the program > code could never be branched to. Rather than > produce object code that would only take up space > and never be executed, the compiler skipped the > unexecutable program source code. > > In the message, <source code 1> is the first of > the source code that has been skipped, and <source > code 2> marks the end of code that was skipped. > > Programmer response: Examine the program listing and determine > whether the code is intended to be executed. > Source programs are line-numbered in the program > listing, and the compiler error message includes > the source program line number near which > <source code 1> can be found. > >Above notwithstanding, I recognize that it is MUCH easier to get a RCF >accepted than an APAR, and if you *do* find a particular compiler error >message wanting then you're tied to the maintenance QA process. So >maybe what IBM needs is an error message server, accessible from all >products, with a database that is easily updated. Changes to the >database wouldn't require regression testing, and would have faster >turnaround than you'd get from the standard publication schedule. > >Just thinking out loud. There are OA issues and other stuff to worry >about, too. ---------------------------------------------------------------------- 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
