For Programmers: Free Programming Magazines  


Home > Archive > Cobol > April 2004 > replace statement and free format









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author replace statement and free format
Herwig Huener

2004-04-26, 11:31 pm

2004-04-26 15:07:00 MEST

I have implemented free format in the
BS2000 COBOL Compiler. What's still
missing is the use of the "replace"
statement in free format, on which I
work now. Now we found a few points
which are not quite clear from the
COBOL-Standard.

Consider a replace-statement given
in fixed format, and it is used
in a part of the code where free
format is in effect. As far as the
generation of code is concerned, there
is no problem, because the Standard
says, everything should be converted
to free format, or a compiler should
behave as if he actually did this.

But what shall be the effect on the
listing? As this is implementor-defined,
one should ask the COBOL community about
the best way.

An example:

....
....
....

replace ==q== by ==add 1 to r. display "1
- "2
- "3
- "4
- "5
- "67
- "8
- "901
- "2
- "34
- "5
- "67
- "8
- "90
- "1
- "234
- "5678901234
- "56
- "78
- "90
- "12
- "34
- "567890123456789
-"0" upon tv. add 1 to s.==.
[color=darkred]

*> The next line has a length of 255:
q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q
q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q
q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q
q q q q q q q q q q q q q
[color=darkred]

....
....
....

End of this example.

Now, for the purpose of a listing, shall the replace-text be
converted to free format, shall the replace be applied and
the result be wraped around because the resulting line has
a length of a few thousand characters?

Or shall the replace-text be taken as it is, repeatedly
replaced into the "... q q q q ..." line, thus providing
a sort of fixed-format code in a place where actually
free format is in effect?

A third serious suggestion I have heard is that the
compiler inserts brackets of[color=darkred]
in such cases, maybe properly marked as compiler-generated.

Should a compiler generate a warning when crossover
- replaces are used?

One may find good reasons for any of these strategies.

Confused. Herwig


Rick Smith

2004-04-26, 11:31 pm


Herwig Huener <Herwig.Huener@fujitsu-siemens.com> wrote in message
news:c6j1j7$eb8$1@nntp.fujitsu-siemens.com...
> 2004-04-26 15:07:00 MEST
>
> I have implemented free format in the
> BS2000 COBOL Compiler. What's still
> missing is the use of the "replace"
> statement in free format, on which I
> work now. Now we found a few points
> which are not quite clear from the
> COBOL-Standard.
>
> Consider a replace-statement given
> in fixed format, and it is used
> in a part of the code where free
> format is in effect. As far as the
> generation of code is concerned, there
> is no problem, because the Standard
> says, everything should be converted
> to free format, or a compiler should
> behave as if he actually did this.
>
> But what shall be the effect on the
> listing? As this is implementor-defined,
> one should ask the COBOL community about
> the best way.
>
> An example:
>
> ...
> ...
> ...
>
> replace ==q== by ==add 1 to r. display "1
> - "2
> - "3
> - "4
> - "5
> - "67
> - "8
> - "901
> - "2
> - "34
> - "5
> - "67
> - "8
> - "90
> - "1
> - "234
> - "5678901234
> - "56
> - "78
> - "90
> - "12
> - "34
> - "567890123456789
> -"0" upon tv. add 1 to s.==.
>
>
> *> The next line has a length of 255:
> q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q

q
> q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q

q
> q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q

q
> q q q q q q q q q q q q q
>
>
> ...
> ...
> ...
>
> End of this example.
>
> Now, for the purpose of a listing, shall the replace-text be
> converted to free format, shall the replace be applied and
> the result be wraped around because the resulting line has
> a length of a few thousand characters?


No. One reason a programmer would use continuation lines
in replacing text is to make such lines visually distinguishable.
Wrapping the text destroys that which is visually distinguishable.

> Or shall the replace-text be taken as it is, repeatedly
> replaced into the "... q q q q ..." line, thus providing
> a sort of fixed-format code in a place where actually
> free format is in effect?


Yes. This maintains the visual distinguishability of the text.

