[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [open-cobol-list] Dialect emulation and "E-Level messages"
From: |
Thomas Biehler |
Subject: |
Re: [open-cobol-list] Dialect emulation and "E-Level messages" |
Date: |
Fri Mar 12 06:40:16 2004 |
User-agent: |
KMail/1.4.3 |
On Wednesday 10 March 2004 22:37, William M. Klein wrote:
> The purpose of this note is to state my STRONGEST possible desire that
Ok, it is a desire only, that is acceptable!
(no requirement --> a progress!) ;-)
> OpenCOBOL *not* provide "generic" compiler emulation support for syntax
> that the "emulated" compiler labels as an ERROR (and issues an E-level - or
> their equivalent) message - even if the emulated compiler creates "object
> code" in such situations.
What is the project goal? Standard !? cobol and support
compiler-compatible behavior (with adequate configuration!)
I think so! I hope so!
Hi Keisuke,
see you that the project goal (TODO)
should have higher piority
to avoid such (useless) disccusions!
>
> I know for a fact, that the VAST majority of IBM mainframe shops do *not*
> allow code into "production use" if the return code from the compiler is
> ABOVE a 4 - even though such compiles do create object code.
>
I have only requested one very special and limited MF compatible behavior.
--> move non-integer to alphanumeric: (1029-E)
I have IMO good reason in this special case!
Really, i do NOT want every bad behavior from Micro Focus in open-cobol!
(Instead i have changed many programms !)
Do not assume what i (others) want! Unterstand ?
If i want something, i prepare it sufficing and request it myself!
You, and only you, introduce IBM in the discussion. Not me!
(I know you love theoretical discussions, what would .. in future
.. if and if .. and if ...)
> In all my years of working for and with Micro Focus, I don't remember any
> sites that "regularly" allowed source code getting E-level messages into
> "production use".
>
You know every customer(s) ? Well, congratulations!
In all my years with Micro Focus (about 14 now) i have not seen
at least one question from Micro Focus:
- What do the customer wish ?
- What is good / bad ?
- What do the customers need / don't need ?
...
How can Micro Focus (and you) know, what a customers think / make ?
Have you contact to a alien who knowes that ?
> ***
>
> The whole "point" of E-level messages (in those environments that provide
> such) is to allow a compile to "complete" so that the programmer can
> get/see as many ERRORS as possible from one compile. The purpose is NOT to
> allow "bad source code" into production use.
>
That is only your conclusion or should i better say assumption (guess) ?
> E-Level error messages *do* tell what the "compiler is assuming" (even
> though it is ALWAYS different from what was coded). It is expected that the
> programmer will FIX the source code to MATCH the desired (and supported)
> behavior.
>
You should clear say if you (only) guess. No facts!
Look here, a orginal excerpt from Micro Focus Error Messages:
(Orginal content = (copy) , but i have it not reformated it for you!)
(I hope you can remember; I know you do not read before you write ...)
...
S Severe. When a severe fault is encountered, intermediate code is not
produced for the statement in error. Consequently, you cannot use this
intermediate code to generate native code, and you will not be able to run
code containing severe faults. You can, however, use the Animator software
on intermediate code containing severe faults if you set the E switch on. If
you use either of these methods to execute the intermediate code produced,
results are unpredictable. Following an S-level error, the source code
between the word that caused the error and the next recognizable verb or the
beginning of the next sentence is ignored. Consequently, when you correct
the original error and resubmit your program, more errors may be found.
E Error. Whenever an error fault occurs in your source code, your COBOL
system attempts to correct the error and continues to check the syntax and
produce intermediate code. Your COBOL system makes assumptions about what
was intended, and if this varies from your expectations, then you should
correct the source code that is in error. In any case, you may wish to
correct the source code so that you can produce intermediate code with no
errors. You can animate intermediate code that contains errors, and you can
also produce generated code from it, or run it, if you set the E RTS switch
on.
...
--> Your COBOL system makes assumptions about what
--> was intended, and if this varies from your expectations, then you should
--> correct the source code that is in error. In any case, you may wish ... !
and your conclusion about the purpose of "E-" error(s) was ???
--> total wrong!
You can see (above) Micro Focus even allows programs
with "S" = servere ! to run if "E - RTS" - switch is on!
(As "the" document writer over 5 years you should remember this!)
Absolut no problem to generate code (.gnt) in DEFAULT = standard
configuration if a program contains E- errors!
It runs with the (implicit) assumptions!
Reread the documentation first, if you can not remember
the Micro Focus defaults!
--> It is only YOUR requirement, not that from Mico Focus to change
"E-" errors! I want a compiler that is "compatible" in some kinds
(only with the adequate configuration!) with Micro Focus.
Not compatible with that what is in your brain! :-)
--> Micro Focus makes it (too) easy (= standard)
to compile / run such programs!
( I agree with you , (often) not a good behavior, it is more a trap ! )
But if you would not allow such misbehavior in open-cobol, users would
have to give up there ports! :-((
from Micros Focus (and other commercial compilers) to open-cobol.
The effort would be much too high!
(By the way: can you take influence to your old friends at Micro Focus
to change there bad (default / standard) behavior ?
Mail to them! In Error Messages Guide only the Numbers are listed
not the severity! No easy way for programmers, adminstrators for the
right CHANGE-MESSAG configuration! (1111-W is absolut fatal!)
You must have overseen this 5 years! )
No "compatible" behavior at all?
Do you really want that nobody can port to open-cobol ?
Have you ported some application in history ?
==> I do NOT assume that!
(In my port are 77 occurences of E-1029 error,
where the compiler "meets the assumption" of the programmers!)
Why i request this error E-1029.
=======================
ANSI Standard 1985 / 2002 :
--> MOVE non-integer to alphanumeric is NOT allowed.
MOVE integer to alphanumeric is allowed ?
--> no progress in 17 years.
The standard commitee could give standard rules for this problematic case:
MOVE non-integer to alphanumeric.
( Possibly solutions: rounding, truncation, only the integer part ,
the MF-behavior ...)
Why this execption at MOVE at this special case ?
There are long rules for the other cases!
I see no good reason here, but this is another discussion!
(fails the standard here ?!)
What are the alternative for me without the compatible behavior
of open-cobol in this special case.
Change all programs with the errors?
--> and test the changed programs ?
How to change:
===========
- MOVE FUNCTION integer or FUNCTION integer-part
would be also ok in the programs
(i assume here only, i would have to find out this first!)
--> then the "move "integer" to alphanumeric is allowed!
but not the original program behavior
--> But FUNCTIONS are TODO for a longer time! --> no alternative!
--> MOVE TO EDITED NUMERIC-Variables first ?
--> new Variables to declare , MOVE , change, test ...
--> CHANGE-MESSAGE (1029 S) in MF Compiler configuration
to prevent new occurences of the error!
--> inform all programmers about this case ...
( I miss some FUNCTION FORMAT (... template)
like in SQL in COBOL-Standard --> dynamicly formatting! )
All this effort because your feeling is bad ?
I repeat me, but i assume you make nothing practical!
Only theoretical discussions!
>
> For examples of some of the AWFUL code that you would need to "support" if
> you start adding E-level error message syntax as "valid" (with or without a
> warning), see:
>
> http://home.netcom.com/~wmklein/IBM/ErrMsg.htm
>
> and do a "find" on
> "-E"
>
> If you do repeated FINDS you will see HUNDREDS of "bad" syntax examples for
> which IBM *does* produce object code - even though the source code is
> CLEARLY "illegal".
>
Well, i will not buy a IBM compiler ...
Discuss with the ibm people ...
NOBODY requests to support other bad things!
Perhaps you have had a nightmare !?
Some hints from me for you:
=====================
Be concret not abstract!
Read first, if you can not remember, and then (perhaps) write
if you have something important to say!
Cite correctly! Read the news-group netiquette!
I hope, this times, my words are easy understandable!
Thomas
P.S. I do NOT like that you stole my time with useless
postings / starting discussion(s) and try to influence the project
in a bad dircection!
But he! Good postings from you are always welcome!
I had to answer long here, to show where you are (totally) wrong.
This costs my time and my nerves!
I have to do some other things around open-cobol and my port.
I hope other people agree with me at this point!
- [open-cobol-list] Re: feature request: MOVE NON-INTEGER TO ALPHA-NUMERIC (MF-EXTENSION), Keisuke Nishida, 2004/03/05
- [open-cobol-list] Re: feature request: MOVE NON-INTEGER TO ALPHA-NUMERIC (MF-EXTENSION), Thomas Biehler, 2004/03/05
- RE: [open-cobol-list] Re: feature request: MOVE NON-INTEGER TO ALPHA-NUMERIC (MF-EXTENSION), William M. Klein, 2004/03/05
- Re: [open-cobol-list] Re: feature request: MOVE NON-INTEGER TO ALPHA-NUMERIC (MF-EXTENSION), Keisuke Nishida, 2004/03/05
- RE: [open-cobol-list] Re: feature request: MOVE NON-INTEGER TO ALPHA-NUMERIC (MF-EXTENSION), William M. Klein, 2004/03/05
- Re: [open-cobol-list] Re: feature request: MOVE NON-INTEGER TO ALPHA-NUMERIC (MF-EXTENSION), Keisuke Nishida, 2004/03/06
- [open-cobol-list] Dialect emulation and "E-Level messages", William M. Klein, 2004/03/10
- Re: [open-cobol-list] Dialect emulation and "E-Level messages", Keisuke Nishida, 2004/03/10
- Re: [open-cobol-list] Dialect emulation and "E-Level messages", Bernard Giroud, 2004/03/11
- Re: [open-cobol-list] Dialect emulation and "E-Level messages",
Thomas Biehler <=