Cobol - If you were inventing CoBOL...

Author

If you were inventing CoBOL...

Richard

2004-09-12, 3:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> No, very complicated decision blocks were their downfall. They worked
> well on small decision blocks (1-5 columns) and passibly on
> medium-sized (6-10). The problem is table size.

I don't see how you contrive the conclusion that they had a
'downfall'.

Decision tables were a tool just like other tools, eg flowcharts.
Certainly they become unwieldy when used inappropriately. This
doesn't stop them being used in appropriate scales.

> Assuming decisions are
> binary T/F, the number of columns for c conditions is (c^2)*2.

Let us see if this is true:

For c=1: c | Y N | 2 columns (1^2)*2 = 2

for c=2: c1 | Y Y N N |
c2 | Y N Y N | 4 columns (2^2)*2 = 8

for c=3: c1 | Y Y Y Y N N N N |
c2 | Y Y N N Y Y N N |
c3 | Y N Y N Y N Y N | 8 columns (3^2)*2 = 18

The actual formula is 2^c

> For c=5, there are 50 columns; 32
> for c-10, there are 200; 1024

> beyond that the
> table becomes impractical to represent

In the DTs that I used they could be Y/N/-(any) (this is called
abbreviation without affecting completeness check) and allowed for an
ELSE rule (which did affect completeness check). Thus the number of
conditions did not directly imply the number of columns. The number
of columns is related directly to the number of distinct meaningful
combinations of conditions that are dependent.

It would be equally wrong to assert that the number of IF statements
required to do the same job is your "(c^2)*2".

Given a task of equivalent complexity this can be done with: A set of
IF statements, or sets of nested sets of IF; an EVALUATE or a set of
nested EVALUATEs; a Decision Table or a set of nested DTs.

> Our next adventure was linear programming

Using Decision Tables for a Linear Programming problem is obviously
the wrong tool.

docdwarf@panix.com

2004-09-12, 3:55 am

In article <3misj0lu8ichlf3ueu9lc5he03m0mm44u6@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 7 Sep 2004 16:39:50 -0400, docdwarf@panix.com wrote:
>
>
>You can't receive per diem as 1099, only actual expenses. The
>difference is $10K in tax savings.

As I understand it one can receive per diem only when one is working more
than seventy miles away from one's declared residence... or something like
that. Have things changed?

DD

Robert Wagner

2004-09-12, 3:55 am

On 11 Sep 2004 21:19:34 -0400, docdwarf@panix.com wrote:

>In article <e1p6k0d279r7da4r8uoe7vql9m5cfungcm@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>01 A-TBL.
> 05 TBL-ITEM OCCURS 1 TO 5000 DEPENDING ON WS-TBL-ITEM-DEPENDS.
>
>My eyes are not what they used to be, Mr Wagner... might you be so kind as
>to give that a read-through and see what you find to come 'right after the
>word OCCURS'?

Pleased to help you, old timer. The limit on this table is 5000.

You're welcome.

Chuck Stevens

2004-09-12, 3:55 am

"LX-i" <lxi0007@netscape.net> wrote in message
news:Cfn_c.43711$5s3.25919@fe40.usenetserver.com...

> - Fall-through pararaphs - only the first paragraph after "PROCEDURE
> DIVISION" would be fallen through. Of course, this mandates scope
> delimiters for PERFORM, IF, etc. (which we currently have).

Ooog ... Add a paragraph label in the middle of code in an existing program
and suddenly it doesn't fall through to what used to be the second
paragraph? I'd be mighty uncomfortable with such a rule ...

-Chuck Stevens

docdwarf@panix.com

2004-09-12, 3:55 am

In article <nedtj05u837mv4q8vl8hr9r7v6cqsggo2e@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 7 Sep 2004 21:29:09 -0400, docdwarf@panix.com wrote:
>
>
>It's changed slightly, for the worse in most cases. The 70 mile test
>was replaced by "in another metropolitan area", which has never been
>defined. Working definition is 'another SMSA'. The DC SMSA includes
>suburbs in MD and VA.

So much for that, then... I'd fail the test of both mileage and SMSA.

[snip]

>If you work in a SMSA longer than 12 months, not only are you no
>longer eligible to receive per diem there, but also you've lost your
>tax home.

Ahhhhh, it comes back to me now... I recall, years on back, am agency that
screwed up on my contract somehow and was cutting me oversized checks for
a few months until they found out. The pimp called me and asked that I
sit down and write them a check for the amount in error to which I
responded 'Why not just take it out of my next paycheck?'... and he said
something like 'Murfle blurfle too much work.'

My response was 'Hey, you made the error, you have the tools to make it
right... you do the work, get back to me when you've cleaned up your
mess' and he got rather annoyed; one of the things he proposed doing was
getting in contact with the IRS and telling them that the client had told
him it was projected I'd be there longer than a year so I was no longer
eligible for per diem.

I asked 'You'd do that?', he responded 'In a heartbeat!'... and I followed
with 'You know, I'd have difficulty continuing my working relationship
with an organisation whose representative considers this to be a
conscionable way to do business... so I think tomorrow I'll call Bill down
at BlamfCo and tell him that things just aren't working out for me and he
should find someone to fill out the term of my contract...'

The corrected their error.

[snip]

>One would think a 1099 corporation could give its solitary employee
>per diem. Nope. It has to be a "Qualified Plan" i.e. reviewed and
>approved by the IRS. They won't approve a one person corporation plan.

Not all corporations are created equal, of course... 'twas e'er thus.

DD

Howard Brazee

2004-09-12, 8:55 am

On 9-Sep-2004, l.willms@jpberlin.de (Lueko Willms) wrote:

> I guess I would not have invented COBOL at all, but Oberon, or
> Component Pascal, as they call its latest incarnation. Or Ada ...

Which of those would have been possible and practical when CoBOL was being
designed?

> Anyway, COBOL should have had "Inline PERFORM" from the beginning,
> and all those improvements from COBOL-85 which made a real programming
> language out of it. No GOTO and no ALTER.

While I don't disagree with your recommendations - I have to ask what are the
qualities of "a real programming language" that you are referring to?

Richard

2004-09-12, 8:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

+ action1| x | | |
+--------+-----+-----+-----+
+ action2| | x | |
+--------+-----+-----+-----+
+ action3| | | x |
+--------+-----+-----+-----+[color=darkred]
> Nested EVALUATEs are an alternative to ALSO.
>
> evaluate cont-1
> when 'N' evaluate cond-2
> when 'N' ....
> when 'Y' ....
> end-evaluate
> when 'Y' evaluate cond-2

Not really, they don't do the same thing except maybe in some degraded
cases.

The ALSO acts as an AND. To illustrate this better I've extended the
decision table to include the else rule and the action blocks. This
gives:

EVALUATE Cond-1 ALSO Cond-2
WHEN "Y" ALSO "N"
PERFORM action1
WHEN "N" ALSO "Y"
PERFORM action2
WHEN ANY ALSO ANY
PERFORM action3
END-EVALUATE

EVALUATE was designed to be a direct implementation of decision
tables, though it does make these somewhat 'sideways'.

I used Decision Table Preprocessors in the 70s and these certainly
made it easy to do very complicated decision blocks. The preprocessor
created dozens of small paragraphs because there were no scope
terminators, but noone ever needed to look at that.

Joe Zitzelberger

2004-09-12, 8:55 am

In article <413752b1$0$20257$cc9e4d1f@news-text.dial.pipex.com>,
"Michael Russell" <michael.russell@spamex.dsl.pipex.com> wrote:

> The biggest omission, as far as I'm concerned - Date, DateTime & Time types,
> plus the arithmetic functions for them.
>
> Michael
>
>

Amen!

Joe Zitzelberger

2004-09-12, 8:55 am

In article <413C9A1A.A5F7E136@mb.sympatico.ca>,
Peter Lacey <lacey@mb.sympatico.ca> wrote:

