Overlapping varaibles in cobol language...

Happy Friday,

just wondering if its ok to overlap constant variables in cobol
language (OO & CharacterBase)? the listed below code have yielded
about 98% success rate with very minor odd results. Does this
approach considered risky to eliminate leading or trailing spaces?
do you see data corruption risk factor as well?
would like to hear your thoughts on this. Thanks.

John.

*>--- overlap Right-2-Left  ---------------------*>

01  String1      Pic X(15) Value "       ABCDEFGH".
01  WipeOut      Pic 9(4) comp-5 value 0.

If String1 <> Space
move 16 to WipeOut
Perform Until String1(1:1) <> Spaces
move String1(2:14) To String1(1:14)
move space to string1(WipeOut - 1:1)
End-Perform
end-if.

*>--- overlap Left-2-Right  ---------------------*>

01  String2      Pic X(15) Value "ABCDEFGH       ".
01  WipeOut      Pic 9(4) comp-5 value 0.

If String2 <> Space
move zeros to WipeOut
Perform Until String2(15:1) <> Spaces
move String2(1:14) To String2(2:14)
move space to string2(WipeOut + 1:1)
End-Perform
end-if.

*>------------------------------------------------*>

Well, hmmm.  Let's see what the COBOL standards have to say about this:

ANSI X3.23-1974, page II-51, paragraph 5.3.5, Overlapping operands:  When a
sending and a receiving item in an arithmetic statement or an INSPECT, MOVE,
SET, STRING or UNSTRING statement share a part of their storage areas, the
result of the execution of such a statement is undefined.

ANSI X3.23-1985, page VI-69, paragraph 6.4.5, Overlapping Operands:  When a
sending and a receiving item in any statement share a part or all of their
storage areas, yet are not defined by the same data description entry, the
result of the execution of such a statement is undefined. ...

ISO/IEC 1989:2002, page 390, paragraph 14.5.9, Overlapping operands:  When a
sending and a receiving item in any statement share a part or all of their
storage areas, yet are not defined by the same data description entry, the
result of the execution of such a statement is undefined. ... In the case of
reference modification ... if an overlapping situation exists, the results
of the operation are undefined.

Maybe it does what you want under certain circumstances in your particular
implementation and maybe it doesn't.

Do you *really* think it's a good idea to go there, given the lengths to
which the standards have gone to discourage such code over the last
thirty-one years?   Are you *really* surprised at the "very minor odd
results"?

-Chuck Stevens


"XPPROGRAMMER" <saud_abraham@hotmail.com> wrote in message
news:1106938614.280367.156600@z14g2000cwz.googlegroups.com...
> Happy Friday,
>
> just wondering if its ok to overlap constant variables in cobol
> language (OO & CharacterBase)? the listed below code have yielded
> about 98% success rate with very minor odd results. Does this
> approach considered risky to eliminate leading or trailing spaces?
> do you see data corruption risk factor as well?
> would like to hear your thoughts on this. Thanks.
>
> John.
>
> *>--- overlap Right-2-Left  ---------------------*>
>
> 01  String1      Pic X(15) Value "       ABCDEFGH".
> 01  WipeOut      Pic 9(4) comp-5 value 0.
>
> If String1 <> Space
> move 16 to WipeOut
> Perform Until String1(1:1) <> Spaces
> move String1(2:14) To String1(1:14)
> move space to string1(WipeOut - 1:1)
> End-Perform
> end-if.
>
> *>--- overlap Left-2-Right  ---------------------*>
>
> 01  String2      Pic X(15) Value "ABCDEFGH       ".
> 01  WipeOut      Pic 9(4) comp-5 value 0.
>
> If String2 <> Space
> move zeros to WipeOut
> Perform Until String2(15:1) <> Spaces
> move String2(1:14) To String2(2:14)
> move space to string2(WipeOut + 1:1)
> End-Perform
> end-if.
>
> *>------------------------------------------------*>
>

On 28-Jan-2005, "XPPROGRAMMER" <saud_abraham@hotmail.com> wrote:

> just wondering if its ok to overlap constant variables in cobol
> language (OO & CharacterBase)? the listed below code have yielded
> about 98% success rate with very minor odd results. Does this
> approach considered risky to eliminate leading or trailing spaces?
> do you see data corruption risk factor as well?
> would like to hear your thoughts on this. Thanks.

In the olden dayze, IBM's compiler would not handle tables that were big eno
ugh
for many people's use.   So we reserved space and then went outside of table
s:

01    My-Table.
05    My Record pic x(80) occurs 5000.
01    Do-not-move-this
05    filler           pic x(80) occurs 5000.

It was reliable enough to work in many shops, but was vulnerable to a re-com
pile
with an optimizing compiler (which can move things around in working storage
).
Nowadays, we have plenty of room and don't need this.    I recommend that
everybody checks to see if their compiler has a switch to allow for boundary
testing, so that if you go outside of your table, you abort with a boundary
error.   It doesn't cost much and can save you from complicated problems.

If you *really* need to do what you are doing, use redefines and group level
s.

Yes. I was really surprised --- the code is legitimely optimized and
adhering to the language's rules. I am more concerned about
execution thrashing on the compiler's part or possible data loss.
performance wise, the code ran very fast even when the length of
string1 & string2 was modified to pic x(1024) value spaces.

John.

Just so you know, in COBOL there is no guarantee that 2 01-levels that are n
ext
to each other in source code - will actually be next to each other in storag
e.
(In the case of EXTERNAL, they probably will NOT be).  If they are next to e
ach
other, there is also no guarantee what "boundaries" (if any) they will be on
 -
so how many bits/bytes will be between them.

Bottom-Line:
What you code will work exactly how it works - no guarantees that it will
work the same way tomorrow much less with a different compiler (or "fix-leve
l"
of the compiler).

--
Bill Klein
wmklein <at> ix.netcom.com
"XPPROGRAMMER" <saud_abraham@hotmail.com> wrote in message
news:1106938614.280367.156600@z14g2000cwz.googlegroups.com...
> Happy Friday,
>
> just wondering if its ok to overlap constant variables in cobol
> language (OO & CharacterBase)? the listed below code have yielded
> about 98% success rate with very minor odd results. Does this
> approach considered risky to eliminate leading or trailing spaces?
> do you see data corruption risk factor as well?
> would like to hear your thoughts on this. Thanks.
>
> John.
>
> *>--- overlap Right-2-Left  ---------------------*>
>
> 01  String1      Pic X(15) Value "       ABCDEFGH".
> 01  WipeOut      Pic 9(4) comp-5 value 0.
>
> If String1 <> Space
> move 16 to WipeOut
> Perform Until String1(1:1) <> Spaces
> move String1(2:14) To String1(1:14)
> move space to string1(WipeOut - 1:1)
> End-Perform
> end-if.
>
> *>--- overlap Left-2-Right  ---------------------*>
>
> 01  String2      Pic X(15) Value "ABCDEFGH       ".
> 01  WipeOut      Pic 9(4) comp-5 value 0.
>
> If String2 <> Space
> move zeros to WipeOut
> Perform Until String2(15:1) <> Spaces
> move String2(1:14) To String2(2:14)
> move space to string2(WipeOut + 1:1)
> End-Perform
> end-if.
>
> *>------------------------------------------------*>
>

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:c4yKd.339874$f47.64860@news.easynews.com...
> Just so you know, in COBOL there is no guarantee that 2 01-levels that are
next
> to each other in source code - will actually be next to each other in
storage.
> (In the case of EXTERNAL, they probably will NOT be).  If they are next to
each
> other, there is also no guarantee what "boundaries" (if any) they will be
on -
> so how many bits/bytes will be between them.

... and in Unisys MCP COBOL74 you can pretty much guarantee that they
*won't* be next to each other.  Each 01 is a separate block of memory
allocated by the system the first time it's referenced during execution.  If
it happens never to be referenced, it never occupies memory at all.

