Cobol - Perfrom Thru

Author

Perfrom Thru

Kannan

2004-03-26, 10:59 pm

I have a doubt in the statement "perform thru" in cobol.

say for example consisder this statement:

perform 001-start thru 005-end-exit.

My doubt is whether this statement above would execute the code
present 001-start and 005-end-exit procedures alone, or would execute
any para in between this two paras. Please clarify on this.

Thanks in advenace.

Arnold Trembley

2004-03-26, 10:59 pm

Kannan wrote:
> I have a doubt in the statement "perform thru" in cobol.
>
> say for example consisder this statement:
>
> perform 001-start thru 005-end-exit.
>
> My doubt is whether this statement above would execute the code
> present 001-start and 005-end-exit procedures alone, or would execute
> any para in between this two paras. Please clarify on this.
>
> Thanks in advenace.

All paragraphs between 001-start and 005-end-exit, inclusive, would be
executed, unless a GO TO statement forces a program branch to some
other label. Branching to another label outside the perform thru
range is a very dangerous thing to do.

Branching into a perform thru range without performing it is also a
very dangerous thing to do.

--
http://arnold.trembley.home.att.net/

docdwarf@panix.com

2004-03-26, 10:59 pm

In article <49f7d61d.0403142339.1c3c17df@posting.google.com>,
Kannan <thamarai_k2001@yahoo.co.in> wrote:
>I have a doubt in the statement "perform thru" in cobol.
>
>say for example consisder this statement:
>
>perform 001-start thru 005-end-exit.
>
>My doubt is whether this statement above would execute the code
>present 001-start and 005-end-exit procedures alone, or would execute
>any para in between this two paras. Please clarify on this.

Please do your own homework.

DD

Robert Jones

2004-03-26, 10:59 pm

thamarai_k2001@yahoo.co.in (Kannan) wrote in message news:<49f7d61d.0403142339.1c3c17df@posting.google.com>...
> I have a doubt in the statement "perform thru" in cobol.
>
> say for example consisder this statement:
>
> perform 001-start thru 005-end-exit.
>
> My doubt is whether this statement above would execute the code
> present 001-start and 005-end-exit procedures alone, or would execute
> any para in between this two paras. Please clarify on this.
>
> Thanks in advenace

The manuals for your compiler should explain this for you, for most
compilers, they are either supplied as hardcopy and/or as viewable
files, if you can't find them, most suppliers also have websites where
you can look at the manuals directly or download them for offline
viewing.

A "perform thru" performs all statement in all procedures between the
first and the second according to the logical flow of the statements.
I.e., it starts with the first statement in the first named procedure
and ends at the last statement in the second named procedure. It is
up to you to ensure that you don't GO TO or PERFORM anywhere else and
not come back.

Lueko Willms

2004-03-26, 10:59 pm

Am 15.03.04
schrieb arnold.trembley@worldnet.att.net (Arnold Trembley)
auf /COMP/LANG/COBOL
in 7Nd5c.25024$H44.469823@bgtnsc04-news.ops.worldnet.att.net
ueber Re: Perfrom Thru

AT> All paragraphs between 001-start and 005-end-exit, inclusive, would
AT> be executed, unless a GO TO statement forces a program branch to some
AT> other label. Branching to another label outside the perform thru
AT> range is a very dangerous thing to do.

That's why I never use PERFORM _THRU,_ and apply PERFORM only on
SECTIONs, not Paragraphs, and prefer to use "inline"-PERFORM, and IF
... ELSE .. END-IF.

After COBOL-85 came into being, there should be no more need to do
otherwise.

And a GO TO should never be used without a corresponding
COME FROM...

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt." - Leo Trotzki (27. Januar 1932)

JerryMouse

2004-03-26, 10:59 pm

Ken Grubb

2004-03-26, 10:59 pm

JerryMouse wrote:

>I notice you are corresponding from India.

PERFORM ... THRU ... must not have been covered in the Outsourcing
documentation.

Ken Grubb
Lower Paxton Twp, PA

Joe Zitzelberger

2004-03-26, 10:59 pm

In article <49f7d61d.0403142339.1c3c17df@posting.google.com>,
thamarai_k2001@yahoo.co.in (Kannan) wrote:

> I have a doubt in the statement "perform thru" in cobol.
>
> say for example consisder this statement:
>
> perform 001-start thru 005-end-exit.
>
> My doubt is whether this statement above would execute the code
> present 001-start and 005-end-exit procedures alone, or would execute
> any para in between this two paras. Please clarify on this.
>
> Thanks in advenace.

It will execute all of the code between the label 001-START and
005-END-EXIT.

However, it is a dangerous construct with plenty of hazards associated
with its use.

If you want to perform all the paragraphs in a range, my suggestion is
that you explicitly code a perform for each paragraph you want executed,
e.g:

PERFORM 001-START
PERFORM 002-DO-SOMETHING
PERFORM 003-DO-OTHER-THING
PERFORM 004-DO-LAST-THING
PERFORM 005-END-EXIT

instead of:

PERFORM 001-START THRU 005-END-EXIT

And please don't let the xenophobes bother you -- many people think
highly of India.

Regards,

Joe

berlutte@sympatico.ca

2004-03-26, 10:59 pm

On 15 Mar 2004 05:08:31 -0500, docdwarf@panix.com wrote:

>Please do your own homework.

Some are looking at skilled others who did:

http://sfgate.com/cgi-bin/article.c...MNG905K1BC1.DTL

Washington -- The government is taking the first steps toward a
targeted military draft of Americans with special skills in computers
and foreign languages.
========================================
============
What an happy ending, old bernouilli!

Except if they outsource the lot, of course!

Clever, nay?

Pierra

2004-03-26, 10:59 pm

Comments embedded below, CAPS for clarity and emphasis only, no shouting
intended. - Dick

Lueko Willms wrote:

><snp>