> A third serious suggestion I have heard is that the
> compiler inserts brackets of
> in such cases, maybe properly marked as compiler-generated.


This is important where the source listing, when written
to a file, may be resubmitted to the compiler. That is, if
page headings, COPY statements, REPLACE statements,
etc., are made comments in the listing, the remaining
original, copied, and replaced lines may then be resubmitted
to the compiler to produce the same resulting executable as
the original source. I believe Micro Focus had (and may still
have) that capability; though I never had reason to use it.

> Should a compiler generate a warning when crossover
> - replaces are used?


Sure, why not.



William M. Klein

2004-04-26, 11:31 pm

Herwig (and group),
There are some (medium good) reasons that the Standard (2002 AND earlier)
doesn't say much about "listings". Most importantly because their are both
historical and current reasons why programmers in one environment expect/want
VERY different things than those in other situations. Before giving some
opinions on your specific questions, let me outline why this is even more of a
problem that you state below.

For those who don't know, the Standard has never even required (and still
doesn't) that a vendor PRODUCE a compile-time listing of the source code. In
the 2002 Standard, there is some new stuff (Directive and option on the COPY
statement) that allows one to turn off listing *if* the vendor produces any at
all - but other than that, it is pretty quiet.

Issues:

1) Free form reference format allows for each source line to have 255 characters
*NOT* "bytes". Therefore, if every other character on your line is UCS-4 while
the others are single byte alphanumeric *and* you need a single byte between
changes of character sets, you could have 255 x 7 = 1785 bytes on a single line
of source code.!!! Now tell me what medium is "good" for display such a line <G>

2) I can think of (at least) 3 reasons why programmers would want "listings" -
and each of these would "suggest" different answers to how you would want your
listings to appear.

A) for "finding and fixing" compiler errors (and warnings)
B) for "finding and fixing" run-time errors
C) for "audit trails" and "researching" existing production programs

3) I was surprised when I was working on the 2002 Standard that neither the old
or the new Standard said anything about what to put in listings when a
REPLACING/REPLACE took place. Should it show the "original" source code or the
"derived" source code. I was even MORE surprised (because I was used to one way
of doing this) that there actually ARE some current compilers that work each
way - and for each way of working, the users are CONVINCED that "their way" is
best.

4) One of the "design" points of the new free form reference format is that it
is POSSIBLE to create valid source code that will compile with EITHER free or
fixed form reference format - so that such source code can be used in COPY
members - without modification. This is possible if you obey the following
rules:

A) only include source code between column 8 and the R-margin (whatever it is
in your compiler)
B) use the new (rather than old) methods for alphanumeric (and national)
literal continuation
C) use directives (not old fashion) debugging indicators, comment indicators,
and page eject directives
D) never continue a COBOL word across lines
E) do not put any data (comments) between the R-margin and end-of-source-line
(Columns 73-80 in many existing implementations)

***

Given what I have said above, the following is what I would like to see from a
vendor in the "best of all possible worlds"

