AW: gnubol: Alphanumeric-edited to Alphanumeric - elementary MOVE

[SiedentopC@Alte-Leipziger.de]

hello Bill,

from my point as a developer:

If the terminal or print-output is korrupted, nevermind, but if the internal
data are false, that could be very expensive. You see an wrong data earlier
oin case of an edited data-item than of database-item. So I want to trust
the data. 

But to be forced to check a runtime-field after every move, in which edited
data are involved, is far from the reality. It makes the code bad to read.
Nobody do this strictly. I prefere a compiler-message ("warning" as
default-severity) in a form like "Data may be korrupted, because the sending
field is edited." or "Data can be loss, because the mismatch of physical
length between the sending and recieving field."

To be compatible with various not-know previous behaviors of current
compilers is also no good decision, it complicates the implementation. Let
the IN-compatibility seen as early as possible - at the compile-time. And if
I (as a cobol-developer) have the chance, to see the problems, I can change
the code. And if I want the coding "as is", I would like to set the the
severity of this message to "ignore". In the other case, I want set them to
"severe".

move "any-value" to alpha-non-edit
move alpha-non-edit to alpha-edit
move alpha-edit to alpha-non-edit
display alpha-non-edit	
// I hope, that the data-value is independent from the temporary move to the
edited field.


Carsten


> -----Ursprüngliche Nachricht-----
> Von:	William M. Klein [SMTP:wmklein@ix.netcom.com]
> Gesendet am:	Montag, 31. Januar 2000 19:19
> An:	J4; WG4 Distribution
> Cc:	gnu
> Betreff:	gnubol: Alphanumeric-edited to Alphanumeric - elementary
> MOVE
> 
> Although I haven't heard from everyone on this topic, I have heard what a
> number of '85 compilers do.  (What they do MAY not be what the Standard
> said - but I can't find any rule to contradict their behavior.)
> 
> 1) Such elementary moves are EXPLICITLY "legal".
> 
> 2) Although "de-editing" is explicitly required by numeric-edited to
> numeric
> elementary moves, there does not seem to be any similar rule for
> alphanumeric-edited to alphanumeric moves
> 
> 3) So far, all "reporting" compilers simply ignore the editing symbol in
> such
> MOVEs (i.e. if you have a "PIC X/X" as the SENDING item, it is actually
> treated as if you had "PIC XXX").
> 
> 4) The actual elementary MOVE rules ('85 Standard and draft) are totally
> "silent" on what happens in such MOVEs.  The "incompatible data" rules of
> the
> '85 Standard *could* be read as applying - but so far I haven't heard of
> any
> compiler that actually treats such situations as "incompatible data".
> 
>  ***
> 
> The bottom-line is that I am "scared" to touch this portion of either the
> MOVE statement rules or the PICTURE clause rules.  Some other code
> examples
> that I think could get "impacted" by my making the rules clearer are:
> 
>   01 Group1.
>      05 alpha-edit Pic X/X.
>   01 Alpha1        Pic XXX.
> 
>    Move "ABC" to Group1
>    Evaluate Alpha-edit
>      When "ABC"
>        Display "believe the data"
>      When "A/C"
>        Display "believe the picture"
>      When other
>        Display "unknown behavior"
>   End-Evaluate
> 
>   Evaluate Function lower-case (alpha-edit)
>      When "abc"
>        Display "believe the data"
>      When "a/c"
>        Display "believe the picture"
>      When other
>        Display "unknown behavior"
>   End-Evaluate
> 
>   Inspect alpha-edit
> 	Tallying Num-Field
> 	  for character before "/"
>    .
> 
> ***
> 
> If we (I?) go with explicitly making this "incompatible data", then
> vendors
> (current and future) can do whatever they want with such code (so it would
> be
> guaranteed to be "compatible" with their '85 implementations) - but then
> they
> would be "required" to check such fields if EC-DATA-INCOMPATIBLE is being
> checked.
>
> If I say that editing symbols (for alphanumeric-edited and
> national-edited)
> items are "ignored" when the field is a "sending operand" - then programs
> would be "required" to continue execution, but I don't think that
> programmers
> will be able to rely on their data.
> 
> If I make this situation totally "implementor defined" - little
> portability
> will be provided, but this might be "compatible" with previous Standards.
> 
>   ***
> 
> Any comments? suggestions?
> 
> Bill Klein
>   wmklein <at> ix.netcom.com
> 
> 
> --
> This message was sent through the gnu-cobol mailing list.  To remove
> yourself
> from this mailing list, send a message to majordomo@lusars.net with the
> words "unsubscribe gnu-cobol" in the message body.  For more information
> on
> the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.