>
> That's why I never use PERFORM _THRU,_ and apply PERFORM only on
> SECTIONs, not Paragraphs, and prefer to use "inline"-PERFORM, and IF
> .. ELSE .. END-IF.
>
I disagree (IMHO) in that the PERFORM_THRU provides a very clear
definition of what you want to do. Having said that, a PERFORM
1000-START THROUGH 5000-EXIT is one of the confusing and improper things
to do. Should be PERFORM 1000-START THRU 1000-EXIT ONLY! The only
labels (and, if necessary GO TO's ) in the paragraph should be things
like 1000-CONTINUE or 1000-GROUP-BYPASS.

Remember, CLARITY is the MAJOR benefit for many coding techniques. You
want to insure that anyone can read, understand, and modify your code
when necessary.

Also, of prime importance, NEVER change styles in a program you are
modifying, unless you are COMPLETELY rewriting the program. Mixing and
mixing PERFORM_THRU and PERFORM's in the same program can give you more
headaches than you ever want.

> After COBOL-85 came into being, there should be no more need to do
> otherwise.
>
> And a GO TO should never be used without a corresponding
> COME FROM...
>
>
> Yours,
> Lüko Willms http://www.mlwerke.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> "Die Interessen der Nation lassen sich nicht anders formulieren als unter
> dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
> Herrschaft anstrebt." - Leo Trotzki (27. Januar 1932)

Howard Brazee

2004-03-26, 10:59 pm

On 15-Mar-2004, Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:

> If you want to perform all the paragraphs in a range, my suggestion is
> that you explicitly code a perform for each paragraph you want executed,
> e.g:
>
> PERFORM 001-START
> PERFORM 002-DO-SOMETHING
> PERFORM 003-DO-OTHER-THING
> PERFORM 004-DO-LAST-THING
> PERFORM 005-END-EXIT
>
> instead of:
>
> PERFORM 001-START THRU 005-END-EXIT

Note: The old style of coding that did PERFORM 001-START thru 0005-END-EXIT
typically had code in it that said GO TO 005-END-EXIT.

This error-prone code could not be replaced directly by your series of performs.

docdwarf@panix.com

2004-03-26, 10:59 pm

In article <adE5c.6067$GQ3.1971@newsread3.news.atl.earthlink.net>,
Pierra <pierra@sprynet.com> wrote:
>Comments embedded below, CAPS for clarity and emphasis only, no shouting
>intended. - Dick
>
>Lueko Willms wrote:
>
>
>I disagree (IMHO) in that the PERFORM_THRU provides a very clear
>definition of what you want to do. Having said that, a PERFORM
>1000-START THROUGH 5000-EXIT is one of the confusing and improper things
>to do. Should be PERFORM 1000-START THRU 1000-EXIT ONLY! The only
>labels (and, if necessary GO TO's ) in the paragraph should be things
>like 1000-CONTINUE or 1000-GROUP-BYPASS.

Well, here we are, back in the Thru/noTHRU debate. As has been stated
before... all decent, sane, attractive and appropriately-scented coders
write only PERFORM PARAGRAPH-NAME THRU PARAGRAPH-NAME-EXIT, allowing for a
GO TO directing execution to the paragraph name immediately preceding or
immediately following the instruction.

>
>Remember, CLARITY is the MAJOR benefit for many coding techniques. You
>want to insure that anyone can read, understand, and modify your code
>when necessary.

Clarity is, I believe, in the mind of the beholder... and don't worry, no
matter what you code the odds are that someone later will blame your style
for their difficulties.

>
>Also, of prime importance, NEVER change styles in a program you are
>modifying, unless you are COMPLETELY rewriting the program. Mixing and
>mixing PERFORM_THRU and PERFORM's in the same program can give you more
>headaches than you ever want.

Yes... and no. Consistency is good, true, but a 'foolish consistency is
the petty hobgoblin of little minds' (Emerson) ; consider the example of a
program written in ANSI '74 style but now being compiled under, say,
Enterprise COBOL for z/OS and OS/390... one can, with suitable care, use
scope delimiters and inline PERFORMS to great advantage.

DD

Joe Zitzelberger

2004-03-26, 11:00 pm

In article <c3745i$19q$1@peabody.colorado.edu>,
"Howard Brazee" <howard@brazee.net> wrote:

> On 15-Mar-2004, Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:
>
>
> Note: The old style of coding that did PERFORM 001-START thru 0005-END-EXIT
> typically had code in it that said GO TO 005-END-EXIT.
>
> This error-prone code could not be replaced directly by your series of
> performs.

I thought the original question was about a new perform construct. As
such, it could be easily written to use the alternative suggested style.

My position on the frivolous use of the GO TO statement is well
documented, there is no need to rehash that one again.

Howard Brazee

2004-03-26, 11:00 pm

On 16-Mar-2004, Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:

> I thought the original question was about a new perform construct. As
> such, it could be easily written to use the alternative suggested style.
>
> My position on the frivolous use of the GO TO statement is well
> documented, there is no need to rehash that one again.

Except that the only reason to use PERFORM THRU is because one is in an old shop
that uses PERFORM THRU. Otherwise, the coder should move up to the 1970's when
the late comers finally moved to structured programming.

If I see PERFORM THRU, then I expect to see GO TO as well. I might luck out
and it's only GO TO XXX-EXIT. But I might not.

I don't know if I have ever seen a program that had PERFORM THRU without GO TO.
Such a style does not seem likely to me.

Richard

2004-03-26, 11:00 pm

Pierra <pierra@sprynet.com> wrote

> I disagree (IMHO) in that the PERFORM_THRU provides a very clear
> definition of what you want to do. Having said that, a PERFORM
> 1000-START THROUGH 5000-EXIT is one of the confusing and improper things
> to do. Should be PERFORM 1000-START THRU 1000-EXIT ONLY!

That is just one of the problems that occurs with PERFORM TRHU. It
may be that the 1000-Exit was meant but was coded incorrectly. The
program may still appear to work (mostly) if 5000-Exit is later in the
program than 1000-Start, the code between 1000-Exit and 5000-Exit
being executed inadvertantly. Depending on what this code is it may
not be noticed that it is being executed, the damage being only minor
- mostly.

> The only
> labels (and, if necessary GO TO's ) in the paragraph should be things
> like 1000-CONTINUE or 1000-GROUP-BYPASS.

The _only_ rational point of having labels between 1000-Start and the
end of 1000-Exit is to allow GO TOs. It is trivially easy to avoid
using GO TOs. Therefore it is trivially easy to eliminate the
spurious labels and just have a PERFORM without THRU.

> Remember, CLARITY is the MAJOR benefit for many coding techniques. You
> want to insure that anyone can read, understand, and modify your code
> when necessary.

Eliminating GO TOs, labels and THRU is a major component of improving
clarity and readability.

> Also, of prime importance, NEVER change styles in a program you are
> modifying, unless you are COMPLETELY rewriting the program. Mixing and
> mixing PERFORM_THRU and PERFORM's in the same program can give you more
> headaches than you ever want.

Absolutely.

Chuck Stevens

2004-03-26, 11:00 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0403161226.683b687e@posting.google.com...

> The _only_ rational point of having labels between 1000-Start and the
> end of 1000-Exit is to allow GO TOs. It is trivially easy to avoid
> using GO TOs. Therefore it is trivially easy to eliminate the
> spurious labels and just have a PERFORM without THRU.

Not necessarily; I know of one other "rational" point for such.

There is (at least) one implementation in which it may be necessary to
insert unreferenced labels in the program to avoid exceeding any
architectural limits that might be encountered for extremely large (in terms
of generated object code, as distinct from source lines) paragraphs.

In such instances, if the existing paragraph is directly PERFORMed, the
program will break if it becomes necessary to insert a new paragraph.
PERFORM <section-name> as well as PERFORM ... THRU will continue to work
without problems.

If a paragraph has to be added to avoid such a limit and the existing
paragraph is PERFORMed without THRU, the easiest correction is to change
PERFORM to PERFORM ... THRU, in which instance I'd suggest adding an
unambiguous <original-paragraph-name>-EXIT paragraph as well, and use that
as the terminus.

-Chuck Stevens

Richard

2004-03-26, 11:00 pm

"Chuck Stevens" <charles.stevens@unisys.com> wrote

[color=darkred]
> Not necessarily; I know of one other "rational" point for such.

> There is (at least) one implementation in which it may be necessary to
> insert unreferenced labels in the program to avoid exceeding any
> architectural limits that might be encountered for extremely large (in terms
> of generated object code, as distinct from source lines) paragraphs.

Was that on DOS perhaps ?

> In such instances, if the existing paragraph is directly PERFORMed, the
> program will break if it becomes necessary to insert a new paragraph.

What exactly do you mean by 'insert a new paragraph' in the context of
'an existing paragraph' ? I assume that you mean a pargraph label.

> PERFORM <section-name> as well as PERFORM ... THRU will continue to work
> without problems.

And so, no doubt, would using sensible sized pargraphs in a more
modular way, each of which is performed without thru or sections.

> If a paragraph has to be added to avoid such a limit and the existing
> paragraph is PERFORMed without THRU, the easiest correction is to change
> PERFORM to PERFORM ... THRU, in which instance I'd suggest adding an
> unambiguous <original-paragraph-name>-EXIT paragraph as well, and use that
> as the terminus.

And I would suggest not doing that, but instead breaking the code down
into more easily grasped functional parts that are performed
separately. But then who am I to preach about this, I have written a
single paragraph that contained a single EVALUATE that ran to over
1500 lines. ;-)

(it was a Windows callback)

Lueko Willms

2004-03-26, 11:00 pm

Am 16.03.04
schrieb charles.stevens@unisys.com (Chuck Stevens)
bei /COMP/LANG/COBOL
in c37t1c$1moq$1@si05.rsvl.unisys.com
ueber Re: Perfrom Thru

CS> There is (at least) one implementation in which it may be necessary
CS> to insert unreferenced labels in the program to avoid exceeding any
CS> architectural limits that might be encountered for extremely large
CS> (in terms of generated object code, as distinct from source lines)
CS> paragraphs.

Which compiler did that? I see that you work at the company where I
did all my COBOL work...

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)

Howard Brazee

2004-03-26, 11:00 pm

On 16-Mar-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> There is (at least) one implementation in which it may be necessary to
> insert unreferenced labels in the program to avoid exceeding any
> architectural limits that might be encountered for extremely large (in terms
> of generated object code, as distinct from source lines) paragraphs.
>
> In such instances, if the existing paragraph is directly PERFORMed, the
> program will break if it becomes necessary to insert a new paragraph.
> PERFORM <section-name> as well as PERFORM ... THRU will continue to work
> without problems.

It's easy enough to replace hunks of such code with PERFORMs of new paragraphs.

Chuck Stevens

2004-03-26, 11:00 pm

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0403161909.163cfb11@posting.google.com...

>
terms[color=darkred]
>
> Was that on DOS perhaps ?

No.

>
>
> What exactly do you mean by 'insert a new paragraph' in the context of
> 'an existing paragraph' ? I assume that you mean a pargraph label.

Yes, in the *middle* of the source text for the existing paragraph, turning
it into two paragraphs.

work[color=darkred]
>
> And so, no doubt, would using sensible sized pargraphs in a more
> modular way, each of which is performed without thru or sections.

The problem comes when what seems like a reasonably-sized paragraph at the
source level generates huge quantities of code. I have seen program
listings that included representations of the generated object code that
occupied scores of pages for a single STRING, UNSTRING and INSPECT
statement. Moreover, I've seen the object code requirements for a test of
an 88-level item more than double when the item to which the 88-level refers
is increased in size by a single character, with no change to the procedural
source code.

that[color=darkred]
>
> And I would suggest not doing that, but instead breaking the code down
> into more easily grasped functional parts that are performed
> separately.

If you have time, that's fine. If you have a production program that has to
be live in the next ten minutes, you may not have that luxury. The idea
here is making the minimum change that will allow the program to compile and
run reliably.

-Chuck Stevens

Chuck Stevens

2004-03-26, 11:00 pm

Unisys ClearPath MCP/AS COBOL74 (and the now-no-longer-supported COBOL(68)).
The architectural limit for an object code segment on this system is 8192
words, or 49,152 bytes. The COBOL74 compiler segments Procedure Division
code unconditionally at the SECTION level, and optionally at the paragraph
level, but never, ever can the code generated for a paragraph exceed that
limit.

I once saw a complaint from a user that changing the DATA DIVISION code
caused a Code Segment Limit syntax error in Procedure Division code. Turns
out the user had increased the size of a single data item from three to nine
characters. That data item had some 35 88-level items associated with it,
most of which were multi-valued, and many of which had THRU clauses. This
dramatically increased the object code generated for what at the source
level was a simple IF statement, but at the object code level required a
number of comparisons; the increase was sufficient to cause code segment
overflows in a number of places in the program. Note that this is a syntax
error requiring programmer correction, not a compiler error.

Unisys MCP/AS COBOL85 uses an entirely different algorithm for code
segmentation and does not encounter this issue.

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9519fn7uflB@jpberlin-l.willms.jpberlin.de...
> Am 16.03.04
> schrieb charles.stevens@unisys.com (Chuck Stevens)
> bei /COMP/LANG/COBOL
> in c37t1c$1moq$1@si05.rsvl.unisys.com
> ueber Re: Perfrom Thru
>
> CS> There is (at least) one implementation in which it may be necessary
> CS> to insert unreferenced labels in the program to avoid exceeding any
> CS> architectural limits that might be encountered for extremely large
> CS> (in terms of generated object code, as distinct from source lines)
> CS> paragraphs.
>
> Which compiler did that? I see that you work at the company where I
> did all my COBOL work...
>
>
> Yours,
> Lüko Willms http://www.mlwerke.de
> /--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --
>
> "Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
> Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c39uqu$1sd$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:

[snip]

>The problem comes when what seems like a reasonably-sized paragraph at the
>source level generates huge quantities of code. I have seen program
>listings that included representations of the generated object code that
>occupied scores of pages for a single STRING, UNSTRING and INSPECT
>statement. Moreover, I've seen the object code requirements for a test of
>an 88-level item more than double when the item to which the 88-level refers
>is increased in size by a single character, with no change to the procedural
>source code.

Ahhhhh, for the Oldene Dayse! Mr Stevens, my experience is with IBM
mainframe compilers... but the change there from IKFCBL00 to IGYCRCTL
changed how things compiled. STRING/UNSTRING and INSPECT used to be
*very* expensive... but now are less so, or at least apparently less so.
A statement like

STRING FLD1(3:2), FLD2, FLD3 DELIMITED BY SIZE INTO FLD4

.... creates the assembley equivalent of:

L 5,92(0,9) TGTFIXD+92
L 15,152(0,5) V(IGZCSTG )
LA 1,3717(0,4) PGMLIT AT +19493
BALR 14,15

.... and notice how all the ... unpleasantness is now hidden in a call to
IGZCSTG. INSPECTs are even more curious...

INSPECT FLDA REPLACING ALL 'AMB' BY 'ZML'

.... gives:

L 15,68(0,5) V(IGZCIN1 )
LA 1,3664(0,4) PGMLIT AT +19440
BALR 14,15

.... showing a call of subrtn IGZCIN1, while

INSPECT FLDA REPLACING ALL 'A' BY 'Q'

....gives:

L 6,440(0,9) BLF=10
TR 0(160,6),317(4) FLDA

.... where TR is, of course, the TRanslate intruction. This seques nicely
into the observation about code requirements increasing when the size of a
data-item which is 88'd is increased; a single-character 88 results in a
CLI where multi-character ones generate at least a CLC.

(I recall reading someplace - the Murach book? - that a CLC is three times
as expensive as a CLI... and this is why All Good Programmers, when given
a choice, keep frequently-addressed 88s to a single character.)

[snip]

>If you have time, that's fine. If you have a production program that has to
>be live in the next ten minutes, you may not have that luxury.

Hmmmmm... a classic example of the 'round too-it' philosophy... 'just
patch the fool thing and get it into Production, we'll Fix It Right when
we get around to it'.

>The idea
>here is making the minimum change that will allow the program to compile and
>run reliably.

As many know, Mr Stevens, a program which makes it through any given run
and gives accurate results may not be 'reliable'... the bug that you
patched over may well be lurking under the surface, waiting for tomorrow's
keyboarding error to bring the region down, hard. The question becomes
one of short-term versus long term: 'How much time does a coder spend
making sure that the program is made long-term reliable?'

(ans: as long as the person who signs the timesheet permits, of course)

DD

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c39vmh$2kr$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>Unisys ClearPath MCP/AS COBOL74 (and the now-no-longer-supported COBOL(68)).

Ahh... in my other posting I mentioned IKFCBL00; that was the IBM
mainframe COBOL '74 compiler... and one must be very careful about coding
for the limits of such things; after all, they are only...

.... thirty years old.

[snip]

>I once saw a complaint from a user that changing the DATA DIVISION code
>caused a Code Segment Limit syntax error in Procedure Division code. Turns
>out the user had increased the size of a single data item from three to nine
>characters. That data item had some 35 88-level items associated with it,
>most of which were multi-valued, and many of which had THRU clauses. This
>dramatically increased the object code generated for what at the source
>level was a simple IF statement, but at the object code level required a
>number of comparisons; the increase was sufficient to cause code segment
>overflows in a number of places in the program. Note that this is a syntax
>error requiring programmer correction, not a compiler error.

I am not sure I understand the distinction you are making here, Mr
Stevens; a 'syntax error', as I understand it, is an error in relating the
elements of the language so that they way the elements relate are no
longer in accord with the rules for said language. For example:

PERFORM PARA-A THRU PARA-C IN ORDER GIVING RESULT-FIELD

.... uses reserved words, true, but their relation is syntactically invalid
for the COBOL language.

In the situation you describe above the compiler began to generate invalid
code based on what appears to be permitted syntax.

>
>Unisys MCP/AS COBOL85 uses an entirely different algorithm for code
>segmentation and does not encounter this issue.

Aye... as mentioned in my other posting this is true of IBM mainframe
compiler IGYCRCTL.

DD

>
>"Lueko Willms" <l.willms@jpberlin.de> wrote in message
>news:9519fn7uflB@jpberlin-l.willms.jpberlin.de...
>
>

Chuck Stevens

2004-03-26, 11:00 pm

Generally speaking, MCP/AS COBOL compilers have eschewed the use of support
libraries to handle complex logic such as can be produced by STRING,
UNSTRING and INSPECT, in the belief that candidates for optimization are
better detected at the source level. The fact that an external procedure is
called does not necessarily imply that the result is more efficient (though
I grant that that may sometimes be true!).

I believe the *performance* of these verbs is adequate, which is the major
concern of most users. But the code generated is nontrivial for many
variants of these verbs.

As to alphanumeric 88's: An individual test for a 3-byte literal in an
88-level item associated with a 3-byte field seventeen bytes into a record,
as generated by COBOL74, looks like
LT8(17), NMC2 (descriptor for memory space containing field), INDX,
LT48(literal, then spaces),
LT8(3), CREL, ZERO, EQUL ...
For a 3-byte literal and a 7-byte field,
LT8(17), NMC2(ibid), INDX,
LT48(literal, then spaces), LT48(spaces), JOIN,
LT8(7), CREL, EQUL ...
and for say 13 bytes
LT8(17), NMC2(ibid), INDX,
ZERO/ONE/LT8/LT16 (offset of literal with space fill in literal pool),
NMC1, INDX,
LT8(13), CREL, ZERO, EQUL ...

Whether LT, NMC1, INDX is faster than either LT48 or LT48, LT48, JOIN
depends on which of a range of systems you're talking about. But LT48,
LT48, JOIN occupies quite a bit more code space than the other two
alternatives, which is the issue at hand.

-Chuck Stevens

<docdwarf@panix.com> wrote in message news:c3a4sj$ppi$1@panix5.panix.com...
> In article <c39uqu$1sd$1@si05.rsvl.unisys.com>,
> Chuck Stevens <charles.stevens@unisys.com> wrote:
>
> [snip]
>
the[color=darkred]
of[color=darkred]
refers[color=darkred]
procedural[color=darkred]
>
> Ahhhhh, for the Oldene Dayse! Mr Stevens, my experience is with IBM
> mainframe compilers... but the change there from IKFCBL00 to IGYCRCTL
> changed how things compiled. STRING/UNSTRING and INSPECT used to be
> *very* expensive... but now are less so, or at least apparently less so.
> A statement like
>
> STRING FLD1(3:2), FLD2, FLD3 DELIMITED BY SIZE INTO FLD4
>
> ... creates the assembley equivalent of:
>
> L 5,92(0,9) TGTFIXD+92
> L 15,152(0,5) V(IGZCSTG )
> LA 1,3717(0,4) PGMLIT AT +19493
> BALR 14,15
>
> ... and notice how all the ... unpleasantness is now hidden in a call to
> IGZCSTG. INSPECTs are even more curious...
>
> INSPECT FLDA REPLACING ALL 'AMB' BY 'ZML'
>
> ... gives:
>
> L 15,68(0,5) V(IGZCIN1 )
> LA 1,3664(0,4) PGMLIT AT +19440
> BALR 14,15
>
> ... showing a call of subrtn IGZCIN1, while
>
> INSPECT FLDA REPLACING ALL 'A' BY 'Q'
>
> ...gives:
>
> L 6,440(0,9) BLF=10
> TR 0(160,6),317(4) FLDA
>
> ... where TR is, of course, the TRanslate intruction. This seques nicely
> into the observation about code requirements increasing when the size of a
> data-item which is 88'd is increased; a single-character 88 results in a
> CLI where multi-character ones generate at least a CLC.
>
> (I recall reading someplace - the Murach book? - that a CLC is three times
> as expensive as a CLI... and this is why All Good Programmers, when given
> a choice, keep frequently-addressed 88s to a single character.)
>
> [snip]
>
to[color=darkred]
>
> Hmmmmm... a classic example of the 'round too-it' philosophy... 'just
> patch the fool thing and get it into Production, we'll Fix It Right when
> we get around to it'.
>
and[color=darkred]
>
> As many know, Mr Stevens, a program which makes it through any given run
> and gives accurate results may not be 'reliable'... the bug that you
> patched over may well be lurking under the surface, waiting for tomorrow's
> keyboarding error to bring the region down, hard. The question becomes
> one of short-term versus long term: 'How much time does a coder spend
> making sure that the program is made long-term reliable?'
>
> (ans: as long as the person who signs the timesheet permits, of course)
>
> DD
>

Chuck Stevens

2004-03-26, 11:00 pm

<docdwarf@panix.com> wrote in message news:c3a5mu$s2a$1@panix5.panix.com...
> In article <c39vmh$2kr$1@si05.rsvl.unisys.com>,
> Chuck Stevens <charles.stevens@unisys.com> wrote:
COBOL(68)).[color=darkred]
>
> Ahh... in my other posting I mentioned IKFCBL00; that was the IBM
> mainframe COBOL '74 compiler... and one must be very careful about coding
> for the limits of such things; after all, they are only...
>
> ... thirty years old.