1) Provide two "basic" options for listings:
- for compiler error fixing (showing code exactly as entered)
- for run-time debugging (showing "derived" source code after
REPLACE/REPLACING

2) For "source code" listing
- do NOT show source code AFTER replace/replacing (or if you do - show it as
comments). This will get "correct" line numbers and show the programmer EXACTLY
what they entered.
- Provide two suboptions: One for source code that is ALL in fixed form
reference format (and will print/display in a "standard length" medium - and
another method for free format reference format or mixed reference format -
where you will have to figure out what to do with VERY long lines (up to 1785
bytes as listed above - or even longer if you use different UTF/UCS national
character sets).
- Depending on how many "passes" your compiler does of source code, either
issue an error message or a warning message if the programmer SAYS their source
code is all "fixed format" but they actually include some free format source
code. (If your compiler does multiple passes, you should be able to turn on the
"free format" listing even if they told you it was all fixed format reference
format)

3) For run-time debugging - show the code in FREE FORMAT reference format always
and after REPLACE/REPLACING (i.e convert it to the "restricted" format that I
described above, e.g. using new-style continuation and directives rather than
column-7 "stuff). You may want to give the programmer a "choice" of how long
you want each listing line to be - only as long as your "R-Margin" fixed format
is - or say 132 (for a typical "old-style" printer) or some length that looks
"good" on a screen in your environment.

4) If your current ('85 Standard) compiler shows listings AFTER doing
REPLACE/REPLACING, then you should give the programmer a choice of whether they
want to have the listing show before (with after as a comment) - or after (with
before as a comment) - or just one or the other. Personally, I can see
advantages and divantages (for fixing compile-time errors) with either
approach.

***

I know that the "recommendations" (personal opinions) given above might be a LOT
of work for a vendor, but I think it would "pay off" in the long run in doing
both compile-time and run-time "fixes".

Let me know if any of this isn't clear.

--
Bill Klein
wmklein <at> ix.netcom.com
"Herwig Huener" <Herwig.Huener@fujitsu-siemens.com> wrote in message
news:c6j1j7$eb8$1@nntp.fujitsu-siemens.com...
> 2004-04-26 15:07:00 MEST
>
> I have implemented free format in the
> BS2000 COBOL Compiler. What's still
> missing is the use of the "replace"
> statement in free format, on which I
> work now. Now we found a few points
> which are not quite clear from the
> COBOL-Standard.
>
> Consider a replace-statement given
> in fixed format, and it is used
> in a part of the code where free
> format is in effect. As far as the
> generation of code is concerned, there
> is no problem, because the Standard
> says, everything should be converted
> to free format, or a compiler should
> behave as if he actually did this.
>
> But what shall be the effect on the
> listing? As this is implementor-defined,
> one should ask the COBOL community about
> the best way.
>
> An example:
>
> ...
> ...
> ...
>
> replace ==q== by ==add 1 to r. display "1
> - "2
> - "3
> - "4
> - "5
> - "67
> - "8
> - "901
> - "2
> - "34
> - "5
> - "67
> - "8
> - "90
> - "1
> - "234
> - "5678901234
> - "56
> - "78
> - "90
> - "12
> - "34
> - "567890123456789
> -"0" upon tv. add 1 to s.==.
>
>
> *> The next line has a length of 255:
> q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q
> q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q
> q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q
> q q q q q q q q q q q q q
>
>
> ...
> ...
> ...
>
> End of this example.
>
> Now, for the purpose of a listing, shall the replace-text be
> converted to free format, shall the replace be applied and
> the result be wraped around because the resulting line has
> a length of a few thousand characters?
>
> Or shall the replace-text be taken as it is, repeatedly
> replaced into the "... q q q q ..." line, thus providing
> a sort of fixed-format code in a place where actually
> free format is in effect?
>
> A third serious suggestion I have heard is that the
> compiler inserts brackets of
> in such cases, maybe properly marked as compiler-generated.
>
> Should a compiler generate a warning when crossover
> - replaces are used?
>
> One may find good reasons for any of these strategies.
>
> Confused. Herwig
>
>



Herwig Huener & Josella Simone Playton

2004-04-26, 11:31 pm

2004-04-26 23:59:00 MEST - approaching midnight

William M. Klein wrote:

> ...


> Let me know if any of this isn't clear.


William,

thanks for your detailed answer. We will discuss
those views in the team. One should have made up one's
mind about what to implement in the requirement phase -
but in a language like COBOL, there are so many
ramifications that one could overlook things quite
easily (as it has been, in ancient times, the
case with Ada also).

I found the program-example which I outlined above
just by fooling around with our existing compiler
without any evil intent.

I coined the word "crossover-replace" for the described
situation, but I do not know whether that sounds right
for the ears of English speaking COBOL-Programmers. The
German equivalent "kreuzweise Ersetzung" sounds
funny, somehow.

Herwig

--
Herwig Huener http://www.quantenrente.de +49
Josella Simone http://www.Josella-Simone-Playton.de 8095
Playton webmaster!@!Herwig-Huener.de 2230
GruberStrasse 10 A / D-85655 GrossHelfenDorf / Bayern / EU

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com