Long literals (was: If you were inventing CoBOL...

A slight "clarification" on what Chuck writes below.

There are two separate enhancements in the 2002 Standard that relate to "lon
g
literals"

1) Concatenation operand - uses "&" operator
2) "new-style" quoted literal concatenation, e.g.
"ABC"-
"XYZ"
or
B"01"-
"11"
or
NX"12AB"-
"78EF"

The difference between these two features (both of which are available in bo
th
free and fixed form reference format) is important to understand *IF* one us
es
COPY REPLACING or REPLACE statements.

"ABC" & "XYZ"    *> is 3 text words
while
"ABC"-
"XYZ"   *> is a single text word

***

I certainly would support moving the "old style" quoted literal concatenatio
n to
archaic or obsolete (if done in the 2008 Standard, OBSOLETE would mean that 
it
would be removed from the 201x Standard <G> ).  However, I also think that th
is
is a VERY commonly used feature (especially by code generators and "alien co
de
translators" like the IBM mainframe CICS translator's handling of EXEC CICS
statements.   Therefore, I wouldn't (personally) expect to see it removed fr
om
many compilers in the next decade or so.

--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:ciscsa$2rj8$1@si05.rsvl.unisys.com...
>
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
>  news:rjg1l0lfug8qpt7gh1safepurkvnvqel2j@
4ax.com...
> 
>
> I think it's probably moving that way, given the availability of the
> concatenation operator in 2002 COBOL.  Personally, though, I think limitin
g
> the size of a literal produced by the concatenation operator to 160
> characters, as the 2002 standard does, missed the boat.
> 
>
> I have.  I think concatenation is an improvement, but I also think the
> 160-character limit on literals causes some coding challenges.
> 
>
> Mostly those "ways around it" involved declaring data items.
>
> Here's one that involves both continuation and substitution of data spaces
:
>    INSPECT identifer-1 CONVERTING literal-4 TO literal-5
> where literal-4 and literal-5 each represents the characters in an 8-bit
> character set.
>
> If it were a 7-bit character set in '74 or '85 COBOL you'd still have to u
se
> continuation to build the literals (you could use the concatenation operat
or
> in 2002 COBOL).  But the maximum size of a literal is still 160 characters
> in 2002 COBOL, so representing the full 256-character set in a single
> literal is prohibited.
>
> This particular construct is one of the reasons for the proposal to increa
se
> the maximum size of an alphanumeric or national literal in the 2008 draft.
>
> If the implementor was able to make proper use of the "structured constant
"
> mechanism also proposed for the 2008 draft, it's possible that
>    INSPECT identifier-1 CONVERTING structured-constant-1 TO
> structured-constant-2
> could be done with no more overhead than the literal-to-literal case, but
> unless that's the case if you're going to avoid continuation there's almos
t
> certainly going to be two instantiations of each of the character sets
> somewhere in the program memory!
>
>    -Chuck Stevens
>
>

typo

> 2) "new-style" quoted literal concatenation, e.g.

should have been

> 2) "new-style" quoted literal continuation, e.g.

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:oLm4d.1886960$y4.325077@news.easynews.com...
>A slight "clarification" on what Chuck writes below.
>
> There are two separate enhancements in the 2002 Standard that relate to "l
ong
> literals"
>
> 1) Concatenation operand - uses "&" operator
> 2) "new-style" quoted literal concatenation, e.g.
>      "ABC"-
>      "XYZ"
>            or
>      B"01"-
>        "11"
>              or
>       NX"12AB"-
>            "78EF"
>
> The difference between these two features (both of which are available in 
both
> free and fixed form reference format) is important to understand *IF* one 
uses
> COPY REPLACING or REPLACE statements.
>
>   "ABC" & "XYZ"    *> is 3 text words
>        while
>   "ABC"-
>  "XYZ"   *> is a single text word
>
> ***
>
> I certainly would support moving the "old style" quoted literal concatenat
ion
> to archaic or obsolete (if done in the 2008 Standard, OBSOLETE would mean 
that
> it would be removed from the 201x Standard <G> ).  However, I also think th
at
> this is a VERY commonly used feature (especially by code generators and "a
lien
> code translators" like the IBM mainframe CICS translator's handling of EXE
C
> CICS statements.   Therefore, I wouldn't (personally) expect to see it rem
oved
> from many compilers in the next decade or so.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:ciscsa$2rj8$1@si05.rsvl.unisys.com... 
>
>

typo

> 2) "new-style" quoted literal concatenation, e.g.

should have been

> 2) "new-style" quoted literal continuation, e.g.

--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:oLm4d.1886960$y4.325077@news.easynews.com...
>A slight "clarification" on what Chuck writes below.
>
> There are two separate enhancements in the 2002 Standard that relate to "l
ong
> literals"
>
> 1) Concatenation operand - uses "&" operator
> 2) "new-style" quoted literal concatenation, e.g.
>      "ABC"-
>      "XYZ"
>            or
>      B"01"-
>        "11"
>              or
>       NX"12AB"-
>            "78EF"
>
> The difference between these two features (both of which are available in 
both
> free and fixed form reference format) is important to understand *IF* one 
uses
> COPY REPLACING or REPLACE statements.
>
>   "ABC" & "XYZ"    *> is 3 text words
>        while
>   "ABC"-
>  "XYZ"   *> is a single text word
>
> ***
>
> I certainly would support moving the "old style" quoted literal concatenat
ion
> to archaic or obsolete (if done in the 2008 Standard, OBSOLETE would mean 
that
> it would be removed from the 201x Standard <G> ).  However, I also think th
at
> this is a VERY commonly used feature (especially by code generators and "a
lien
> code translators" like the IBM mainframe CICS translator's handling of EXE
C
> CICS statements.   Therefore, I wouldn't (personally) expect to see it rem
oved
> from many compilers in the next decade or so.
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Chuck Stevens" <charles.stevens@unisys.com> wrote in message
> news:ciscsa$2rj8$1@si05.rsvl.unisys.com... 
>
>