I don't disagree. But we have many, many happy users of Unisys MCP/AS
COBOL74, and it remains a supported product.

> I am not sure I understand the distinction you are making here, Mr
> Stevens; a 'syntax error', as I understand it, is an error in relating the
> elements of the language so that they way the elements relate are no
> longer in accord with the rules for said language.

The term "syntax error" does not appear in ANSI X3.23-1974. As I see it, as
a practical matter syntax errors are not necessarily limited to syntax
rules, nor are run-time errors necessarily limited to general rules, even in
the current standard. A paragraph for which a given compiler generates
more object code than can be contained in a given object code segment on a
given architecture requires *syntactic* correction -- splitting the
paragraph -- by the programmer, and is thus a *syntax error* in that
implementation.

Reengineering that compiler to use a different code segmentation scheme may
not be appropriate given a large user base and customers dependent on the
current mechanism. Providing an alternative mechanism that the user may
specify still requires at least minimal source alteration to invoke such a
mechanism.

-Chuck Stevens

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c3a9q3$9h3$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>
><docdwarf@panix.com> wrote in message news:c3a5mu$s2a$1@panix5.panix.com...
>COBOL(68)).
>
>I don't disagree. But we have many, many happy users of Unisys MCP/AS
>COBOL74, and it remains a supported product.
>
>
>The term "syntax error" does not appear in ANSI X3.23-1974.

