[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gnubol: STD - What do you think *should* happen
My question/issue has to with a task of "clarifying" the wording in the
revision of the Standard. My underlying requirement will be to be compatible
with the '85 Standard (what is required, but not necessarily what is assumed
but ambiguous). I believe the '85 Standard is QUITE clear that "de-editing"
does not occur in alphanumeric-edited to alphanumeric elementary items - when
the data is "valid", i.e.
01 Group1.
05 alpha-edit Pic X/X.
01 Alpha1 Pic XX.
....
Move "A/B" to Group1
Move alpha-edit to Alpha1
will result in alpha1 having the contents "A/" and *not* "AB". Therefore, I
don't think that de-editing (whether desirable or not) would be an option if
alpha-edit regardless of the content of alpha-edit.
Note: the rules in the '85 Standard that talk about de-editing are pretty
specific to numeric-edited to numeric elementary moves - and I don't think
any current vendor provides this as a (non-standard) option for
alphanumeric-edited to alphanumeric.
Bill Klein
wmklein <at> ix.netcom.com
> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of
> RKRayhawk@aol.com
> Sent: Sunday, January 30, 2000 6:14 AM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: STD - What do you think *should* happen
>
>
> In a message dated 1/29/00 11:04:10 AM EST, wmklein@ix.netcom.com writes:
>
> <<
> 01 GROUP1.
> 05 ALPHA-EDIT PIC X/X.
> 01 ELEM1 PIC XX.
> ...
> MOVE "ABC" TO GROUP1
> MOVE ALPHA-EDIT TO ELEM1
>
>
> ****
>
> The question is what the 2nd move "should" do. I can think of
> (at least) 3
> possibilities:
> >>
>
>
> Actually, since numeric edited fields _would_ de-edit, I would
> tend to assume
> that a compiler might generate code that _would_ de-edit the alphanumeric
> edited fields for us. So if the first move of 'ABC' to the group level
> munged the value to 'ABC' (and not 'A/?'), then the hoped for
> de-edit would
> shuttle 'AC' to the result field.
>
> BUt I don't know what the standard says 'should' happen. Programs
> I have seen
> that are involved with de-editing are either dealing with in house
> data, that
> is well behaved, or dealing with data from outside and no one believes the
> picture clauses anyway!
>
> In practice junior programmers are a little snowed by de-editing, and
> surprisingly many DBAs do not know COBOL! Data definitions are frequently
> brutish; using redefinitions or lower level data items to do the
> work. There
> is not a strong tendency towards interchange that involves
> de-editing. So I
> think there is not a general practice, nor a general expectation for the
> scenario you posit. Instead there is a general avoidance of it.
>
> So if you want to know what people think _should_ happen, you will
> probably
> find marks spread across the map, and only some of that will be
> from actual
> compiler interaction experience. If you want to know what
> _should_ happen in
> a rational sense (which I don't think you asked), then consistency is what
> _should_ result.
>
> De-editing should be consistent. A student who learns a few lessons about
> de-editing should be able to generalize her knowledge, no matter
> which part
> of the subject she studies first. COBOL should have consistent behavior
> across its facilities.
>
> But off in the compilers, over there in reality, shoulda, coulda,
> and woulda,
> can be many a spendid thing indeed.
>
> So the counter-point would be, assuming elementary moves: when do you not
> want de-editing to happen? And why? Can you state the reasons that
> you expect
> universal agreement on that?
>
> Best Wishes,
> Bob Rayhawk
> RKRayhawk@aol.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.