-Chuck Stevens

XPPROGRAMMER wrote:
> Happy Friday,
>
> just wondering if its ok to overlap constant variables in cobol
> language (OO & CharacterBase)? the listed below code have yielded
> about 98% success rate with very minor odd results. Does this
> approach considered risky to eliminate leading or trailing spaces?
> do you see data corruption risk factor as well?
> would like to hear your thoughts on this. Thanks.

You can hone your code with this technique such that you achieve 99.98%
success. Someday you die.

>
> John.
>
> *>--- overlap Right-2-Left  ---------------------*>
>
> 01  String1      Pic X(15) Value "       ABCDEFGH".
> 01  WipeOut      Pic 9(4) comp-5 value 0.
>
> If String1 <> Space
> move 16 to WipeOut
> Perform Until String1(1:1) <> Spaces
> move String1(2:14) To String1(1:14)
> move space to string1(WipeOut - 1:1)
> End-Perform
> end-if.

This will work, though there are easier ways to do it. Little Used Rule: You
may move a variable to a subset of itself if the receiving starting byte is
to the left of the sending starting byte. Corallary: Those who come after
you will think you mad.

>
> *>--- overlap Left-2-Right  ---------------------*>
>
> 01  String2      Pic X(15) Value "ABCDEFGH       ".
> 01  WipeOut      Pic 9(4) comp-5 value 0.
>
> If String2 <> Space
> move zeros to WipeOut
> Perform Until String2(15:1) <> Spaces
> move String2(1:14) To String2(2:14)
> move space to string2(WipeOut + 1:1)
> End-Perform
> end-if.
>
> *>------------------------------------------------*>

Important Rule: You can't move a variable to itself if the receiving area is
to the right of the sending area.

Because moves are done a byte at a time. When you get to the second byte to
move, it's already been replaced by the 1st byte.

Assume "X" = "ABCDEFbbbb" and you want the result to be "bABCDEFbbb"

Move X(1:) to X(2:) would work IF the machine moved strings as a single
entity. Since compilers generate byte moves, after the first byte move X=
AACDEFbbbb. Then the machine moves the second byte and you get X=AAADEFbbbb
and so on.

Basic Rule: The sending and receiving fields in any operation shall not be
the same. Abuse this rule at your peril - as in
pitchforks-and-torches-peril.

"JerryMouse" <nospam@bisusa.com> wrote in message
news:10vlhg52r4hke45@news.supernews.com...

>  Little Used Rule: You
> may move a variable to a subset of itself if the receiving starting byte
is
> to the left of the sending starting byte.

In some implementations.  In other implementations the hardware instructions
may impose other restrictions or disallow it altogether.  In the case of
Unisys MCP systems, for the results to be predictable with overlapping
operands on such a MOVE, the source and destination "pointers" need to be
more than 8 bytes apart.

One of the reasons this might be a Little Used Rule is that following it
will Hose Your Data if you try it anywhere but the System Upon Which This
Little Used Rule Applies!      ;-)

See aforementioned standards references  ...

-Chuck Stevens

XPPROGRAMMER wrote:
> Happy Friday,
>
> just wondering if its ok to overlap constant variables in cobol
> language (OO & CharacterBase)? the listed below code have yielded
> about 98% success rate with very minor odd results. Does this
> approach considered risky to eliminate leading or trailing spaces?
> do you see data corruption risk factor as well?
> would like to hear your thoughts on this. Thanks.

Are you just dabbling or do you *really* want 100% success. I'm not
going to re-post here, but check M/F Answer Exchange for a message I
posted on "Stringing Examples'. (A slightly earlier version is here if
you check the c.l.c. archives). It uses OO to get rid of 'pre' and
'after' white space. I haven't done any volume tests on it, but would
suggest ACCURACY is more important than speed.

Just to be sure, I changed the program to accept your two versions of
text and it returned a display of 'ABCDEFGH' in both cases, plus the
resulting StringLength of 8 chars.

Jimmy, Calgary AB