This might be why, Mr Stevens, I did not cite the standard and instead
relied on a definition of 'syntax' supplied by a common reference
(http://www.m-w.com).

>As I see it, as
>a practical matter syntax errors are not necessarily limited to syntax
>rules, nor are run-time errors necessarily limited to general rules, even in
>the current standard. A paragraph for which a given compiler generates
>more object code than can be contained in a given object code segment on a
>given architecture requires *syntactic* correction -- splitting the
>paragraph -- by the programmer, and is thus a *syntax error* in that
>implementation.

The program may require a correction in syntax not because the syntax is
at variance with the Standard, Mr Stevens, but because the compiler's
interpretation of the syntax results in undesireable conditions. Given a
definition of syntax as 'the way in which linguistic elements (as words)
are put together to form constitutents (as phrases or clauses)' then the
error is not 'an error of syntax' or a 'syntax error'.

(Given a definition of syntax as 'The rules governing the formation of
statements in a programming language' (www.dictionary.com, citing the AHD)
it becomes even more obvious; changing the size of the data item is well
within the rules given in the standard... but the compiler chokes.)

>
>Reengineering that compiler to use a different code segmentation scheme may
>not be appropriate given a large user base and customers dependent on the
>current mechanism.

Ahhhhhh... the classic 'You can't fix that bug... our processing depends
on it!'

>Providing an alternative mechanism that the user may
>specify still requires at least minimal source alteration to invoke such a
>mechanism.

The source may need to be altered, Mr Stevens, but not because the syntax
is at variance with the Standard... hence my questioning of labelling the
circumstance as a 'syntax error'. If it is a given that syntax is
dictated by the Standard I would appreciate a demonstration as to how
another conclusion is possible. As I see our two views:

You say: 'The statement will not compile without a change in syntax. The
statement will not compile because there is a syntax error.'

I say: 'The statement will not compile without a change in syntax. The
syntax of the statement is in full accord with the appropriate Standard.
The statement will not compile because the compiler will not accept a
statement which is in full accord with the appropriate Standard.'

DD

JerryMouse

2004-03-26, 11:00 pm

Richard wrote:
>
> And I would suggest not doing that, but instead breaking the code down
> into more easily grasped functional parts that are performed
> separately. But then who am I to preach about this, I have written a
> single paragraph that contained a single EVALUATE that ran to over
> 1500 lines. ;-)

Suzie kept one little sheep,
It's fleece shown white like snow
Yet everwhere Suzie went,
The sheep did surely go.

I'm currently working on Hamlet without the letter "O."

"Let be, yet maybe anti-be, this is the quandry..."

It isn't easy, but what's art without suffering.

>
> (it was a Windows callback)

Chuck Stevens

2004-03-26, 11:00 pm

<docdwarf@panix.com> wrote in message news:c3acn4$goq$1@panix5.panix.com...

> Ahhhhhh... the classic 'You can't fix that bug... our processing depends
> on it!'

You can't fix a bug if two users are adamant that the compiler work in
different ways *by default*.

It is not necessarily a bug, for example, to make all code segments in a
program save the last some 8K words long and let the "segment breaks"fall
where they may, without any user control over where they might fall, even if
the segment breaks fall in the middle of a "tight loop" in a
performance-critical path in the program.

It is also not necessarily a bug to have the code segmentation scheme bear
some relationship to the way the programmer has structured the program,
using SECTIONs as unconditional boundaries and paragraphs as potential ones,
with the risk that the code for a given paragraph might exceed a hard limit.

It is not a bug for the user to be able to choose either approach, for that
matter.

But both approaches cannot simultaneously be the default behavior.

As to whether such a limit conforms to the applicable standard, there isn't
one in force that applies. Whether ANSI X3.23-1974 does or does not provide
for the possibility that the implementor may encounter or enforce such
limitations is moot, as that particular standard has been out of force for
nigh onto twenty years now.

-Chuck Stevens

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c3apdc$k6n$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
><docdwarf@panix.com> wrote in message news:c3acn4$goq$1@panix5.panix.com...
>
>
>You can't fix a bug if two users are adamant that the compiler work in
>different ways *by default*.

One can do - within legal and physical limits - whatever one pleases, Mr
Stevens... whether one can do such things and retain a customer base is
another matter, entire.

I noticed, however, that you did not address my summation of our different
viewpoints... in fact, it seems that you removed it without any evidence
of editing whatsoever. Might you be so kind as to comment on this,
please? I wrote -

--begin quoted text:

The source may need to be altered, Mr Stevens, but not because the syntax
is at variance with the Standard... hence my questioning of labelling the
circumstance as a 'syntax error'. If it is a given that syntax is
dictated by the Standard I would appreciate a demonstration as to how
another conclusion is possible. As I see our two views:

You say: 'The statement will not compile without a change in syntax. The
statement will not compile because there is a syntax error.'

I say: 'The statement will not compile without a change in syntax. The
syntax of the statement is in full accord with the appropriate Standard.
The statement will not compile because the compiler will not accept a
statement which is in full accord with the appropriate Standard.'

--end quoted text

.... and I would appreciate your verifying if my interpretation of your
view is correct.

DD

Lueko Willms

2004-03-26, 11:00 pm

Am 18.03.04
schrieb docdwarf@panix.com
auf /COMP/LANG/COBOL
in c3btne$k5$1@panix1.panix.com
ueber Re: Perfrom Thru

d> You say: 'The statement will not compile without a change in syntax.
d> The statement will not compile because there is a syntax error.'
d>
d> I say: 'The statement will not compile without a change in syntax.
d> The syntax of the statement is in full accord with the appropriate
d> Standard. The statement will not compile because the compiler will not
d> accept a statement which is in full accord with the appropriate
d> Standard.'

The Standard (let me remind you that this is an old compiler
implementing the 1974 recommendations) does not require that a
contigouus sequence of statements must be allowed to have any
arbitrary length.

If there is any statement on this matter, it would certainly leave
this to the implementor. I don't have the Text of X3.23 ANS COBOL 1974
at hand to verify this, but I found this in the September 1981 draft
of COBOL-85:

--------- schnipp -----------------------------------------

In general, Standard COBOL specifies no upper limit on such things
as the number of statements in a program and the number of operands
permitted in certain statements. It is recognized that these limits
will vary from one implementation of Standard COBOL to another and may
prevent the successful translation of some programs that meet the
requirements of Standard COBOL.

------------------ schnapp --------------------------------
Section I, Chapter 1.7

I have no qualms if the compiler tells the trespassing of such
limits as a "syntax error" if the programmer can avoid such an error
by syntactically changing the code to be translated.

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <955HdfgeflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
> Am 18.03.04
>schrieb docdwarf@panix.com
> auf /COMP/LANG/COBOL
> in c3btne$k5$1@panix1.panix.com
> ueber Re: Perfrom Thru
>
>d> You say: 'The statement will not compile without a change in syntax.
>d> The statement will not compile because there is a syntax error.'
>d>
>d> I say: 'The statement will not compile without a change in syntax.
>d> The syntax of the statement is in full accord with the appropriate
>d> Standard. The statement will not compile because the compiler will not
>d> accept a statement which is in full accord with the appropriate
>d> Standard.'
>
> The Standard (let me remind you that this is an old compiler
>implementing the 1974 recommendations) does not require that a
>contigouus sequence of statements must be allowed to have any
>arbitrary length.

I do not believe, Mr Willms, that the length of the statement Mr Stevens
mentioned changed... just the length of the data-field which was being
evaluated for a condition, as stated in:

<http://groups.google.com/groups?sel...8&output=gplain>

--begin quoted text:

I once saw a complaint from a user that changing the DATA DIVISION code
caused a Code Segment Limit syntax error in Procedure Division code.
Turns out the user had increased the size of a single data item from three
to nine characters.

--end quoted text

As I understand (and simplify) the example:

01 FLDA PIC X(03).
88 COND1 VALUE 'AAA'.
....

IF COND1 THEN (imperative statement)

.... compiled and executed as expected while

01 FLDA PIC X(09).
88 COND1 VALUE 'AAAAAAAAA'.
....

IF COND1 THEN (imperative statement)

.... caused the 'Code Segment Limit syntax error in the Procedure
Division'.

Now I would readily agree that changing a data *type* can render a given
syntax invalid; the target/receiving operand for a COMPUTE should not be
other than some type of numeric. What is being said here, however, seems
to be that a change in a field's size, and size alone, renders a
previously-accepted syntax as an error because of the amount of code the
compiler produces as a result of this change... and this seems, to me, to
be a matter of the compiler's workings and not the language's syntax,
hence my questioning and attempts to discuss.

I don't expect any earth-shaking changes to result from this... but I
would hope to see open, honest, reasoned discusion - establishing
definitions, generating logical relations, comparing and interpreting the
resulting conclusions - about what might be seen as a rather fundamental
question of 'what are the criteria used in applying a given label to a
situation?'...

.... and, of course, I have seen enough of the world to know that, at
times, my hopes can be cruelly dashed... but hey, it is a change from
posting 'please do your own homework' and requesting rates, or ranges of
rates.

DD

Michael Wojcik

2004-03-26, 11:00 pm

In article <C_ednYa8kt1vVcXdRVn-tA@giganews.com>, "JerryMouse" <nospam@bisusa.com> writes:
>
> Suzie kept one little sheep,
> It's fleece shown white like snow
^^^

This should be "Its", if this is an ANSI-standard sheep, and not just
a big ball o' fleece.

> Yet everwhere Suzie went,

If you made this "Yet everywhere this Suzie went" you'd maintain the
meter of the original.

> The sheep did surely go.

Still, a noble effort, now fortunately enshrined in Google Groups
for posterity.

> I'm currently working on Hamlet without the letter "O."
>
> "Let be, yet maybe anti-be, this is the quandry..."
>
>
> It isn't easy, but what's art without suffering.

Indeed.

--
Michael Wojcik michael.wojcik@microfocus.com

Art is our chief means of breaking bread with the dead ... but the social
and political history of Europe would be exactly the same if Dante and
Shakespeare and Mozart had never lived. -- W. H. Auden

There are many definitions of what art is, but what I am convinced art is not
is self-expression. If I have an experience, it is not important because it
is mine. It is important because it's worth writing about for other people,
worth sharing with other people. That is what gives it validity. (Auden)

Any average educated person can turn out competent verse. -- W. H. Auden

Richard

2004-03-26, 11:00 pm

"JerryMouse" <nospam@bisusa.com> wrote

>
> "Let be, yet maybe anti-be, this is the quandry..."
>
>
> It isn't easy, but what's art without suffering.

But it should be the artist that suffers, not, as in this case, the audience.

Lueko Willms

2004-03-26, 11:00 pm

Am 18.03.04
schrieb docdwarf@panix.com
bei /COMP/LANG/COBOL
in c3ceqj$i28$1@panix5.panix.com
ueber Re: Perfrom Thru

d> What is being said here, however,
d> seems to be that a change in a field's size, and size alone, renders a
d> previously-accepted syntax as an error because of the amount of code
d> the compiler produces as a result of this change... and this seems, to
d> me, to be a matter of the compiler's workings and not the language's
d> syntax, hence my questioning and attempts to discuss.

Which makes clear that this is an implementation issue.

I really don't care if the compiler emits a message saying "You have
bypassed my implementation limits" or "I can't cope with that syntax
any more, which I see as an error", if the programmer can find
somewhere clear indications on how to adapt his program to compile to
a correct executable.

It doesn't matter, if the number of sentences in one Paragraph
changed, or some data definition. Fact is that the compiler choked and
could no longer generate executable code.

d> I don't expect any earth-shaking changes to result from this...

Especially in the case of a compiler implementing COBOL-1974, when a
newer compiler implementing COBOL-85 is available. What in all
probability means that the COBOL-74 compiler, if still supported, will
not implement new features, but maybe just some minor error
corrections. Probably not more than making sure that it works
correctly under new versions of the operating system.

I would recommend anyone to move up to COBOL-85.

d> but I would hope to see open, honest, reasoned discusion -
d> establishing definitions, generating logical relations, comparing
d> and interpreting the resulting conclusions - about what might be
d> seen as a rather fundamental question of 'what are the criteria
d> used in applying a given label to a situation?'...

Yeah, the main issue in this case is: implementation issues are up
to the implementor.

That's the way the cookie crumbles.

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Die Arbeit in weißer Haut kann sich nicht dort emanzipieren, wo sie
in schwarzer Haut gebrandmarkt wird." - Karl Marx 12.11.1866

Lueko Willms

2004-03-26, 11:00 pm

Am 19.03.04
schrieb L.Willms@JPBERLIN.de (Lueko Willms)
auf /COMP/LANG/COBOL
in 959LIvFuflB@jpberlin-l.willms.jpberlin.de
ueber Re: Perfrom Thru

LW> I would recommend anyone to move up to COBOL-85.

Well ... I understand that there is an even newer standard, 2002.

My contact with COBOL production work ended 10 years ago.

Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

"Die Arbeit in weißer Haut kann sich nicht dort emanzipieren, wo sie
in schwarzer Haut gebrandmarkt wird." - Karl Marx 12.11.1866

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <959LIvFuflB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
> Am 18.03.04
> schrieb docdwarf@panix.com
> bei /COMP/LANG/COBOL
> in c3ceqj$i28$1@panix5.panix.com
> ueber Re: Perfrom Thru
>
>d> What is being said here, however,
>d> seems to be that a change in a field's size, and size alone, renders a
>d> previously-accepted syntax as an error because of the amount of code
>d> the compiler produces as a result of this change... and this seems, to
>d> me, to be a matter of the compiler's workings and not the language's
>d> syntax, hence my questioning and attempts to discuss.
>
> Which makes clear that this is an implementation issue.

Clarity is in the eye of the beholder, Mr Willms... clearly Mr Stevens has
labelled it a 'syntax problem' and - unless my service has been editing or
dropping his postings here - has not responded to my requests for
clarification. This might be seen as understandable, given that a 'syntax
error' is usually tossed into the coder's lap to resolve.

[snip]

>d> I don't expect any earth-shaking changes to result from this...
>
> Especially in the case of a compiler implementing COBOL-1974, when a
>newer compiler implementing COBOL-85 is available. What in all
>probability means that the COBOL-74 compiler, if still supported, will
>not implement new features, but maybe just some minor error
>corrections.

Given the number of code-possibilities the compiler has been subject to in
the past three decades it might be reasonable to consider it unlikely that
there are too many situations which have *not* been encountered... and
are, most likely, being relied upon. As Mr Stevens pointed out... if two
or more of you are gathered in a particular 'feature's' name then it is
unlikely that said 'feature' will be changed.

DD

Chuck Stevens

2004-03-26, 11:00 pm

<docdwarf@panix.com> wrote in message news:c3ei3a$sve$1@panix1.panix.com...
> Clarity is in the eye of the beholder, Mr Willms... clearly Mr Stevens has
> labelled it a 'syntax problem' and - unless my service has been editing or
> dropping his postings here - has not responded to my requests for
> clarification. This might be seen as understandable, given that a 'syntax
> error' is usually tossed into the coder's lap to resolve.

I have not responded to your repeated requests for an extended essay on what
I regard as a syntax error in which contexts for two reasons: 1) I believe
in the context of the various COBOL dialects others have answered
adequately, and 2) I have been embroiled in internecine discussion on the
correct way to generate object code to close files in a MERGE (as generated
by all compilers that have syntactic support for sort/merge), as well as the
proper way to simulate the long-deprecated ICVU operator without using the
almost-as-deprecated ICVD operator as utilized by ALGOL (both ICVD and ICVU
are long since gone from all other language compilers' code generation
schemata).

Given Mr. Klein's eloquent response I felt my time was better utilized
resolving problems that more directly affected our users!

-Chuck Stevens

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c3f5q2$iqt$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>
><docdwarf@panix.com> wrote in message news:c3ei3a$sve$1@panix1.panix.com...
>
>I have not responded to your repeated requests for an extended essay on what
>I regard as a syntax error in which contexts for two reasons:

Please excuse the impoliteness of my midsentence interruption, Mr Stevens,
but to the best of my knowledge I have not requested an 'extended essay'
from you or anyone else. I have asked twice - and now ask for the third
and final time - whether my summary of our differences may be summarised
as follows:

From
<http://groups.google.com/groups?q=g...anix5.panix.com>
....
and
<http://groups.google.com/groups?q=g...anix1.panix.com>

--begin quoted text:

You say: 'The statement will not compile without a change in syntax. The
statement will not compile because there is a syntax error.'

I say: 'The statement will not compile without a change in syntax. The
syntax of the statement is in full accord with the appropriate Standard.
The statement will not compile because the compiler will not accept a
statement which is in full accord with the appropriate Standard.'

--end quoted text

If my interpretation is in error then it might be courteous to supply
clarification. If I am correct then an acknowledgement of accuracy would
be appreciated.

DD

Chuck Stevens

2004-03-26, 11:00 pm

<docdwarf@panix.com> wrote in message news:c3f8cn$qka$1@panix5.panix.com...

I wrote:

what[color=darkred]
>
> Please excuse the impoliteness of my midsentence interruption, Mr Stevens,
> but to the best of my knowledge I have not requested an 'extended essay'
> from you or anyone else. I have asked twice - and now ask for the third
> and final time - whether my summary of our differences may be summarised
> as follows:

I do not feel I can do justice to the answer without a lengthy response, and
I do not have time to compose one.

> If my interpretation is in error then it might be courteous to supply
> clarification. If I am correct then an acknowledgement of accuracy would
> be appreciated.

Perhaps it would have been clearer had I written "paragraph" or "program"
instead of "statement". I do believe your interpretation of my intent is
indeed incorrect.

There is nothing inherently wrong with a single IF statement that references
an 88-level item that generates vast quantities of code, nor is there
anything inherently wrong with the compiler that does so.

The error is in having a paragraph whose generated code (including such an
IF statement or not) exceeds implementation limits (in this case,
documented -- Form 8600 0296-203 page 5-4, in case you're curious), for
which the appropriate correction is applied at the syntactic level -- either
by supplying additional paragraphs, or by adjusting the (Unisys MCP/AS
extension to ANSI-74 COBOL) value in the CODE SEGMENT-LIMIT clause in the
OBJECT-COMPUTER paragraph from its default value of 1500 words, as the
manual specifies.

-Chuck Stevens

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c3fch4$nhv$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>
><docdwarf@panix.com> wrote in message news:c3f8cn$qka$1@panix5.panix.com...
>
>I wrote:
>
>
>I do not feel I can do justice to the answer without a lengthy response, and
>I do not have time to compose one.

This may indeed be what you feel, Mr Stevens, but your feelings do not
constitute a single request on my part, let alone the 'repeated requests'
to which you have referred.

>
>
>Perhaps it would have been clearer had I written "paragraph" or "program"
>instead of "statement". I do believe your interpretation of my intent is
>indeed incorrect.
>
>There is nothing inherently wrong with a single IF statement that references
>an 88-level item that generates vast quantities of code, nor is there
>anything inherently wrong with the compiler that does so.
>
>The error is in having a paragraph whose generated code (including such an
>IF statement or not) exceeds implementation limits (in this case,
>documented -- Form 8600 0296-203 page 5-4, in case you're curious), for
>which the appropriate correction is applied at the syntactic level -- either
>by supplying additional paragraphs, or by adjusting the (Unisys MCP/AS
>extension to ANSI-74 COBOL) value in the CODE SEGMENT-LIMIT clause in the
>OBJECT-COMPUTER paragraph from its default value of 1500 words, as the
>manual specifies.

'The error is in having a paragraph whose generated code... exceeds
implementation limits... for which the appropriate correction is...
syntactic.'

I read these words, Mr Stevens, and I read that the implementation limits
('in this case, documented' leaving the possibility that in other cases,
undocumented) are exceeded and 'the correction is applied at the syntactic
level'.

The implementation limits must be compensated for by syntax... the
limitation, then, is not one of the syntax but one of the implementation,
as Mr Willms stated. I have demonstrated, here, how this conclusion was
reached; if the conclusion was reached by an error in definition or logic
then, by all means, be so kind as to demonstrate.

To others reading this... I am a coder and I bristle at being told my code
contains a 'syntax error' when what the code does is cause the compiler to
'generate code which exceeds implementation limits'.

If legitimate language constructs (it seems that nobody has yet found
where it is that syntax is defined!) cause the compiler to puke... fine,
no sweat, tell me the compiler gurks and I need to correct something.

*Don't* tell my syntax is in error; to do so seems, at least to me, quite
similar to the many times I've had miserable, stinkwad, gut-crawling,
corner-office idiots blaming their inabilities on me and then tell me they
were Much Too Busy to be shown that they are wrong... not, of course, that
anyone in this exchange might be demonstrating behaviors which could be
interpreted in that manner.

DD

LX-i

2004-03-26, 11:00 pm

docdwarf@panix.com wrote:
>
>
> I am not sure I understand the distinction you are making here, Mr
> Stevens; a 'syntax error', as I understand it, is an error in relating the
> elements of the language so that they way the elements relate are no
> longer in accord with the rules for said language. For example:
>
> PERFORM PARA-A THRU PARA-C IN ORDER GIVING RESULT-FIELD
>
> ... uses reserved words, true, but their relation is syntactically invalid
> for the COBOL language.
>
> In the situation you describe above the compiler began to generate invalid
> code based on what appears to be permitted syntax.

I haven't had any experience with the MCP side of Unisys, but the 2200
side also had a code segment limit in the '74 compiler. It's a syntax
error because there's too much syntax. :) However, on the 2200 side,
you would get the error out of the "collector" (linker) because your
I-bank (instruction bank) overlaps your D-bank (data bank).

COBOL 85 gripes if a segment is too big, and provides a keywork of
SEGCODE to tell the compiler to do segmenting as it sees fit. Also, in
COBOL 85, the segments are 262,143 4-character words, so you've got to
have a pretty hefty program to blow that limit to begin with.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <105soma4476fqf0@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>I haven't had any experience with the MCP side of Unisys, but the 2200
>side also had a code segment limit in the '74 compiler. It's a syntax
>error because there's too much syntax. :)

I see... and who is it who says there is 'too much syntax'?

DD

LX-i

2004-03-26, 11:00 pm

docdwarf@panix.com wrote:
>
>
> I see... and who is it who says there is 'too much syntax'?

Probably the manual (the 2200 ACOB (74) manual does, going into detail
about it in the "segmentation module" section).

I've read the rest of the thread at this point, and I can see both
sides. If the compiler documents that you can only generate xK of
instructions or data per paragraph/section/etc, and you write valid
COBOL syntax that exceeds this limit, what type of error would you call
it? (Size, maybe?)

(As an aside, I sure am glad we don't have to manually segment our
programs any more - that was a pain!)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <105tnvdmso6tca@corp.supernews.com>,
LX-i <lxi0007@netscape.net> wrote:
>docdwarf@panix.com wrote:
>
>Probably the manual (the 2200 ACOB (74) manual does, going into detail
>about it in the "segmentation module" section).

This is, I assume, the implementation manual.

>
>I've read the rest of the thread at this point, and I can see both
>sides. If the compiler documents that you can only generate xK of
>instructions or data per paragraph/section/etc, and you write valid
>COBOL syntax that exceeds this limit, what type of error would you call
>it? (Size, maybe?)

If the code generated is beyond the compiler's capabiliies to handle then
the limitation is one of the compiler, not the code. As an analogy... it
used to be that one could not define a table of more than 32K (... or was
it 64K? I think it was 32K... but my memory is, admittedly, porous) under
the IBM mainframe compiler IKFCBL00. So...

01 BIG-TBL.
05 TBL-ITEM OCCURS 32 PIC X(1000).

.... would compile, while

01 BIG-TBL.
05 TBL-ITEM OCCURS 33 PIC X(1000).

.... would throw an error. My experience is, I agree, limited... but I do
not recall anyone calling this a 'syntax error', it was always a 'compiler
limit'... same thing with not being able to define an OCCURS at the 01
level. Sure, you had to change your code (or 'perform an application of
syntactic correction', as some might label such an action)... but folks
seemed to know that you had to change your code not because the syntax was
in error but because the compiler just could not deal with such things.

DD

Howard Brazee

2004-03-26, 11:00 pm

On 20-Mar-2004, docdwarf@panix.com wrote:

> The implementation limits must be compensated for by syntax... the
> limitation, then, is not one of the syntax but one of the implementation,
> as Mr Willms stated. I have demonstrated, here, how this conclusion was
> reached; if the conclusion was reached by an error in definition or logic
> then, by all means, be so kind as to demonstrate.
>
> To others reading this... I am a coder and I bristle at being told my code
> contains a 'syntax error' when what the code does is cause the compiler to
> 'generate code which exceeds implementation limits'.

I agree. But this is just a term. I get irritated similarly when someone
uses terms such as "database" in a different manner that I do. Or "ten items
or less", or "hot water heater", or ... (please let's not start a thread, this
could last forever!)

It does seem as though the compiler company is doing a cop-out, blaming the
programmer for the compiler's limitations.

Chuck Stevens

2004-03-26, 11:00 pm

<docdwarf@panix.com> wrote in message news:c3mppr$f9q$1@panix5.panix.com...

> If the code generated is beyond the compiler's capabiliies to handle then
> the limitation is one of the compiler, not the code. As an analogy... it
> used to be that one could not define a table of more than 32K (... or was
> it 64K? I think it was 32K... but my memory is, admittedly, porous) under
> the IBM mainframe compiler IKFCBL00. So...
>
> 01 BIG-TBL.
> 05 TBL-ITEM OCCURS 32 PIC X(1000).
>
> ... would compile, while
>
> 01 BIG-TBL.
> 05 TBL-ITEM OCCURS 33 PIC X(1000).
>
> ... would throw an error. My experience is, I agree, limited... but I do
> not recall anyone calling this a 'syntax error', it was always a 'compiler
> limit'... same thing with not being able to define an OCCURS at the 01
> level. Sure, you had to change your code (or 'perform an application of
> syntactic correction', as some might label such an action)... but folks
> seemed to know that you had to change your code not because the syntax was
> in error but because the compiler just could not deal with such things.

From the viewpoint of the user in the Unisys MCP/AS world -- because it's
reported that way to the user by the operating system -- a "syntax error" is
any error that causes *any* compiler to report to the operating system, and
ultimately to the user, that the compilation terminated as a "SNTX"
termination. This is allowed only for processes established a priori as
compilations by the operating system. That includes limits errors,
violations of ANSI standards, references to undefined variables in languages
other than FORTRAN, redefinition of field attributes in the C-specs of RPG,
errors reported back through various compilers from the DMSII data base
declaration or access-parsing software, and yes, even cases like "A compiler
error has occurred. Please contact your support organization." as issued by
the COBOL74 compiler and a whole passel of similar ones potentially issued
by RPG. So long as the compiler is capable of detecting the error *and
continuing*, the error is reported as a syntax error.

In this context, the only cases that are reported as "compiler errors" in
the strict sense are those in which the compiler has detected a situation
*it* views as impossible, almost always indicative of an undected logic
error encountered previously in the compilation. In such cases, the
compiler continues to attempt to parse the remainder of the program so that
the user can get as much benefit from the compilation as possible.

All of these types of errors will generally result in the compiler
*terminating gracefully* after having examined the entire source file (and
at least going through the motions of generating code even after the
detection of such problems.

If the user specifies through directives that *warnings* should also be
treated as syntax errors, the compiler will oblige; ordinarily things like
"Four bits of filler have been added here so that all alphanumeric,
word-oriented and group items begin on a character boundary." as issued
during the parsing of the Data Division are treated as advisory.

"Syntax errors" are in direct contrast to indexing errors, arithmetic
faults, invalid operands encountered by the object code sequences within the
compiler, and such like, which result in the immediate, fatal and premature
termination of the compilation process. Fault terminations are reported
back to the user as one or another form of "DS" termination, as would be a
manual "DS" of the compilation by the end user or by an operator. As I
understand it, "DS" stands for "Discontinue Service"; the mnemonic dates
back at least to Burroughs B5000 days, and I can't verify its history
further back than that. When such a fault occurs, the compiler stops
*right then*, and may or may not give the user any indication of which
statement or construct it was that caused the compiler to encounter this
*program fault*.

Compilations that encounter no execution-time faults or syntax errors
(whether or not they encounter warnings that haven't been turned into errors
at user request) are deemed to have successfully reached end-of-task
("EOT").

Thus, in the Unisys MCP/AS community, there are syntax errors; there are
irrecoverable program faults encountered during compilation, and there are
successful compilations. Those have been the choices for not much less than
a half-century of Burroughs Large System and Unisys ClearPath systems;
whether the decisions made by Burroughs Corporation in the late 1950's and
very early 1960's are strictly semantically accurate when viewed from the
mindset of a linguist or of users of other equipment using different
conventions must be weighed against what existing users of the equipment
have been led to expect.

Given that my employers expect me to resolve genuine problems encountered by
genuine licensed users of Unisys hardware and software products, as well as
to prepare for a meeting that will take me out of the office all next w

,
I think I've devoted enough time and energy to this topic. This response
will have to suffice, whether deemed adequate or not.

-Chuck Stevens

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c3nav9$ef$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>
><docdwarf@panix.com> wrote in message news:c3mppr$f9q$1@panix5.panix.com...
>
>
>From the viewpoint of the user in the Unisys MCP/AS world -- because it's
>reported that way to the user by the operating system -- a "syntax error" is
>any error that causes *any* compiler to report to the operating system, and
>ultimately to the user, that the compilation terminated as a "SNTX"
>termination.

So... because the compiler says the syntax is in error then... it *must*
be because the syntax is in error, not because the compiler is unable -
documented or not - to generate code.

And why is the syntax said to be 'in error', even if it agrees with the
Standard? The syntax is said to be in error, it seems... because the
compiler says so, not any other sort of language-defining corpus.

>This is allowed only for processes established a priori as
>compilations by the operating system. That includes limits errors,
>violations of ANSI standards, references to undefined variables in languages
>other than FORTRAN, redefinition of field attributes in the C-specs of RPG,
>errors reported back through various compilers from the DMSII data base
>declaration or access-parsing software, and yes, even cases like "A compiler
>error has occurred. Please contact your support organization." as issued by
>the COBOL74 compiler and a whole passel of similar ones potentially issued
>by RPG. So long as the compiler is capable of detecting the error *and
>continuing*, the error is reported as a syntax error.

Thanks for clearing this up... '(s)o long as the compiler is capable of
detecting the error *and continuing*, (emphasis original) the error is
reported as a syntax error.'

Not 'so long as the compiler is capable of determining what the cause of
the error is', as long as it can keep going... syntax is blamed.

Programmers are responsible for the syntax of the statements they write,
last I looked.

[snip]

>Thus, in the Unisys MCP/AS community, there are syntax errors; there are
>irrecoverable program faults encountered during compilation, and there are
>successful compilations. Those have been the choices for not much less than
>a half-century of Burroughs Large System and Unisys ClearPath systems;
>whether the decisions made by Burroughs Corporation in the late 1950's and
>very early 1960's are strictly semantically accurate when viewed from the
>mindset of a linguist or of users of other equipment using different
>conventions must be weighed against what existing users of the equipment
>have been led to expect.

If someone can be sold the expectation that a compiler will tell you
'syntax error' instead of 'I can't deal with the code I generate from
this' then they deserve what they have purchased... and when someone
refers to a Long and Respected History I am usually reminded of Rear
Admiral Grace Murray Hopper - may she sleep with the angels! - saying
something along the lines of "the most damaging phrase in the language is
`We've always done it this way.'"

>
>Given that my employers expect me to resolve genuine problems encountered by
>genuine licensed users of Unisys hardware and software products, as well as
>to prepare for a meeting that will take me out of the office all next w

,
>I think I've devoted enough time and energy to this topic. This response
>will have to suffice, whether deemed adequate or not.

How exquisitely generous of you, Mr Stevens, to have deemed the poor words
I've posted worthy of any response at all.

DD

Joe Zitzelberger

2004-03-26, 11:00 pm

Just my not so humble $0.02...

If the compiler can detect that some source code has generated object
code that will exceed the segment limits.

And the normal fix is for the programmer to insert some unreferenced
labels in the middle of the offending source code.

But the compiler, which can detect the error, does not assume some
unreferenced labels in the middle of the segments and keep on trucking?

Even the blondest among us would wonder about the manufacturer that
tried to pass this one off on its customers. (regardless of
syntax-error/compiler-error labeling)

In article <c3nav9$ef$1@si05.rsvl.unisys.com>,
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

> <docdwarf@panix.com> wrote in message news:c3mppr$f9q$1@panix5.panix.com...
>
>
> From the viewpoint of the user in the Unisys MCP/AS world -- because it's
> reported that way to the user by the operating system -- a "syntax error" is
> any error that causes *any* compiler to report to the operating system, and
> ultimately to the user, that the compilation terminated as a "SNTX"
> termination. This is allowed only for processes established a priori as
> compilations by the operating system. That includes limits errors,
> violations of ANSI standards, references to undefined variables in languages
> other than FORTRAN, redefinition of field attributes in the C-specs of RPG,
> errors reported back through various compilers from the DMSII data base
> declaration or access-parsing software, and yes, even cases like "A compiler
> error has occurred. Please contact your support organization." as issued by
> the COBOL74 compiler and a whole passel of similar ones potentially issued
> by RPG. So long as the compiler is capable of detecting the error *and
> continuing*, the error is reported as a syntax error.
>
> In this context, the only cases that are reported as "compiler errors" in
> the strict sense are those in which the compiler has detected a situation
> *it* views as impossible, almost always indicative of an undected logic
> error encountered previously in the compilation. In such cases, the
> compiler continues to attempt to parse the remainder of the program so that
> the user can get as much benefit from the compilation as possible.
>
> All of these types of errors will generally result in the compiler
> *terminating gracefully* after having examined the entire source file (and
> at least going through the motions of generating code even after the
> detection of such problems.
>
> If the user specifies through directives that *warnings* should also be
> treated as syntax errors, the compiler will oblige; ordinarily things like
> "Four bits of filler have been added here so that all alphanumeric,
> word-oriented and group items begin on a character boundary." as issued
> during the parsing of the Data Division are treated as advisory.
>
> "Syntax errors" are in direct contrast to indexing errors, arithmetic
> faults, invalid operands encountered by the object code sequences within the
> compiler, and such like, which result in the immediate, fatal and premature
> termination of the compilation process. Fault terminations are reported
> back to the user as one or another form of "DS" termination, as would be a
> manual "DS" of the compilation by the end user or by an operator. As I
> understand it, "DS" stands for "Discontinue Service"; the mnemonic dates
> back at least to Burroughs B5000 days, and I can't verify its history
> further back than that. When such a fault occurs, the compiler stops
> *right then*, and may or may not give the user any indication of which
> statement or construct it was that caused the compiler to encounter this
> *program fault*.
>
> Compilations that encounter no execution-time faults or syntax errors
> (whether or not they encounter warnings that haven't been turned into errors
> at user request) are deemed to have successfully reached end-of-task
> ("EOT").
>
> Thus, in the Unisys MCP/AS community, there are syntax errors; there are
> irrecoverable program faults encountered during compilation, and there are
> successful compilations. Those have been the choices for not much less than
> a half-century of Burroughs Large System and Unisys ClearPath systems;
> whether the decisions made by Burroughs Corporation in the late 1950's and
> very early 1960's are strictly semantically accurate when viewed from the
> mindset of a linguist or of users of other equipment using different
> conventions must be weighed against what existing users of the equipment
> have been led to expect.
>
> Given that my employers expect me to resolve genuine problems encountered by
> genuine licensed users of Unisys hardware and software products, as well as
> to prepare for a meeting that will take me out of the office all next w

,
> I think I've devoted enough time and energy to this topic. This response
> will have to suffice, whether deemed adequate or not.
>
> -Chuck Stevens
>
>

Chuck Stevens

2004-03-26, 11:00 pm

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-EE378D.23121722032004@corp.supernews.com...
> Just my not so humble $0.02...
>
> If the compiler can detect that some source code has generated object
> code that will exceed the segment limits.
>
> And the normal fix is for the programmer to insert some unreferenced
> labels in the middle of the offending source code.
>
> But the compiler, which can detect the error, does not assume some
> unreferenced labels in the middle of the segments and keep on trucking?
>
> Even the blondest among us would wonder about the manufacturer that
> tried to pass this one off on its customers. (regardless of
> syntax-error/compiler-error labeling)

Rememer that Unisys MCP/AS object code segments are *never* loaded into
memory until such time as control is passed to them, and the memory space is
eligible to be marked as absent and reused by the memory management scheme
at any point so long as it is not actively being executed. Transfer of
control from one segment to another may be relatively fast and it may not,
dependent on whether the destination code segment happens to be resident in
memory or not. And the user has little control, particularly on a
limited-memory system, as to whether that code segment will be resident at
any given moment.

Thus, the reason the COBOL74 compiler doesn't do the equivalent of inserting
a label is that the implementor is unwilling to assume that the
silently-inserted label (and the object code associated with it that is
required to transfer control from one object code segment -- resident in
memory or not -- to another) does not, or cannot, occur in the middle of a
time-critical routine, thereby degrading performance of that routine to an
unacceptable level.

Either you give the user control over whether (carefully-written
user-optimized or not) code (carefully-written user-optimized or not) is
indeed efficient -- by giving the user control over whether a "silent"
inter-segment transfer is permitted to occur.

As it happens, I have no problem with allowing both schemata in the same
compiler. Unfortunately, providing the user such a choice -- ignore
paragraphs and sections entirely for purposes of code segmentation, or
segment at section and sometimes paragraph boundaries in the Procedure
Division -- at compile time is not an option for the COBOL74 compiler
because such significant new features are not being considered for it. Such
an option is actively being discussed for COBOL85.

A side note: while "segmentation" is a fully-supported and undeprecated
module of ANSI X3.23-1974, it is marked obsolete in ANSI X3.23-1985 and is
absent from ISO/IEC 1989:2002. As I see it, the primary "pecularity" in the
segmentation module is the distinction between the impact of ALTER on
SECTIONs with numbers less than 50 and its impact on SECTIONs with larger
section numbers, and ALTER is also obsolete in ANSI X3.23-1985 and absent
from ISO/IEC 1989:2002 (and has arguably been deprecated even longer than
the segmentation module itself).

The distinction between "fixed" and "overlayable" segments that is discussed
at length in ANSI X3.23-1974 does not actually describe a physical
difference among MCP/AS object code segment types. In general *all* user
code segments are overlayable, and the COBOL74 distinction between "fixed"
and "overlayable" must be made by differences in the object code and in
control information associated with ALTER and GO TO. Some compilers
generate code for ALTER to "step on" the branch instruction associated with
the destinationless GO TO (and to restore the branch on entry for each
overlayable segment); Unisys MCP/AS compilers are not among them.

-Chuck Stevens

Chuck Stevens

2004-03-26, 11:00 pm

I wrote:

<Either you give the user control over whether (carefully-written
user-optimized or not) code (carefully-written user-optimized or not) is
indeed efficient -- by giving the user control over whether a "silent"
inter-segment transfer is permitted to occur. >

More clearly:

Either you give the user control over whether (carefully-written
user-optimized or not) code is indeed efficient -- by giving the user the
ability to prohibit a "silent" inter-segment transfer is permitted to occur
inside that piece of code -- or you don't. Unisys MCP/AS COBOL74, if it
errs in this regard, errs on the side of giving the user greater control
over the efficiency of his program at the expense of the possibility that if
the user fails to exercize that option appropriately the result *can* (under
very limited circumstances) be an uncompilable program.

-Chuck Stevens

Howard Brazee

2004-03-26, 11:00 pm

On 23-Mar-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:

> Thus, the reason the COBOL74 compiler doesn't do the equivalent of inserting
> a label is that the implementor is unwilling to assume that the
> silently-inserted label (and the object code associated with it that is
> required to transfer control from one object code segment -- resident in
> memory or not -- to another) does not, or cannot, occur in the middle of a
> time-critical routine, thereby degrading performance of that routine to an
> unacceptable level.

So it chooses to abort or disallow the code instead?

Dumb.

But no dumber than the ANSI 74 practice on IBM mainframes of sticking filler
tables behind tables that are too small to do the job (getting around a similar
compiler limitation).

I wish CoBOL had a USAGE mode that allowed for unlimited number size. Sure we
know it's inefficient - but the compiler could handle it anyway.

Chuck Stevens

2004-03-26, 11:00 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:c3q0e4$r4p$1@peabody.colorado.edu...
>
> On 23-Mar-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
inserting[color=darkred]
a[color=darkred]
an[color=darkred]
>
> So it chooses to abort or disallow the code instead?

It informs the user, at compile time, that the current object code segment
has exceeded architectural limits. The programmer has the option of adding
paragraphs, changing the default segment size at which the compiler s

s to
start a new code segment, or both. But never, never does the COBOL74
compiler decide that it's OK to stick a code segment break in the middle of
any statement, or even between any two statements.

> Dumb.

You may think so. But it is my experience that users who have historically
used COBOL to drive devices like check reader-sorters at full smoke (or do
other performance- or time-critical tasks) are not at all pleased when the
compiler decides to stick a segment transfer (and the potential for a code
segment overlay) in the middle of what the user deems extremely
critical-path code. They'd rather have their hand slapped so that they know
they need to do something to their program. The ones that have no control
over where the compiler segments code *can't* fix their programs.

> I wish CoBOL had a USAGE mode that allowed for unlimited number size.

Unisys MCP/AS provides 23 digits of precision in arithmetic. ISO/IEC
1989:2002 mandates 32 digits for standard arithmetic. I believe at least
the earliest Burroughs Medium System provided hardware support for
arithmetic on (packed or display) items of up to 100 digits or even more,
though as I recall later ones didn't handle arithmetic on extremely large
items because field experience demonstrated insufficient customer demand for
this feature. MCP/AS COBOL85 allows manipulation of (though I grant not
arithmetic directly on) very, very large COMP (=PACKED-DECIMAL) items (I
just played with numeric MOVEs to a 6000-digit COMP destination).

How many digits have you found that you actually need in practice?

-Chuck Stevens

docdwarf@panix.com

2004-03-26, 11:00 pm

In article <c3q0e4$r4p$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:

[snip]

>But no dumber than the ANSI 74 practice on IBM mainframes of sticking filler
>tables behind tables that are too small to do the job (getting around a similar
>compiler limitation).

Speaking as one who coded just such a thing (you know... one of those
'it's blowing up and we have 15 minutes before the evening cycle' sort of
thing, there's always enough time to do it over but never enough time to
do it right)... one did what one did and Prod kept running.

(Curious, though, to compare an... 'oddity' in a compiler with the tricks
users employed to get around such 'oddities'.)

DD

Joe Zitzelberger

2004-03-26, 11:00 pm

In article <c3pu8d$1pjm$1@si05.rsvl.unisys.com>,
"Chuck Stevens" <charles.stevens@unisys.com> wrote:

> I wrote:
>
> <Either you give the user control over whether (carefully-written
> user-optimized or not) code (carefully-written user-optimized or not) is
> indeed efficient -- by giving the user control over whether a "silent"
> inter-segment transfer is permitted to occur. >
>
> More clearly:
>
> Either you give the user control over whether (carefully-written
> user-optimized or not) code is indeed efficient -- by giving the user the
> ability to prohibit a "silent" inter-segment transfer is permitted to occur
> inside that piece of code -- or you don't. Unisys MCP/AS COBOL74, if it
> errs in this regard, errs on the side of giving the user greater control
> over the efficiency of his program at the expense of the possibility that if
> the user fails to exercize that option appropriately the result *can* (under
> very limited circumstances) be an uncompilable program.
>
> -Chuck Stevens

Still, if a user is working at the Cobol level, they have already
indicated a lack of concern with how the object code is going to be
generated. That is the compilers job.

If they want to build segments exactly the way they want them, wouldn't
they use an assembler?

William M. Klein

2004-03-26, 11:00 pm

Doc,
I guess I see the two situations as identical.

With OS/VS COBOL,
If you coded a table greater than 32K, you received a compile-time (I would
call syntax) error. (The error was listed when you compiled ERRMSG - so I
consider those syntax errors). A programmer than could "add" a dummy 01-level
after the table and "treat" it as part of the original table.

With the Unisys '74 compiler (as I understand it),
If the programmer coded a single paragraph that was too large, they would
receive a compile-time message. The programmer could then add a "dummy" (never
referenced) paragraph name.

***

What is the difference between these two errors-followed-by-programmer-change
that you see.

--
Bill Klein
wmklein <at> ix.netcom.com
<docdwarf@panix.com> wrote in message news:c3qqe1$5lo$1@panix1.panix.com...
> In article <c3q0e4$r4p$1@peabody.colorado.edu>,
> Howard Brazee <howard@brazee.net> wrote:
>
> [snip]
>
similar[color=darkred]
>
> Speaking as one who coded just such a thing (you know... one of those
> 'it's blowing up and we have 15 minutes before the evening cycle' sort of
> thing, there's always enough time to do it over but never enough time to
> do it right)... one did what one did and Prod kept running.
>
> (Curious, though, to compare an... 'oddity' in a compiler with the tricks
> users employed to get around such 'oddities'.)
>
> DD
>

docdwarf@panix.com

2004-03-27, 11:50 pm

In article <1069f8jbntmh6ab@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:
>
><d