> LX-i wrote:
>
> mas agua caliente, por favor ...
>
>
>
> Me: COBOL, RPG, 360-style assembler, FORTRAN (a long time ago), PRIME
> Infobasic, and PROGRESS: plus a bit of VB and a tiny bit of C. I have
> seen two styles of CASE implementation:
>
> BEGIN CASE
> CASE x = y
> ...
> CASE b = a
> ...
> CASE TRUE (i.e., the default)
> ...
> END CASE
>
> or
>
> CASE variable
> WHEN value
> ...
> WHEN another value
> ...
> ELSE (default)
> END CASE.
>
> The second is much more precise and far more focused.
>
> I see from somebody else's post that EVALUATE was implemented to encode
> decision tables (which I didn't know); that gives it a rationale; but
> it's still an abomination. You can equate various aspects of EVALUATE
> to either style, as you please.
>
>
> (Please note that I don't have an up-to-date COBOL reference).
> PL

The second style is a subset of EVALUATE. You can code, and have it be
completely legal and reasonable:

EVALUATE some-number
WHEN 1
...do something...
WHEN 2
...do something else...
WHEN 3
...do something else...
WHEN 4
...do something else...
WHEN OTHER
...do something else...
END-EVALUATE

This is exactly your second style from above.

Some of the problems with that type of CASE structures, in some
languages, is that it is sometimes the case (-;) that the value of
"some-number" must be known at compile time.

But Cobol Evaluate offers a much richer type of case, which you are
never forced to use if you prefer the simple case above. Cobol Evaluate
allows you to define the condition as an expression or a variable. It
allows multiple conditions to be evaluated at once. Finally, it allows
you to use literals, variables or expressions in the when clauses.

It is totally flexible.

Richard

2004-09-12, 8:55 am

"James J. Gavan" <jjgavan@shaw.ca> wrote

[color=darkred]
> Naturally when you hit a series of repetitive 'No's you aren't interested.

The convention of Decision tables is that '-' indicates 'don't care',
which is ANY in the EVALUATE, and that the last rule column is the
'else' or catchall.

This is why nested evaluates don't work the same, there has to be
duplication of action blocks and multiple 'when other'.

> Perhaps Richard can expand a little - I'm assuming (1) He has drawn up the
> Decision Table
> with 'meaningful' condition names to work out his logic, and then has the
> table commented into the code,

When I was using formal decision table pre-processors these were left
in the source code, yes. In some case the DTs came from other sources
such as business specifications and were just dropped into the program
without much change.

These days I tend to use 'table driven' programs where the 'decision
table' is actually a W-S table or even on the disk file so that it can
be changed as required by the client without recompiling the program.

> (2) Are the Yes's and No's then written into a Yes/No table in W/S ?
> On #2 perhaps he doesn't - maybe he is setting Level 88 conditions ?

I generally dislike 88 levels and don't use them. They make the code
soggy and hard to light.

I have a couple of books from the 70s:

An Introduction to Decision Tables, Herman McDaniel
Programs from Decision Tables, E. Humbly.

The latter explores techniques for generating code. However with
EVALUATE it can be trivial to do this.

Robert Wagner

2004-09-12, 8:55 am

On 7 Sep 2004 05:17:57 -0400, docdwarf@panix.com wrote:

>In article <r97qj0tphnr9ab5t3iku5l9e6arfvvujeb@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>Yes, but your original assertion was that such initiatives came from
>programmers, not management. Curious that you would support this
>assertion with an example of the opposite.

I was wearing two hats. The request came from the programmer side, was
approved by the manager side and passed up the ladder.

I said the need for BMC on VSE came from programmers because
non-technical managers would not perceive it. It wouldn't have been
mentioned by the IBM salesman nor aforementioned magazines.

Richard

2004-09-12, 8:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> I've seen one or two who were good at vi. The vast majority stumble
> and project inefficiency.

Was that 'the vast majority' of those that you have seen using vi
(possibly a small number) or were you asserting 'the vast majority' of
all vi users, even though you have no idea who they are ?

> The problem is an editor that doesn't let you overtype changes, how
> basic is that?,

In what way does vi 'not let you overtype changes' ? It may be that
you simply don't know how to do this.

> doesn''t have Find All, doesn't let you navigate
> between files except by sequential cycling, doesn't support
> hyperlinks, doesn't let you open multiple windows, etc. etc.

Wow, I find that NotePad doesn't do any of that either, so Windows
editors are all crap.

In fact when I do a 'vi' I get to have multiple windows, jump via tags
to another file and all manner of things.

Robert Wagner

2004-09-12, 8:55 am

On Tue, 7 Sep 2004 14:46:39 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:gr7sj0dojf1b1s1qlocvigaevfubik81q9@
4ax.com...
>types,
>
>This provides for Date values, but how does it provide for DateTime, or for
>that matter, Time, manipulation, using standard representations?

For those, one uses ESQL, which can do both. :)

SELECT (TIMESTAMP(:finish-time) - TIMESTAMP(:start-time)) INTO
:duration FROM DUAL;

Foul? OK, create DateTime and Time classes in OO Cobol and provide
them with appropriate methods to import and export standard
representations from a non-OO program. OO doesn't require a change to
OO thinking. One can continue writing non-OO programs and use OO to
simply create new types and extend the language without waiting for a
committee. I did exactly that in OODEMO. This code snippet could
easily have been generalized to 'invoke a-Time 'subtract' using
start-time stop-time returning duration'.

invoke a-Timer 'stop' returning elapsed-time

.. method-id. 'stop'
.. local-storage section
.. 01 temp-time pic x(08)
.. 01 end-time comp pic s9(09)
.. linkage section
.. 01 elapsed-time comp pic s9(09)

.. procedure division returning elapsed-time.
if running
accept temp-time from time
invoke self 'time-to-integer'
using temp-time returning end-time
compute elapsed-time rounded = end-time - start-time
set running to false
end-if
exit method
.. end method 'stop'

.. method-id. 'time-to-integer'
.. linkage section
.. 01 input-time
.. 05 hours pic 99
.. 05 minutes pic 99
.. 05 seconds pic 99
.. 05 hundredths pic 99
.. 01 output-time comp pic s9(9)

.. procedure division using input-time returning output-time.
compute output-time =
((((((hours * 60) +
minutes) * 60) +
seconds) * 100) +
hundredths)
exit method
.. end method 'time-to-integer'

.. end object
.. end class timer
..

Robert Wagner

2004-09-12, 8:55 am

On 7 Sep 2004 16:41:50 -0700, riplin@Azonic.co.nz (Richard) wrote:

>"Howard Brazee" <howard@brazee.net> wrote
>
>
>As with any conversion between languages, one may not wind up with 'a
>Cobol program' but with an 'RPG program in the syntax of the Cobol
>language'.

I wrote a DIBOL-to-Cobol conversion program whose design objective was
'maintainable, pretty Cobol'.

DIBOL is a Basic-like language that has out-of-line exception handlers
for everything, including ON SIZE ERROR faults. The exception handlers
are turned on and off by inline procedural code. Typically, they're
turned off most of time and turned on only for statements that need
it.

So the assignment statement 'b=a' could be converted to 'move a to b',
if the handler was off, or to 'compute b = a on size error perform
numeric-error', if it was on or unknown. The latter is not 'pretty'
maintainable Cobol, especially when there are thousands of them.

How to tell whether the handler is or might be on required simulating
all execution paths that might lead to 'b=a'. On large monolithic
spaghetti programs that were typical, I found the number of possible
paths was tens of thousands. I spent w

s trying to reduce the number
of paths, without success. Finally, I gave up. If 'set handler on' was
in the same 'paragraph', I generated compute else I generated move.

As a practical matter, that solution seemed to work. To a purist, it
was Wrong.

Some languages are so poorly designed that they cannot be translated
to 'pretty' Cobol.

Robert Wagner

2004-09-12, 8:55 am

On 7 Sep 2004 18:11:39 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
>Let us see if this is true:
>
>For c=1: c | Y N | 2 columns (1^2)*2 = 2
>
>for c=2: c1 | Y Y N N |
> c2 | Y N Y N | 4 columns (2^2)*2 = 8
>
>for c=3: c1 | Y Y Y Y N N N N |
> c2 | Y Y N N Y Y N N |
> c3 | Y N Y N Y N Y N | 8 columns (3^2)*2 = 18
>
>The actual formula is 2^c
>

You're right. I stand corrected.
[color=darkred]
>In the DTs that I used they could be Y/N/-(any) (this is called
>abbreviation without affecting completeness check) and allowed for an
>ELSE rule (which did affect completeness check). Thus the number of
>conditions did not directly imply the number of columns. The number
>of columns is related directly to the number of distinct meaningful
>combinations of conditions that are dependent.

Right, 2^c is the max. Our software looked not only for completeness
but also for redundancy i.e. columns that could be combined by
changing a value to any and/or rewriting a condition.

>It would be equally wrong to assert that the number of IF statements
>required to do the same job is your "(c^2)*2".
>
>Given a task of equivalent complexity this can be done with: A set of
>IF statements, or sets of nested sets of IF; an EVALUATE or a set of
>nested EVALUATEs; a Decision Table or a set of nested DTs.

A procedural solution can have fewer IF statements when the conditions
are inequalities because it can compute intermediates which become
inputs to the next batch of IFs. Also, it can reiteratively converge
on a solution with simpler logic than would be required for a one-pass
solution.

>
>Using Decision Tables for a Linear Programming problem is obviously
>the wrong tool.

Not so fast. Our inputs to both were the very same inequalities.
There were 20-30 of them. D/T wanted to solve the problem in one pass
whereas LP eliminated the least important on each iteration.

Richard

2004-09-12, 8:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote

> I think that every current type of program could have been created with these
> restrictions *and* I think (but can't prove it) that such a language would have
> insured "easier to maintain" programs.

That may well be true, however, without, say, ALTER it may have been
difficult to get programs to fit into the machines that were available
at the time. Having to do first-time and last-time testing using a
flag and test would have used more memory. The difference between
assembler program size and that of an equivalent Cobol would have been
much more marked. The cost of using Cobol would thus have been much
more because the cost of memory was huge compared to that of
programmers time.

Today the costs have reversed. A Gigabyte is less than the cost of one
programmer for a day, while in 1959 one K of core was more than the
cost of a programmer for a year.

Thus, in 1959, the language had features to save memory. It also had
features to save programmer time (when compared to assembler) but only
where this did not conflict with fitting it into the computer they
could afford.

Sure, take back 'what you know now' to 1959, but also take back a
machine that you can buy now for 'pocket change' that would allow them
to use those ideas.

Richard

2004-09-12, 8:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
> If they'd used lists rather than unsupported tables, rewrite would
> have been unnecessary when better hardware/software removed the
> restriction.

Your argument is a religeous one:

Tables weren't 'unsupported'. The size wasn't directly supported.

Rewrite was unnecessary anyway. All that was necessary when the
restriction was removed was to up the OCCURS value. How hard is that
?

Lists are not directly interchangable with tables. Lists are either
serial only or require more complex linking and traversal code.
Tables can be directly accessed by a calculated index number.
Simplistic lists, as implemented in the way you have shown, are
generally slower than tables, and may be _much_ slower.

Double linked lists, trees, and other exotic structures are far more
complex and error prone and may be considerably slower.

William M. Klein

2004-09-12, 8:55 am

Also, the compiler that had 32K size limits didn't support USAGE POINTER so
"lists" would have been a problem to implement.

--
Bill Klein
wmklein <at> ix.netcom.com
"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0409072338.3ded2d39@posting.google.com...
> Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
> Your argument is a religeous one:
>
> Tables weren't 'unsupported'. The size wasn't directly supported.
>
> Rewrite was unnecessary anyway. All that was necessary when the
> restriction was removed was to up the OCCURS value. How hard is that
> ?
>
> Lists are not directly interchangable with tables. Lists are either
> serial only or require more complex linking and traversal code.
> Tables can be directly accessed by a calculated index number.
> Simplistic lists, as implemented in the way you have shown, are
> generally slower than tables, and may be _much_ slower.
>
> Double linked lists, trees, and other exotic structures are far more
> complex and error prone and may be considerably slower.

Howard Brazee

2004-09-12, 8:55 am

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

>
> I'd still be uncomfortable with a language specification in which control
> would fall through the second, and *only* the second, paragraph in a
> program.

I didn't understand that bit and replied with a question why there should be one
drop through. Zero seems better to me.

> I don't see that the standard for COBOL should *enforce* structure to a
> program, only that it should *allow* and *support* it.

We can't change this now. But it DOES enforce structures. Working Storage is
before Procedure. Nobody would have considered it enforcing structure if,
from the beginning, the only way to get to a paragraph was to perform it. The
only way to do subroutines was to call them. Nobody felt constrained that we
can't drop through to subroutines.

If a program has in its procedure paragraph (call it MAIN, or don't give it a
name at all), 50 PERFORMS and none elsewhere, that program isn't structured the
way we think of it. There would still be style wars.

James J. Gavan

2004-09-12, 8:55 am

Robert Wagner wrote:

>On Wed, 08 Sep 2004 03:44:21 GMT, "James J. Gavan" <jjgavan@shaw.ca>
>wrote:
>
>
>
>
>I did "new" to construct an instance. I didn't like the idea of
>putting the timer at the class level (factory) because then there
>could only be one timer per program. Here's the top part. Do you have
>suggestions for improvement?
>
>
>
No that's fine as you have done it - your point about wanting more than
one timer per program - identifying each 'timer' by an instance. Of
course if you were only using one per program, then the functions could
have just been in FACTORY.

Jimmy

Chuck Stevens

2004-09-12, 8:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:chn96a$35j$1@peabody.colorado.edu...
> It would be nice if the COPY REPLACING statement was designed from the
scratch
> for prefixes and suffixes.
>
> I wanted to use it to change the prefix on a file and also replace
==comp-3== by
> ==display==.

I don't much like the "partial-token replace" that is, as far as I'm
concerned, the consequence of an insufficiently-well-thought-out definition
for "COBOL word" in the standard.

But are you aware of "REPLACING LEADING" and "REPLACING TRAILING" in the
2002 standard? This is syntactically fairly clean, I think.

-Chuck Stevens

Richard

2004-09-12, 8:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> I hit R, replacement character, cursor right, R, replacement
> character, etc. Is there another way?

You may be doing that with r (lower case) which is 'replace one'.
Using R (upper case) puts you into replace mode where you just type
the replacement until esc to end the mode.

It seems the problem _is_ your knowledge of it.

docdwarf@panix.com

2004-09-12, 8:55 am

In article <56g7k0hgdkb0a89nn1euro8osbg0la4rok@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 11 Sep 2004 21:19:34 -0400, docdwarf@panix.com wrote:
>
>
>Pleased to help you, old timer. The limit on this table is 5000.

Mr Wagner, do you always have such problems answering what is asked of
you? My question, as you quoted above, was not 'what is the limit of the
table'... second request, then: might you be so kind as to give that a
read-through and see what you find to come 'right after the word OCCURS'?

>
>You're welcome.

Mr Wagner, you might be thanked after you answer the question... but not
by me for what you've supplied so far.

DD

Robert Wagner

2004-09-12, 8:55 am

On 8 Sep 2004 05:27:19 -0400, docdwarf@panix.com wrote:

>Ahhhhh, it comes back to me now... I recall, years on back, am agency that
>screwed up on my contract somehow and was cutting me oversized checks for
>a few months until they found out. The pimp called me and asked that I
>sit down and write them a check for the amount in error to which I
>responded 'Why not just take it out of my next paycheck?'... and he said
>something like 'Murfle blurfle too much work.'

I had the same situation. The company reached into my checking account
via 'direct deposit' and took it back BEFORE talking to me. Most
people don't realize that direct deposit is bi-directional. The
capability exists to currect errors like this.

Months after the project ends, an unprincipled pimp might reach into
your account with such a 'correction'. Then the burden is on you to
get it back. Be sure to withdraw direct deposit authorization the day
after the last paycheck hits.

Robert Wagner

2004-09-12, 8:55 am

On 8 Sep 2004 11:56:51 -0700, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>
>You may be doing that with r (lower case) which is 'replace one'.
>Using R (upper case) puts you into replace mode where you just type
>the replacement until esc to end the mode.

Excellent! Thank you.

>It seems the problem _is_ your knowledge of it.

That's in evidence here.

Robert Wagner

2004-09-12, 8:55 am

On 11 Sep 2004 15:13:05 -0700, riplin@Azonic.co.nz (Richard) wrote:

>"James J. Gavan" <jjgavan@shaw.ca> wrote
>
>
>Robert has told us that everyone he worked for went bankrupt.
>
>If there is a causal relationship in there it is not yet clear whether
>employing Robert was a cause or an effect.

'I don't want to work for a company that would hire someone like me.'

Robert Wagner

2004-09-12, 8:55 am

On Sat, 11 Sep 2004 15:06:43 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:mt76k0dbt25is9dnsgmqcfqj3nehr293hc@
4ax.com...
>
>Mr Wagner, consider that a method is an identified, perhaps
>named, procedure (function, process, recipe, etc.) for doing
>something. Now consider the difference between
>ChocolateCake:'Baking' and ChocolateCake:'Bake'.
>The first suggests the recipe itself. The second a command
>to follow the recipe.

Compare 'Start baking a cake' to 'Start bake cake'. The latter is how
two-year-olds talk.

>One other point, Mr Wagner. INVOKE in COBOL has
>a similarity to LET in BASIC. It is not necessary for one to
>mentally process the word to understand that a command
>is to be executed, though INVOKE is necessary for syntax.

In 'Let A take the value of B' and 'Let A equal B', the object of Let
is A. There is no need to modify the verbs because they are not the
objects of Let.

>Consider that
> [Invoke] EmployeeMaster:'Read' using EmployeeRecord
>is understandable without 'Invoke' and, under certain conditions
>is equivalent to the COBOL statement
> Read EmployeeMaster into EmployeeRecord.
>That is, under certain conditions, method names have an
>equivalence to COBOL verbs and may be considered as
>extension to the instruction set.

This is true. It explains why Inline Invocation is better than INVOKE
-- because it lets us say the verb in the same way we say normal Cobol
verbs such as READ.

>Given the subject of this thread, Mr Wagner, would your
>COBOL instructions be READING, WRITING, ADDING,
>SUBTRACTING, etc.?

That would be wrong because they are not preceeded by a verb.

If they were, the form would be PERFORM READING, DO WRITING, CARRY OUT
ADDING, etc.

docdwarf@panix.com

2004-09-12, 8:55 am

In article <8ra8k01novaf5qivmjsn6nt01erhpla9mf@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 11 Sep 2004 15:13:05 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>
>'I don't want to work for a company that would hire someone like me.'

'The work around here is stultifyingly boring, horrendously dull and
really kills any kind of passionate or creative soul one could bring to a
job... and there's so little of it, too!'

DD

Peter Lacey

2004-09-12, 8:55 am

LX-i wrote:
>
> Peter Lacey wrote:
>
> Mostly English - a little bit of Spanish... ;)

mas agua caliente, por favor ...

>
> I've worked in COBOL, VB, Ada, Java, PHP, and a wee bit of C++ and FORTRAN.
>

Me: COBOL, RPG, 360-style assembler, FORTRAN (a long time ago), PRIME
Infobasic, and PROGRESS: plus a bit of VB and a tiny bit of C. I have
seen two styles of CASE implementation:

BEGIN CASE
CASE x = y
....
CASE b = a
....
CASE TRUE (i.e., the default)
....
END CASE

or

CASE variable
WHEN value
....
WHEN another value
....
ELSE (default)
END CASE.

The second is much more precise and far more focused.

I see from somebody else's post that EVALUATE was implemented to encode
decision tables (which I didn't know); that gives it a rationale; but
it's still an abomination. You can equate various aspects of EVALUATE
to either style, as you please.

(Please note that I don't have an up-to-date COBOL reference).
PL

Richard

2004-09-12, 8:55 am

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> .. and delete table extension(s) .. and possibly delete the BLL cell
> fixup code .

Those are not _necessary_, but they may be done. Even is _far_ from
being the "rewrite" that you claimed.

Changing from MFs SET ADDRESS (unsupported by Fujitsu) to
BASED-STORAGE now _that_ is a rewrite.

> A recurring beginners' question is 'why don't databases have OCCURS?'

Which seems completely irrellevant. And besides I've never come
across that.

> Seems to me like good design. If it makes sense for structures on
> disk, why doesn't it make as much sense for structures in memory?

> In databases, 'table' is a misnomer. The structures are actually lists
> linked by a tree-like index.

In relational databases the data is held in 'tables' . They are
logically exactly the same as tables there is no 'misnomer'. How
these are implemented is quite irrelevant and completely opaque.
There is no reason that they can't be done exactly like your CISAM MF
files which are just a table with a _separate_ index. In fact some
databases, notably Informix, which does, or at least did, use exactly
those CISAM files.

> You're confusing tables with 'direct' structures accessed via hash.
> How does one calculate the index number in a table?

How about : divide by 2 for a binary chop search ? Try doing that on a
list.

>
> My results showed slightly slower, and that was because of an
> implementation detail in Micro Focus -- calling the runtime for one
> and not the other.

Strangely they are also slower in Fujitsu. In fact they are
inherently slower even when they are simple single linked lists.

>
> Talk about religion. You're asking the simplicity gods to protect us
> from our own mistakes.

Exactly. The principle is KISS. If a system can be made to work
reliably using simple components that are demonstrably error free then
only a fool would complexify it for no benefit.

> Lookups via a balanced tree run exactly as fast
> as a binary chop -- both take log2 (n) looks.

But they are _much_ slower to create. They are also slower for each
'look'.

> In practice, there are
> two differences that make tree lookups faster:

> 1. If the table is not truncated to its actual size by using Occurs
> Depending On, binary chop will take log2 (max) rather than log2 (n).

This does not make 'tree lookups faster'. It may make a table binary
chop fractionally slower, but still faster overall than loading and
searching a tree.

> Simplicity advocates, hung by their own petard, usually avoid ODO
> because it's 'too complicated'.

Well there yer go, everyone except Robert is just too stupid to do it
right.

And is it these same 'simplicity advocates' that you are trying to
encourage to code up double linked lists and tree traversals ?

> 2. Binary chop REQUIRES the entries be sorted. If they aren't
> naturally, one must add sort time to the comparison. Balancing a tree
> is analogous to the sort time, but tree lookups don't REQUIRE that the
> tree be balanced. They run correctly albiet a little slower with an
> unbalanced tree

When presented with ordered data they degrade to a linked list with
only the right branch ever used and thus work much slower then a
single linked list.

To produce a reasonable balanced tree either they must be given data
ordered randomly, for example by sorting using a random number as the
key, or the tree must be rotated when unbalance is out by given
amount.

Rotation code can be very complex, with a need to detect when it is
actually required. Poorly done it can become unstable in some cases
when the rotation is done and then undone on the next access.

> (think of an indexed file requiring reorganization).
> Overall speed depends on the ratio of looks vs. organization time.
> When the number of looks is less than approximately n, tree lookup is
> faster because it doesn't have the overhead of organization.

You were wrong when you claimed simple lists were faster. There may be
specific cases where loading a tree does produce an insignicant time
saving over a SORT plus SEARCH ALL, and it would be _much_ slower if
the data were naturally ordered.

But quite frankly I wouldn't care it was faster or not. I know from
having done it how complex trees can be and I really don't see the
point in recoding 'what C did in the 70s'.

Lueko Willms

2004-09-12, 3:55 pm

.. Am 08.09.04
schrieb robert@wagner.net.yourmammaharvests (Robert Wagner)
auf /COMP/LANG/COBOL
in c4puj0tqk37476s5fuka54i2s8ci6mcpcl@4ax.com
ueber Re: If you were inventing CoBOL...

RW> I had the same situation. The company reached into my checking
RW> account via 'direct deposit' and took it back BEFORE talking to me.
RW> Most people don't realize that direct deposit is bi-directional. The
RW> capability exists to currect errors like this.
RW>
RW> Months after the project ends, an unprincipled pimp might reach into
RW> your account with such a 'correction'. Then the burden is on you to
RW> get it back. Be sure to withdraw direct deposit authorization the day
RW> after the last paycheck hits.

Can't you instruct your bank to cancel that transaction?

Under German law, such a direct debit can be cancelled up to 6 w

s
after the debit date.

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)

docdwarf@panix.com

2004-09-12, 3:55 pm

In article <9GW2O0r9flB@jpberlin-l.willms.jpberlin.de>,
Lueko Willms <l.willms@jpberlin.de> wrote:
>. Am 08.09.04
>schrieb robert@wagner.net.yourmammaharvests (Robert Wagner)
> auf /COMP/LANG/COBOL
> in c4puj0tqk37476s5fuka54i2s8ci6mcpcl@4ax.com
> ueber Re: If you were inventing CoBOL...
>
>RW> I had the same situation. The company reached into my checking
>RW> account via 'direct deposit' and took it back BEFORE talking to me.
>RW> Most people don't realize that direct deposit is bi-directional. The
>RW> capability exists to currect errors like this.
>RW>
>RW> Months after the project ends, an unprincipled pimp might reach into
>RW> your account with such a 'correction'. Then the burden is on you to
>RW> get it back. Be sure to withdraw direct deposit authorization the day
>RW> after the last paycheck hits.
>
> Can't you instruct your bank to cancel that transaction?

I will qualify this by saying that my knowledge about such things is
close to a decade out-of-date, Mr Willms, but... to the best of my
knowledge, no.

>
> Under German law, such a direct debit can be cancelled up to 6 w

s
>after the debit date.

One of the reasons that I stopped using direct-deposit mechanisms was
being told by... someone whom the bank had answering the question-line
about such matters that once a company had been given authorisation to
make direct deposits (and the irremovable, associated authority to make
direct withdrawals by merely changing the sign on the transaction) this
authority could not be revoked except by changing accounts.

I do not know if this was true at the time - those who answer the
telephone at various institutions might, possibly, not have the fullest
and most subtle knowledge of said institution's policies and capabilities
- and I do not know if it is true now... but having this revealed to me
has caused me, as noted in another posting, to shun direct deposit
entirely.

DD

Howard Brazee

2004-09-12, 3:55 pm

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

> I could see, for example, some benefit to a sequence like:
> COPY LIB REPLACING LEADING ==SOME== BY ==FIRST-==,
> REPLACING LEADING ==GENERIC-== BY ==FIRST-==,
> REPLACING INVALID BY DISPLAY.
> COPY LIB REPLACING LEADING ==SOME== BY ==SECOND-==,
> REPLACING LEADING ==GENERIC-== BY ==SECOND-==,
> REPLACING INVALID BY COMPUTATIONAL.

My current compiler doesn't handle multiple REPLACING clauses. It will do
nested COPY statements, but not with REPLACING. It also doesn't handle
LEADING.

If I were designing CoBOL back when, I think I would have done the COPY
statement differently. IDD copies work well, but they weren't available back
then.

docdwarf@panix.com

2004-09-12, 3:55 pm

In article <m9l0k0pd9nt5oriajrc92417rdt4k47952@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 8 Sep 2004 17:45:21 -0400, docdwarf@panix.com wrote:
>
>
>
>Better to open a second account at the same bank, use scheduled
>electronic transfer to move funds to your main account.

Hmmmmm... I don't know how scheduled EFT works but any time I've done the
manual version there's been an associated charge for it. There'd also
have to be some jiggery-pokery for 'substandard' w

s, holidays, vacation
time and the like... perhaps some research would be in order should the
need arise.

>That way you
>avoid float rules that violate the spirit, if not the letter, of
>regulation CC. "It takes seven to ten days for an out of state check
>to clear." Someone should create a twelve-step program for bankers'
>addiction to float.

Float is time, time is money, money is what bankers are in business to
make... what comes next, reinstatement of usury laws?

Tangentially related... I'm in the habit of paying off my credit-cards in
full every month. The other day I got a statement saying that my interest
rate on a card had been increased; I called Customer Service and asked
why... the lass told me that they weren't earning enough on my account. I
asked two questions:

1) How much money would they have to earn in order to reinstate my lower
rate? ('I can't answer that but the accounts are reviewed semi-annually
for such considerations.' 'Oh... so you can tell me that what you earn
now is 'not enough' but you cannot tell me what 'enough' is?' 'Well, if
you want to put it *that* way, sir... but the accounts are reviewed
semi-annually...')

2) My rate was increased because I did not use my card a certain way. If
I now use my card that way it is going to cost me more money. Usually if
someone wants to encourage a kind of behavior they charge less for it; if
you want to encourage sales of an item you decrease the price. What sense
does it make to charge me more money for something that you want me to do?

(silence... 'Sir, it is our policy to...')

DD

Chuck Stevens

2004-09-12, 3:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:chpnsj$bc1$1@peabody.colorado.edu...
>
> On 8-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
>
> My current compiler doesn't handle multiple REPLACING clauses. It will
do
> nested COPY statements, but not with REPLACING. It also doesn't handle
> LEADING.

REPLACING is Library Module Level 2 in both the '74 and '85 standards.
Sounds like your compiler implemented Level 1. That's a really good example
of one of the reasons the '02 standard has no modules and no levels within
modules ...

LEADING and TRAILING are new in '02.

-Chuck Stevens

docdwarf@panix.com

2004-09-12, 3:55 pm

In article <jsr0k0hi00bdmcrlbmipfm09b1h6m3765u@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 9 Sep 2004 07:28:39 -0400, docdwarf@panix.com wrote:
>
>
>That's not true. You can withdraw the authorization. My bank does it
>over the phone, others may insist it be in writing.

As a Wise Person once said, Mr Wagner, 'Never believe anything you see
posted on the UseNet, including this statement.' Should I find myself in
a position which requires direct deposit I'll do my best to keep this, and
other advice, in mind.

DD

Howard Brazee

2004-09-12, 3:55 pm

01 TAPEOUT-RECORD.
COPY LAMMASTP REPLACING == 01 == BY == 02 ==.
- - - - - - - - - - - - - - - 15 Line(

COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.

The above code doesn't work.

It replaced PIC X(01) with PIC X(02)

What a pain. I may have to have both copies in Working Storage, with a
replacing to change the name of the 01 level in one of them.

Michael Wojcik

2004-09-12, 3:55 pm

In article <cjprj0prq523koe9plmd31hr6v8m6jbs5t@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> On 7 Sep 2004 14:58:51 GMT, mwojcik@newsguy.com (Michael Wojcik)
> wrote:
>
>
> I've seen one or two who were good at vi. The vast majority stumble
> and project inefficiency.

This may come as a shock, Robert, but your anecdotal experience does
not constitute a meaningful study. Actual studies performed by actual
researchers have shown that vi is as productive for experienced users,
in general, as other editors. (See eg [1] for abstracts.)

In any event, the thousands of happy vi users worldwide amply demonstrate
that your claim is bogus.

>
> The problem is an editor that doesn't let you overtype changes, how
> basic is that?,

vi has an overtype mode - command R.

> doesn''t have Find All,

vi has find all - command :p. Moreover, it has the very powerful
"global" command, :g, which lets you perform any ex command on all
matching lines. And it has global find-and-replace (with regular
expressions and parameterized replacement), with or without
confirmation.

> doesn't let you navigate between files except by sequential cycling,

Nearly every "improved" vi clone, such as vim, supports multiple file
buffers. vim ships as the default implementation of vi on a number
of Unix platforms. The original vi didn't support multiple file
buffers because it was designed to be compact, and traditional vi
still doesn't because there's no demand to change it - everyone who
wants these features uses an improved vi.

> doesn't support hyperlinks,

A clear advantage. "Supporting" hyperlinks is an idiotic feature.
An editor should not be an HTTP user agent or an FTP client. (It's
likely that some vi clones do "support" hyperlinks, anyway. And, of
course, even original vi supports replace-with-shell-command, which
combined with wget or the like will trivially "support" hyperlinks.
Wrap it in a macro if you like.)

> doesn't let you open multiple windows

"Graphical" vi clones do, but I don't count that an advantage (which
is why I don't use them). vi is a terminal-window editor. It doesn't
open any windows at all. That's how I like my programs to work.

Here are reasonable reasons to avoid vi:

- "I don't like vi".
- "I find vi hard to use."
- "I find modal editing does not fit well with my work habits."
- "I prefer GUI interfaces, and a graphical vi is not available on my
platform."
- "I have a different editor that I already like."

Here are unreasonable ones:

- "vi sucks."
- "No one [or "most people", or whatever unsubstantiated quantity you
prefer] can use vi well."

In other words, while it's perfectly reasonable to dislike vi, it's
not reasonable to claim that's a deficiency in the editor. vi wasn't
written for you. There wouldn't have been any point of contention if
you'd simply written "I hate vi"; as usual, it's your claim that your
experience is universally applicable that's caused the difficulty.

Now, if you'd care to identify some important feature that you can
reasonably claim is desired by most programmers and lacking in vi,
then you might have an argument. But consider first that two of the
five in your list above were outright wrong, another is widely
available in vi implementations, and the other two are of dubious
value.

--
Michael Wojcik michael.wojcik@microfocus.com

Advertising Copy in a Second Language Dept.:
The precious ovum itself is proof of the oath sworn to those who set
eyes upon Mokona: Your wishes will be granted if you are able to invest
it with eternal radiance... -- Noriyuki Zinguzi

Richard

2004-09-12, 3:55 pm

docdwarf@panix.com wrote

> Tangentially related... I'm in the habit of paying off my credit-cards in
> full every month. The other day I got a statement saying that my interest
> rate on a card had been increased;

I pay off my card in full (well actually I ensure that the wife pays
off her card, I just don't use credit cards), and here that means that
there never is any interest to pay, it only starts after the due date
a w

or two after the statement arrives.

In this case the interest rate is irrelevant as it is never invoked.

Frederico Fonseca

2004-09-12, 3:55 pm

On Wed, 08 Sep 2004 08:47:56 GMT, Robert Wagner
<robert@wagner.net.yourmammaharvests> wrote:

>On 7 Sep 2004 20:05:34 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>
>My sample is people I've watched, well over 100.
Well, I have worked with hundred of customers, all of them having
between 2 and 20 programmers (some very few had a lot more), and all
using Unix (and variants), using vi as editor. All of them worked very
well (except for the new arrivals at the companies, and even so some
already had experience elsewhere).

>
>
>I hit R, replacement character, cursor right, R, replacement
>character, etc. Is there another way?
A few.

You can replace
an entire line (cc or S) or until the end of line (c$ or C),
an entire word (or multiple words) - d4w will delete 4 words, c3w will
change 3 words 3c5w will delete 5 words 3 times (e.g. 15 words).

a single letter - r
as many letters you need - 5r.

And many many other options.

You just need to learn and use vi.

And when it cames to doing regular expressions then there is no editor
like vi that I know of.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Robert Wagner

2004-09-12, 3:55 pm

On 9 Sep 2004 16:19:45 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:

>In article <cjprj0prq523koe9plmd31hr6v8m6jbs5t@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:

>
>vi has find all - command :p. Moreover, it has the very powerful
>"global" command, :g, which lets you perform any ex command on all
>matching lines. And it has global find-and-replace (with regular
>expressions and parameterized replacement), with or without
>confirmation.

What I had in mind is what I call 'live grep'. It searches all the
programs being edited and creates a 'grep document' containing
matching lines. You can put the cursor on a line and hit a key to see
it 'in context' in the original file; another keystroke returns you to
the grep. Overtyping and global changes in the grep document are
changing the original. The grep document doesn't contain copies of
lines, it contains pointers to them.

Ultra Edit has a similar feature.

>
>Nearly every "improved" vi clone, such as vim, supports multiple file
>buffers. vim ships as the default implementation of vi on a number
>of Unix platforms. The original vi didn't support multiple file
>buffers because it was designed to be compact, and traditional vi
>still doesn't because there's no demand to change it - everyone who
>wants these features uses an improved vi.

How about a picklist of buffers rather than next, next, next?

>
>A clear advantage. "Supporting" hyperlinks is an idiotic feature.
>An editor should not be an HTTP user agent or an FTP client. (It's
>likely that some vi clones do "support" hyperlinks, anyway. And, of
>course, even original vi supports replace-with-shell-command, which
>combined with wget or the like will trivially "support" hyperlinks.
>Wrap it in a macro if you like.)

I was thinking of Cobol copybooks. You put the cursor on a line
containing copy or include (or just a file name), hit one key, it
takes every word on the line and searches the path for a file of that
name. It makes two passes, the first pass tries words containing a dot
or in uppercase or in quotes. When it finds the copybook or referenced
file, it adds it to the ring and opens it. One keystroke takes you to
the copybook.

>
>"Graphical" vi clones do, but I don't count that an advantage (which
>is why I don't use them). vi is a terminal-window editor. It doesn't
>open any windows at all. That's how I like my programs to work.

In text-mode editors it is reasonable to split the screen
(horizontally or vertically) into two windows. When editing Cobol, one
often wants to see the data division in one window and the procedure
division in another. When comparing two files, it is convenient to see
them side-by-side.

>Here are reasonable reasons to avoid vi:
>
>- "I don't like vi".
>- "I find vi hard to use."
>- "I have a different editor that I already like."

Those are my reasons.

>There wouldn't have been any point of contention if
>you'd simply written "I hate vi"; as usual, it's your claim that your
>experience is universally applicable that's caused the difficulty.

Yet another lesson in Usenet etiquette.

Howard Brazee

2004-09-12, 3:55 pm

On 9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Possibly your mistake was that you (like Chuck below <G> ) erroneously repeated
>
> the keyword "REPLACING"?
>
> You may NOT (in a Standard - '85 or '02) compiler repeat the replacing
> keyword,
> but you may have as many
>
> ==operand-1== by ==operand-2==
>
> phrases as you want.

I had that error, but just tried
COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==
==EDUSERV-RECORD= BY ==XXXX==.

without luck.

For documentation I look at
http://publibz.boulder.ibm.com/cgi-...RSTHIT#FIRSTHIT

or
http://makeashorterlink.com/?S5F726149

> P.S. Or is this one of your IDMS pre-compiler problems?

I don't see how.

Chuck Stevens

2004-09-12, 3:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:h4b1k05ig9p7td27942dserkso614kc8kq@
4ax.com...

> There is no reason to modify data passed BY CONTENT.

There isn't? Forty-five years of ALGOL programs that used parameters as
local variables once they'd examined the value have been Doing It Wrong???

> If the callee does so, it has a false expectation that changes are being
passed back
> to the caller.

No, in fact, it may be with the *correct and specific* expectation that the
changes made to the parameter will *not* be passed back to the caller!
Once the callee has made use of the value as passed from the caller, the
callee can do whatever he wants with the variable *without* fear of damage
upstream!

-Chuck Stevens

Howard Brazee

2004-09-12, 3:55 pm

On 9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>
> which is missing the 2nd "=" after "EDUSERV-RECORD"

That was the problem.

> which will cause a compiler error. If this was just a re-typing error, then I
>
> still want to see what the compiler is saying.

Posted in an earlier message.

Howard Brazee

2004-09-12, 3:55 pm

On 9-Sep-2004, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> Howard,
> The link you point to DOES show a "loop" for the replacing phrases. (See
> the
> "<" above operand-1).
>
> Exactly what error are you getting when you try this copy statement?

At the start of the listing (other errors are at the end)

328 IGYLI0088-S The "COPY" statement was invalid. Expected "BY", but
found "XXXX". The statement was discarded.

329 IGYLI0001-W A blank was missing before character "X" in column 59. A
blank was assumed.

329 IGYLI0001-W A blank was missing before character "=" in column 63. A
blank was assumed.

000328 006400 COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==

000329 006410 ==EDUSERV-RECORD= BY ==XXXX==.

000330 006500/

000331 006600 PROCEDURE DIVISION.

000332 006700

Alternatively, I can do:

000328 006400 COPY LAMMASTP REPLACING ==COMP-3== BY ==DISPLAY==.

000329C*
****************************************
********************************
000330C* ******* EDUSERV LOAN MASTER FILE COPYBOOK

000331C*
****************************************
********************************
000332C* ******* CHANGE LOG:

000333C* ******* DLOWENS 11/14/95 MR12505 - EXPAND FILE LAYOUT/EDUSERVE
CHG MR1250
000334C* ******* RPAYNE 11/14/95 MR11421 - ADD FLDS TO LAYOUT FOR
NSLDS MR1142
000335C* ******* RPAYNE 11/14/95 MR10661 - ADD FLDS TO LAYOUT
MR1066
000336C* ******* WC 4/93 NEW COPYBOOK CREATED SR#6893

000337C*
****************************************
********************************
000338C 01 EDUSERV-RECORD.

000339C 05 LN-DETAIL-RECORD.

000340C 10 LN-BORROWER-NAME PIC X(30).

000341C 10 LN-SOC-SEC-NUMBER PIC S9(09)
DISPLAY
....

Robert Wagner

2004-09-12, 3:55 pm

On Wed, 8 Sep 2004 12:54:53 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:oiasj05hgcd6pd6hvhjo4kvruafi76tp81@
4ax.com...

>
>Why and how is the reading of memory dumps made *easier* by a monolithic
>working-storage if the contents of every 01-level item are presented
>separately, identified by the 01-level item's name as well as the stack
>location of the descriptor pointing to it (corresponding to the map provided
>on the compilation listing)? The program dumps available to you *do* have
>that capability, right?

I don't work on mainframes nor read dumps. In the Good Old Days, IBM
dumps made no attempt at formatting. That's why programmers coded a
literal reading 'Working-Storage starts here' and always did
READ..INTO -- because it was hard to find buffers in a dump. That's
why third-party companies developed dump-formatting products like
Abend-Aid.

>
>I can see this having *some* utility in our environment, but if 01-level
>records aren't ALLOCATEd until they're accessed, I'm not sure why you'd
>*have* to go through all that trouble!

That requires operating system support -- a hook into the memory fault
handler. I don't think early IBM operating systems offered that.

>
>No, that's not right. Page 422, 14.8.4.3, CALL statement Syntax Rule 8
>mandates that if BY VALUE appears on a parameter in the caller it must also
>appear on the corresponding parameter in the called program, and that
>applies whether a prototype is used or not.

So it does. I was looking at the procedure division header spec.

William M. Klein

2004-09-12, 3:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:qhf1k010k1f3o9o1o2v36o1botloa6eqol@
4ax.com...
> On Wed, 8 Sep 2004 15:18:55 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
<snip>
> Some implementations extend the standard by replacing the record name
> without the need for REPLACING. For example:
>
> 01 OUTPUT-RECORD COPY foo.
>
> Where foo reads:
>
> 01 INVENTORY-RECORD.
> 02 ....
>
> However, 'COPY foo' in a sentence by itself would use
> INVENTORY-RECORD.
>

The behavior you describe above was available with IBM's OS/VS COBOL compiler -
but only when it was running in '68 Standard mode (specified as LANGLVL(1)).
When LANGLVL(2) (their '74 Standard mode) was in effect this did not work.

I won't swear to it (as I don't have the '68 and '74 Standards) but this may
well be a difference between the two ANSI Standards.

--
Bill Klein
wmklein <at> ix.netcom.com

--
Bill Klein
wmklein <at> ix.netcom.com

Robert Wagner

2004-09-12, 3:55 pm

On Thu, 9 Sep 2004 12:25:58 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:h4b1k05ig9p7td27942dserkso614kc8kq@
4ax.com...
>
>
>There isn't? Forty-five years of ALGOL programs that used parameters as
>local variables once they'd examined the value have been Doing It Wrong???

Is memory so expense they can't afford their own local variables?

>passed back
>
>No, in fact, it may be with the *correct and specific* expectation that the
>changes made to the parameter will *not* be passed back to the caller!
>Once the callee has made use of the value as passed from the caller, the
>callee can do whatever he wants with the variable *without* fear of damage
>upstream!

After finding the value in foo is wrong, I search for all places where
foo is modified. Now, I have to notice whether foo was passed BY
CONTENT? I don't think so.

We potentially had the same problem before. A program could modify an
output record, then never write it. In all the code I've worked with,
I can't recall ever seeing that happen .. at least on purpose. If I
did catch someone doing that, I'd accuse him or her of deceptive
programming and insist it be changed.

docdwarf@panix.com

2004-09-12, 3:55 pm

In article <chqg2m$oj9$1@peabody.colorado.edu>,
Howard Brazee <howard@brazee.net> wrote:
>
>On 9-Sep-2004, docdwarf@panix.com wrote:
>
>
>But are the principals interested?

Some are, some aren't... I guess it depends on how principled they are.

DD

Rick Smith

2004-09-12, 3:55 pm

"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:6rd8k0l8ejudlnug25mppml9qu3qod2rfq@
4ax.com...
> On Sat, 11 Sep 2004 15:06:43 -0400, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
function[color=darkred]
>
> Compare 'Start baking a cake' to 'Start bake cake'. The latter is how
> two-year-olds talk.

Consider, *preparing* (the act of a person who prepares)
Wagner's Vegetarian Medley cannot exist independently of
Wagner writing the recipe. Wagner is not necessary to
*prepare* the dish according to the recipe.

Also, invoke has a sense of 'do the following'. Thus "Do the
following, 'Baking a cake'", makes no sense; but "Do the
following, 'Bake a cake'", does make sense. I have not yet
found a sense of invoke the includes 'start'.

[invoke: to cause, call forth, or bring about. -- RHCD]

>
> In 'Let A take the value of B' and 'Let A equal B', the object of Let
> is A. There is no need to modify the verbs because they are not the
> objects of Let.

As I show above, the entire command is the object of invoke,
not just the method name. Computer languages are not natural
languages. But, if one defines 'this command' as the text
following 'invoke', then 'invoke this command' gives the
verb-noun combination you're trying to achieve. And, this is
why 'invoke' is not necessary to the understanding.

>
> This is true. It explains why Inline Invocation is better than INVOKE
> -- because it lets us say the verb in the same way we say normal Cobol
> verbs such as READ.

Mr Wagner, better? Or just different? INVOKE is required
for syntax. It is not required for understanding. Treating
INVOKE as more than it is invites confusion.

docdwarf@panix.com

2004-09-12, 3:55 pm

In article <chqpmr$1ail$1@si05.rsvl.unisys.com>,
Chuck Stevens <charles.stevens@unisys.com> wrote:
>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:khd1k0lpf3vrl06mghimnoe9es8p82puh6@
4ax.com...

[snip]

>
>"Normalized design" is orthogonal to "cannot design an unnormalized data
>base". "Normalization" is a religious war. "Unnormalized" databases have
>existed since long before the publication of Dr. Codd's theories *and* IBM's
>apparent endorsement of them in about 1978; such databases have been
>supplying the needs of happy customers for thirty years now.

Hmmmmm... reminds me of an exchange I had with a co-worker, sometime
around 1987 or so:

Him: dBase is great, man... a fully relational database that'll fit on
your PC!

Me: dBase has it points, both good and bad... but it is not 'a fully
relational database'.

Him: It ain't? Who says says so?

Me: Dr E. F. Codd.

Him: Oh, throw some (fornicating) names at me, why don'cha!

DD

James J. Gavan

2004-09-12, 3:55 pm

Robert Wagner wrote:

>On 8 Sep 2004 23:13:09 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>
>
>
>
>
>
>SET ADDRESS is unsupported but implemented by Fujitsu.
>
>I really doubt compiler companies will delete extensions that once
>worked. When Micro Focus or IBM releases a 2002 compiler, do you think
>we'll have to rewrite SET ADDRESS to BASED-STORAGE?
>
>
>
>
>One cannot insert a row between two existing ones in a Cobol table.
>
>
<Snip>

Robert,

I haven't been following it - we are not there yet - but go take a
lookee at J4 - referencing papers written by John Piggott on Dynamic
Tables. (The very latest is authored by Piggott and Karlin). I'd bet
this point and some of those you made later are covered - close
proximity to the OO collection approach.

Jimmy

>
>
>
>Try doing that on an unsorted table. While you're sorting the table,
>I'll build a tree. Never mind, it's already built. I'll do the lookups
>in the unbalanced tree while you're sorting. Want to see it again?
>I'll do them a second time while you're STILL sorting.
>
>
>
>
>Sorting is inherently complex too. We hide that from the user by
>putting the logic in a library called by the SORT verb. The same could
>have done for lists.
>
>In the old days, structures natively supported by the language, such
>as tables, had a simplicity advantage over structures we had to manage
>ourselves. OO changed the balance. We can now create types and
>supporting methods that are nearly as easy to use.
>
>Someone said 'Two things would sicken the average citizen: the inside
>of a slaughterhouse and seeing how government actually works.' We seem
>to have found a third in data management algorithms.
>
>
>
>
>The principle is MISS -- Make It Simple, Stupid .. even if it isn't.
>
>
>
>
>A pointer to the next entry in a list is no more complex than adding 1
>to a subscript. In fact, it's simpler. I don't have to multiply by the
>size of an occurrence to find it.
>
>
>
>
>Do you have evidence? I posted code that did it both ways and measured
>total build and lookup time to be:
>
> MF table sort, search all 5.1
> tree, lookup (unbalanced) 2.6
> tree, balance, lookup 2.6
>
>
>
>
>I didn't say everyone; I said simplicity advocates.
>
>
>
>
>No, I posted that for people wanting to learn how to program. Others
>will continue doing it the slow way until someone hands them an
>easy-to-use package.
>
>
>
>
>In that case, the lookup could switch to binary chop. I posted a demo
>that sorted by rotating the tree until everything was on the right,
>then did lookups with binary chop.
>
> tree, to table, search all 2.9
>
>If inputs had been in sequence, rotation would have stopped after one
>pass. Time would have been 1.3.
>
>
>
>
>Random inputs do not produce a well-balanced tree. One has to
>unbalance it until everything is on the right (or left), in other
>words sort the entries. Only then can a balanced tree be built.
>
>
>
>
>'I tried that once and ran into problems. It follows, therefore, that
>nobody else should be allowed to use it.' I once worked for a manager
>who set shop standards by that logic. She wouldn't allow Cobol SORT
>because she had trouble with it ten years earlier.
>
>
>
>
>See above. Twice the speed is not insignificant. The specific case was
>50,000 random 30-byte keys, which seems typical of everyday use.
>
>
>
>
>It would be the same, because tree search would detect that and switch
>to binary chop.
>
>
>
>
>It is a prelude to managing more complex structures in databases. You
>have to crawl before you can walk.
>
>

James J. Gavan

2004-09-12, 3:55 pm

LX-i wrote:

> Howard Brazee wrote:
>
>
>
> Well, program flow has to start _somewhere_ - are you saying don't
> have an initial paragraph?

Well there's a truism. Somebody really *bright* reference OO, once
wrote, "But you are thinking procedural", i.e. a "main", "begin", or
whatever. Years ago went around a cookie factory in Wales. The damn
things don't just create themselves ! Somebody has to chuck a whole lot
of fat, flour, liquid etc. into a vat - call it housekeeping if you
like - but that starts the process. Oh yes - more 'housekeeping' -
somebody has to clean up the bloody mess when the production is finished.

Jimmy

Richard

2004-09-12, 3:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> In text-mode editors it is reasonable to split the screen
> (horizontally or vertically) into two windows. When editing Cobol, one
> often wants to see the data division in one window and the procedure
> division in another.

When I use vi I get that.

> When comparing two files, it is convenient to see
> them side-by-side.

I find it _much_ more convenient to use a file comparitor that put the
two files side by side with the difference highlighted.

Alternately I will use konsole or similar with two console sessions
one with each file and then rapidly flick between them so they overlay
each other and the differences stand out.

>
> Those are my reasons.

But your original comment was quite unlike those.

Richard

2004-09-12, 3:55 pm

LX-i <lxi0007@netscape.net> wrote

> Paragraph-1.
> perform me.
> Paragraph-2.
> perform that.
> stop run.
>
> What is the first paragraph after "PROCEDURE DIVISION"? :)

Perhaps it is a terminolgy problem. The first paragraph is 'perform
me'. The first pargraph _label_ is 'paragraph-1'.

Robert Wagner

2004-09-12, 3:55 pm

On Thu, 9 Sep 2004 16:41:14 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:khd1k0lpf3vrl06mghimnoe9es8p82puh6@
4ax.com...

>One can construct an "array type" using OCCURS, too. As an *advanced*
>student of data base design, *surely* you are aware that the data base
>infrastructure for a *very* widely used data base implementation has OCCURS,
>even OCCURS ... DEPENDING, and has had since the middle 1970's, at least.

Sounds like you're talking about IDMS, formerly owned by Cullinane,
now by CA. The tipoff should be CA. Everything owned by them is a
sinking ship being milked for cashflow .. including our beloved Realia
compiler, now one of the walking fatally wounded.

> "Normalization" is a religious war.

It's the only source of Truth and Enlightenment. Disbelievers are
heritics who must be shunned. What do you mean by "religious war"?
This is about Truth, not religion.

> "Unnormalized" databases have
>existed since long before the publication of Dr. Codd's theories *and* IBM's
>apparent endorsement of them in about 1978; such databases have been
>supplying the needs of happy customers for thirty years now.

I've heard the phrase 'fat, dumb and happy'. Are they fat too?

>COBOL-style tables exist in databases that allow them, whether the database
>definition calls them "an ordered collection of items, all of which have
>identical attributes, existing in a group item" or "a table".

Not in any ANSI SQL-compliant database.

>Mind you, you can restrict your data base design to avoid tables utterly, to
>make every like-format record -- or even every *field* in the data base --
>exist without any physical relationship to any other field in the data base,
>with all associations being through keys and collections of keys uniquely
>identifying each instantiation of every field, if you want to.

Why stop at fields? Every string is a collection of bytes and every
byte is a collection of bits. We could build a database containing
only two data points -- 1 and 0 -- and form everything else as
collection classes of those data. Ridiculus, you say? That's exactly
what the computer industry has been doing for 50 years.

>But whether *you* want to design a data base that way or not is completely
>orthogonal to whether *any* data base implementation either precludes or
>enforces that, or any other data base design philosophy; to whether the end
>user might find the data base useful as designed and implemented; and to
>whether Dr. Codd would have approved of the data base design.

Users speak through their wallets. Last time I looked at the tote
board, the crowd favorites were Oracle, DB2 and SQL Server. IDMS was
clearly an also-ran. Sorry they didn't like IDMS, but rejection is a
fact of life.

Howard Brazee

2004-09-12, 3:55 pm

On 7-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:

> There was once a Datamation report (in the late 70s I think) that
> compared 'maintenance' effort versus 'new development' effort. This
> found that at Cobol shops some high percentage of programmer time was
> 'maintenance' while at C shops it was low.
>
> They concluded that if the Cobol programs were converted to C then the
> maintenance requirement would be much lower and thus more new
> development could be done.

I always get a good chuckle when reminded of this conclusion.

> I suspect that some management may have believed this clueless hack.

I know that LOTS of management have come to the same conclusion - although
mostly not thought out. New code is sexy, maintenance is someone else's
problem.

Robert Wagner

2004-09-12, 3:55 pm

On Sun, 12 Sep 2004 10:15:49 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:

>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:6rd8k0l8ejudlnug25mppml9qu3qod2rfq@
4ax.com...
>function
>
>Consider, *preparing* (the act of a person who prepares)
>Wagner's Vegetarian Medley cannot exist independently of
>Wagner writing the recipe. Wagner is not necessary to
>*prepare* the dish according to the recipe.

The definition you gave is either the gerundial or intransitive form
of prepare. An intransitive has no direct object, therefore could not
take the command is its object. Example: "He is preparing for a
carreer." By citing the gerundial form, you supported my argument.

>Also, invoke has a sense of 'do the following'. Thus "Do the
>following, 'Baking a cake'", makes no sense; but "Do the
>following, 'Bake a cake'", does make sense. I have not yet
>found a sense of invoke the includes 'start'.

"Do the following" is a complete sentence in which following is an
adjective and the word action has been elided. Its full form is "Do
the following action:", where action is the object of do. "Bake a
cake" is also a complete sentence. The rules of punctuation call for a
colon between the two sentences because "Bake a cake" expands the word
action. If a list of sentences followed, that would be an enumeration:
"Do the following: Bake a cake, Decorate it, Serve it to the guests."

The word invoke is not a sentence, it's a verb. If it were a sentence,
it would have punctuation after it, for example:

Invoke this: Bake a cake.
Hark! The herald angels sing.

>
>As I show above, the entire command is the object of invoke,
>not just the method name. Computer languages are not natural
>languages. But, if one defines 'this command' as the text
>following 'invoke', then 'invoke this command' gives the
>verb-noun combination you're trying to achieve. And, this is
>why 'invoke' is not necessary to the understanding.

A sentence cannot be the object of a verb, but a gerund (ending with
-ing) can be.

Read a record.
Carry out reading a record.
Perform reading a record.

>
>Mr Wagner, better? Or just different?

Grammatically correct is better.

> INVOKE is required
>for syntax. It is not required for understanding. Treating
>INVOKE as more than it is invites confusion.

The word invoke is NOT required for syntax. The standard says we can
use Inline Invocation instead.

Robert Wagner

2004-09-12, 3:55 pm

On 5 Sep 2004 19:36:06 -0700, riplin@Azonic.co.nz (Richard) wrote:

>I used Decision Table Preprocessors in the 70s and these certainly
>made it easy to do very complicated decision blocks. The preprocessor
>created dozens of small paragraphs because there were no scope
>terminators, but noone ever needed to look at that.

No, very complicated decision blocks were their downfall. They worked
well on small decision blocks (1-5 columns) and passibly on
medium-sized (6-10). The problem is table size. Assuming decisions are
binary T/F, the number of columns for c conditions is (c^2)*2. For
c=5, there are 50 columns; for c-10, there are 200; beyond that the
table becomes impractical to represent

I worked with this problem quite a bit in the course of writing much
of ACM's DETAB/65. Wim Boerdam, credited for implementation in the
below reference, was my boss at the time. He handled politics and
lanaguage spec; I handled coding.

Wim started with a high-school education (if that) and taught himself
enough chemistry to become chief chemist at one of the largest US oil
refineries. He made a career change to computers around 1960. In
1964, we were trying to use DETAB/65 to optimize the refinery, which
involved way more than ten conditions. After we finished DETAB, Wim
admitted it was the wrong tool for the job. Our next adventure was
linear programming (Danzig 63 Simplex), which was much more
successful. That's another story.

Meanwhile, RAND and Codasyl went their own way with DETAB-X, which I
know nothing about.

http://hopl.murdoch.edu.au/showlang...nguage=DETAB/65

Richard

2004-09-12, 3:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> I care about the logical view, not physical details. They could store
> the inserted record on paper tape for all I care. So long as it comes
> up in the right place when I say NEXT, I'm happy.

Well you _can_ insert a record into a table, you just need to move all
the data at that point up one. That is just an irrelevant physical
implementation detail, the logical result is that the record was
inserted.

> Imagine that, a linked list. Since we've lost the ability to find
> entries with SEARCH ALL, let's build an index over it. Let's call it a
> tree.

One can do that, and it doesn't require non-standard address fiddling.
Or just sort and search all.

> There is an alternative -- one used by nearly every spelling checker.
> Leave the original intact and put recent additions in an unordered
> set. You look in the main list first. If not found there, you do a
> serial search through the supplement. When the supplement becomes too
> big, you 'reorganize' it into the main list.

More complexification yet again.

>
> You said "Tables can be directly accessed by a calculated index
> number." What about two entries that calculate the same index number?

Yes, I did say that. In fact that is what SEARCH ALL does. Now hash
tables are useful too, and these can work by calculating an index. As
you say there may be collisions which are dealt with using an overflow
technique (such as adding 1 until an empty slot is found). Hash
tables work quite well when densities are low and a good collision
system is done (the one above may not be good).

You can't do good hash tables with lists.

One can also calculate into a table when it is known that each item is
going to a unique position, which may emulate a multi-dimension table.
For example if I have a range of warehouses of different
configurations but some actual maximum number of slots then, for a
particular warehouse by knowing the max height and number of rows I
can assign a single dimension table entry uniquely by calculating
using the characteristics.

It seems you are rather short of ideas about how these calculations
can be used.

> My low-level fiddling is the code that belongs inside a *competent*
> collection class method.

Hmm, does this mean that it was inside an *incompetent* class, or that
it wasn't inside a class at all ?

> I measured and posted here the speed of
> methods developed under other philosophies. Their performance was
> terrible -- 50 times slower than the worst of the legacy solutions.

Having to deal with generics and collections does mean that there is
some unavoidable overhead, yes.

When you have come back with your attempt a collection class that can
deal with generic classes as competently (in terms of actually
working) as MicrFocus's then perhaps a comparison can be made.

In the meantime your code was just 'what C did in the 70s'.

> I didn't make this stuff up nor bias the outcome. I measured the speed
> of code distributed by a mainstream company.

Fine, compare like with like and come back.

>
> What do you think lies in the heart of databases? It's bit-fiddling
> that isn't embarrassed by the appellation.

Just as you said above, I really don't care what it does, something
about papertape, I just throw data at it and get it back (or SORT and
SEARCH ALL). I don't want some non-standard pointer code as you
advocated.

>
> I think there are more aspiring tool makers than you do.

The question was ... _visit_here_.

If you want to argue the toss about tree rotation there are groups
that are especially for that where tool builders will visit.

>
> I sorted by rotating the tree until all left-pointers were null. I
> don't recall whether I physically rearranged them with MOVE or XOR.

It still seem that you have lost the advantage of having no limits by
using a table and also have complexified by mixing table handling and
pointers.

Richard

2004-09-12, 3:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

>
> That would be sweet. I've heard it's written in Cobol. What would be a
> selling point .. 2002 .. dot-NET? Is it realistic to expect either
> from Open Source workers?

But Robert, if they open source it then you can work on it and make it
do exactly what you want, even add classes in the way you would
prefer. You could show J4 how it should be done.

Michael Wojcik

2004-09-12, 8:55 pm

In article <b7djj0dcl5pb7prmim2ditf36eiplr8ftq@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
>
> Whoops. I should have said EXIT EVALUATE. There's no such thing. I
> made it up to compare with C, which requires an explicit exit
> 'break'. If you leave it out, the case statement continues running.
> Missing 'break' is a common form of bug.
>
> Some defend that, saying you might want it to continue if the program
> is a 'state machine'.

State machines have nothing whatsoever to do with it.

Default fallthrough was a deliberate design decision by Dennis
Ritchie, but it was made primarily to simplify implementing something
that clearly is a feature: multiple cases with a common body, as in

case 1:
case 2:
action();
break;

Some subsequent C-like languages that have removed default fall-
through (C#, for example) treat empty case bodies specially, so only
they fall through; that permits multiple case syntax while removing
the problem of accidental fallthrough. (C# overloads the goto
keyword for explicit fallthrough - unnecessary, since a normal C goto
with a normal label would also work, but a bit of syntactic sugar to
pacify fallthrough fans.)

That is clearly an improvement in language safety, but it complicates
implementation. It also arguably muddies the language design, though
since case is already a distinct C construct (basically a block-scoped
goto) another idiosyncracy hardly seems to matter.

--
Michael Wojcik michael.wojcik@microfocus.com

Today's Carnivore bait: Distracted by the Anthrax song, I let my bin,
laden with goods, crash into a bush.

Peter Lacey

2004-09-12, 8:55 pm

On 3-Sep-2004, riplin@Azonic.co.nz (Richard) wrote:[color=darkred]
>

I've got news for you. Programmers back then didn't have any problems
writing code.

In any language, at any time, programmers become familiar with the
language as it is and write within its limits. Problems that they may
have, then or now, are caused by faulty planning or misuse of language
features (such as a subscript with a value of zero).

Richard surely didn't mean they would have had NO problems - just one
particular kind. In any case, he's wrong.

PL

Howard Brazee

2004-09-12, 8:55 pm

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

>
> If you had the right tools, it might. As I remember the history, Burroughs'
> first effort at RPG (on the B2500/B3500?) was the COFIRS translator which
> transformed RPG source files into COBOL. Burroughs' next big effort in this
> language was RPG for the B1000, which produced the same object code as the
> original COBOL compiler on that system (remember, each language had its own
> instruction set on that system), and was pretty much based on a combination
> of COFIRS and COBOL. An instruction set specifically for RPG came quite a
> bit later; I don't know how much they had to change the compiler, though.

If you have the right tools, I suppose you're right. I'm awfully glad we
didn't have the right tools.

(I am *not* a fan of such conversions).

James J. Gavan

2004-09-12, 8:55 pm

Robert Wagner wrote:

>No, very complicated decision blocks were their downfall. They worked
>well on small decision blocks (1-5 columns) and passibly on
>medium-sized (6-10). The problem is table size. Assuming decisions are
>binary T/F, the number of columns for c conditions is (c^2)*2. For
>c=5, there are 50 columns; for c-10, there are 200; beyond that the
>table becomes impractical to represent
>
>
>
Interesting you made that point Robert. That's how I feel - and my
original use was as a systems analyst, not as a programmer. At best
three levels in a condition table, otherwise having established the
rules beyond three, even with all the Y's and N's configured, beyond the
three, frankly it becomes a blur for the average human mind - plus of
course you drop off the right-hand side of the paper !.

They most certainly can be effective. I wrote one spec for stock
transfers in a Department store group, which other than specifying the
input key-punched form and the resulting print-outs, was solely a set of
decision tables - but not ENORMOUS ones - but broken down into discrete
units. The programmer loved it, although at the time I don't know how he
coded it, because at that point I wasn't into COBOL.

The application worked like a dream, with some very minor tweaks - which
were not disastrous - the lacking information was because the bean
counters had failed to advise me of some unique features.

Jimmy, Calgary AB

Robert Wagner

2004-09-12, 8:55 p