[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.