Home > Archive > Cobol > February 2005 > If you were inventing CoBOL...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
If you were inventing CoBOL...
|
|
| Robert Wagner 2004-09-15, 3:55 pm |
| Correction, I meant to say:
If you avoid DIVIDE .. BY, the four arithmetic verbs store their
result into the rightmost word.
| |
| James J. Gavan 2004-09-15, 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.
>
>
| |
| Robert Wagner 2004-09-15, 3:55 pm |
| On Wed, 15 Sep 2004 02:50:55 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
> I don't think that there is any doubt that many
>"COBOL words" have different semantic meanings than in "normal English" - just
>think of "move" which (by normal English semantics) should have been the "COPY"
>statement (as it doesn't "destroy" the original or "remove" it from its original
>place).
The first program I wrote depended on the sending field being cleared.
It was in assembly language, but could as well have been Cobol. After
learning that Move is really Copy, I wondered why computer people
don't speak English.
The answer came to me years later. Move sounds like it's doing useful
work whereas Copy sounds like unproductive overhead. Why copy data
somewhere else; why not use the original? Indeed, I've found poorly
written programs do a lot more unnecessary Moves than well written
ones.
| |
| docdwarf@panix.com 2004-09-15, 3:55 pm |
| In article <joe_zitzelberger-921801.09193115092004@knology.usenetserver.com>,
Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:
[snip]
>I suspect I've gone on far to long about your misunderstanding of my use
>of the word 'understand'.
Me, personally, I try to avoid using words like 'understanding'... they
get downright knotty ('What are the phenomena which must be demonstrated
in order to apply to a situation the evaluation of 'Now it is
understood'?') and rather than try to fulminate, fume and Hume my way into
a Critique of such things I'll lazily fall back into Wittgenstein's
example of 'perfect language':
Two men are working together, building a wall.
One holds out his hand and says 'Brick'.
The other places a brick into the hand.
DD
| |
| Howard Brazee 2004-09-15, 3:55 pm |
|
On 14-Sep-2004, Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:
> Get over it -- Cobol is an ARTIFICAL language. It does not follow the
> rules of English. Not only doesn't it, it should not follow the rules
> of English. Speaking English is no qualification (some would say an
> anti-qualification) toward being able to THINK logically.
Heck, English doesn't follow "the rules of English".
| |
| Robert Wagner 2004-09-15, 3:55 pm |
| On Wed, 15 Sep 2004 02:59:53 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:
>Given 'Open input in-file', substitute the elements giving
>'verb noun noun'. The object of the verb 'Open' is the noun
>'in-file', which follows the noun 'input' which modifies the
>relation between the verb and its object, in other words, the
>object of the verb follows the object of a preposition. These
>are discrepancies with English syntax because the noun
>following a verb should be its object and what should be a
>prepositional phrase does not contain a preposition.
No, Input is an adjecive in this case. The Input (noun) is the data
residing in, and/or about to be written to, the file.
>In fact, the 'Open' example is exactly the same 'verb noun noun'
>relationship as 'Invoke Cake "Bake"' which also violates English
>syntax for the same reasons.
It violates English because it has 'verb noun verb'. Putting quotes
around Bake doesn't change it from verb to noun.
>Mr Wagner wrote:
>"I can't think of a case where Cobol's procedure division
>syntax violates English syntax. Can you? The rule-breaker
>is INVOKE (or CALL) taking as its object a method name
>written as a non-gerundial verb."
>
>Mr Wagner states that 'a method name written as a
>non-gerundial verb' is a 'rule-breaker' ('violates English syntax').
>In fact, Mr Wagner's complaint is unrelated to English syntax;
>because, as I said four days ago, 'The name of a method is
>a noun.' This statement is true even when the name is selected
>from a list of 'non-gerundial verb[s]'.
>
>Mr Wagner is not incapable of using verbs as nouns. The text
>'INVOKE (or CALL)' uses both INVOKE and CALL as
>nouns. It is still a mystery why he would insist that using verbs
>as nouns in a COBOL program is, somehow, ungrammatical.
The words Method, Action and Verb are defined as nouns. However words
classified as one of the three, such as Invoke, Call and a method
name, are defined as verbs and are properly used in the grammatical
center of a predicate to describe an action performed upon an object.
If you want to perform an action on an action, you have to turn it
into an infinitive (by putting To in front) or a gerund (by putting
-ing at the end). In cases such as 'an archaeological find' an
instance of a action's output can be used as a noun. However, it
doesn't make much sense to talk about the end result before knowing
what it will be.
| |
| Donald Tees 2004-09-15, 3:55 pm |
| docdwarf@panix.com wrote:
> In article <joe_zitzelberger-921801.09193115092004@knology.usenetserver.com>,
> Joe Zitzelberger <joe_zitzelberger@nospam.com> wrote:
>
> [snip]
>
>
>
>
> Me, personally, I try to avoid using words like 'understanding'... they
> get downright knotty ('What are the phenomena which must be demonstrated
> in order to apply to a situation the evaluation of 'Now it is
> understood'?') and rather than try to fulminate, fume and Hume my way into
> a Critique of such things I'll lazily fall back into Wittgenstein's
> example of 'perfect language':
>
> Two men are working together, building a wall.
>
> One holds out his hand and says 'Brick'.
>
> The other places a brick into the hand.
>
> DD
>
Pointing and grunting *is* the lowest level that both machine and man
"understand".
Donald.
;< )
| |
| docdwarf@panix.com 2004-09-15, 3:55 pm |
| In article <pcY1d.14445$0h7.1114235@news20.bellglobal.com>,
Donald Tees <donald_tees@sympatico.ca> wrote:
>docdwarf@panix.com wrote:
>
>Pointing and grunting *is* the lowest level that both machine and man
>"understand".
Hmmmmm... and what are the criteria used for evaluation which rated this
beneath, say, whacking roundly with a stout shilleleagh?
DD
| |
| Robert Wagner 2004-09-15, 3:55 pm |
| On 15 Sep 2004 09:49:11 -0400, docdwarf@panix.com wrote:
>.. I'll lazily fall back into Wittgenstein's
>example of 'perfect language':
>
>Two men are working together, building a wall.
>
>One holds out his hand and says 'Brick'.
>
>The other places a brick into the hand.
Wittgenstein would love GUIs, which have reduced us to the literacy of
a one-year-old who can only point at what he wants and click a mouse.
| |
| Michael Wojcik 2004-09-15, 3:55 pm |
|
In article <joegk05mipj3jee12evgs016daukv6u7hm@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
> On Tue, 14 Sep 2004 22:32:25 -0400, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
>
> No, B is the object of by.
Specifically, "B" is the object of the preposition "by", forming the
prepositional phrase "by B", which acts as an adverb modifying the
predicate "multiply A". "A" is the direct object of the verb
"multiply".
> It's correct English because By can
> occasionally introduce the object being affected.
It's "correct English" (that is, standard usage) because prepositional
phrases are often adverbial. I'm not sure exactly what you mean by
"the object being affected", but "B" is the object of one thing only,
and that is the preposition "by", and a preposition does not name an
effect.
> Consider: He came by airplane,
"by airplane", again, is an adverbial prepositional phrase. The verb
"came" here has no object (as we'd expect, since it's intransitive).
> He did right by his children.
Here "right" is the direct object and "by his children" is still an
adverbial prepositional phrase. (Well, arguably it's an adjectival
prepositional phrase, modifying "right" - ie, describing the scope of
"rightness" - because English is, after all, ambiguous. But it
definitely is not an object of the verb "did".)
> But Cobol is internally
> inconsistent. DIVIDE A BY B stores the result into A whereas MULTIPLY
> A BY B stores the result into B. That IS an error.
Is DIVIDE ... BY even allowed without a GIVING phrase? The MF docs
seem to say that it isn't.
I agree that I'd expect MULTIPLY ... BY to store the result in the
first identifier, though. If I say, in English, "now multiply your
result by 5", I expect the listener to consider the quantity named by
"result" to now be the product.
--
Michael Wojcik michael.wojcik@microfocus.com
Americans have five di vantages which you should take into account
before giving us too hard a time:
- We're landlocked
- We're monolingual
- We have poor math and geography skills -- Lucas MacBride
| |
| Howard Brazee 2004-09-15, 3:55 pm |
|
On 15-Sep-2004, mwojcik@newsguy.com (Michael Wojcik) wrote:
[color=darkred]
>
> "by airplane", again, is an adverbial prepositional phrase. The verb
> "came" here has no object (as we'd expect, since it's intransitive).
>
Or he stood right by his children.
We have some overloaded operators here.
| |
| docdwarf@panix.com 2004-09-15, 3:55 pm |
| In article <37ngk0tda284bm7asa956v15rh99v57lrv@4ax.com>,
Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>On 15 Sep 2004 09:49:11 -0400, docdwarf@panix.com wrote:
>
>
>Wittgenstein would love GUIs, which have reduced us to the literacy of
>a one-year-old who can only point at what he wants and click a mouse.
Mr Wagner, the example given above - with its accomplishment of a task and
the understanding of what the task requires for successful completion -
might appear to contradict that assertion.
DD
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
| I can think of lots of cases in which it is possible for procedure division
code to violate English syntax rules. One that comes to mind is that COBOL
grammar does not require agreement in number between the literals and the
keywords that introduce them: VALUE and VALUES are both permissible in an
88-level item regardless of how many literals there are.
E, VALUES IS and VALUE ARE are all permissible
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:icmek0dhec01s1pjkbbg26o6pk6p7ahmdh@
4ax.com...
> Yes, they do. (For simplicity, I omitted + Punctuation.) I can't think
> of a case where Cobol's procedure division syntax violates English
> syntax. Can you?
Sure I can. Scope terminators!
I also think the "direct" and "indirect" objects (for want of a better
"offhand" term) in "MULTIPLY A BY B ROUNDED ..." are in direct conflict with
English syntax.
And if the VALUE clause in the data division is to mimic English syntax, the
fact that there is no requirement in COBOL that the number of literals used
in the list agree with the introductory keyword in number.
> The rule-breaker is INVOKE (or CALL) taking as its
> object a method name written as a non-gerundial verb. Defenders of
> INVOKE can say 'The standard didn't tell you how to name a method.
> Don't blame Cobol because YOU chose the ungrammatical word.' ...
It appears to me that the purpose of making COBOL "simple English or
pseudo-English" was to make it, insofar as possible, self-documenting.
Whether the syntax violates the rules of *English grammar* is irrelevant so
long as the grammar to which the syntax belongs is unambiguously defined.
That leads to my opinion that the appropriate response to the complaint "But
INVOKE violates the rules of English grammar!" is thus "feh."
-Chuck Stevens
| |
|
| James J. Gavan wrote:
> LX-i wrote:
>
>
> 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.
:)
(I guess I wasn't clear enough with my first point about only one
paragraph... At least two really bright folks read something I didn't
intend to write. Funny thing, this "language" stuff... :> )
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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 ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:ocpek0pi167k6v6b8eus0cvs439ltjki30@
4ax.com...
> Poland may be the only country where people don't know how to spell
> their own names. My step-father, his two brothers and their sister
> used four different spellings of their common surname.
Poland may be one of a number of places -- regardless of political
boundaries -- in which there may be a number of equally-legitimate ways to
spell your name, even presuming there is only one way to pronouce it! I
can think of at least one *spoken* language that has two entirely separate
*written* forms using different alphabets.
Some languages have few ambiguities between spelling and pronunciation, some
have many, some have rigorous standards for spelling, some don't give a darn
so long as the phonetics represented by the spelling come close enough to
the phonemics. I don't think this is a *fault* of the country of Poland,
merely a difference in emphasis and priority.
-Chuck Stevens
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
|
<docdwarf@panix.com> wrote in message news:ci9h8n$pl4$1@panix5.panix.com...
> Me, personally, I try to avoid using words like 'understanding'... they
> get downright knotty ('What are the phenomena which must be demonstrated
> in order to apply to a situation the evaluation of 'Now it is
> understood'?') and rather than try to fulminate, fume and Hume my way into
> a Critique of such things I'll lazily fall back into Wittgenstein's
> example of 'perfect language':
>
> Two men are working together, building a wall.
>
> One holds out his hand and says 'Brick'.
>
> The other places a brick into the hand.
>
> DD
>
I remember vaguely a sequence from "Beyond the Fringe" involving a visit to
Bertrand Russell. It ran something like this, where the visitor is speaking
in first person:
I entered the room and noticed a basket in Mr. Russell's lap, and after we
were introduced I commented "Tell me. Are there any apples in that basket?"
Mr. Russell said "No." After a short pause, I then queried "Are there some
apples in that basket?" Mr. Russell said "No," and smiled seraphically as
was his wont. That left me in a logical cleft stick from which there seemed
but one escape: "Are there, then, apples in that basket?" Mr. Russell
exclaimed "YES!", and from that day forward we remained the very closest of
friends.
-Chuck Stevens
| |
| Richard 2004-09-15, 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'.
| |
| Richard 2004-09-15, 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.
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:3jjgk0pbc6t3vlddptis35vmogaec33rbk@
4ax.com...
> No, Input is an adjecive in this case. The Input (noun) is the data
> residing in, and/or about to be written to, the file.
The only adjectives defined and mentioned as such in the COBOL standard are
ALL, LEADING and FIRST in the context of the INSPECT statement. INPUT is
not in that list. (I find no instance of "adjecive" in the standard).
Technically speaking, according to the grammar of COBOL, INPUT is a *key
word* that introduces the *input phrase* specifying a particular function.
If I were to assign *English* semantics to it, I would argue that it
functions *adverbially*. I'm not sure what I would argue if I were
applying Swahili or Tagalog or APL semantics to it, though.
-Chuck Stevens
| |
| Robert Wagner 2004-09-15, 3:55 pm |
| On Wed, 15 Sep 2004 08:10:30 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:
>Interestingly, when presented as an instruction to a person,
>the result may be left on a calculator or written to the right of
>the statement or on a scratch pad. To say that the result goes
>into A, is to apply behavior not indicated.
>
>Since the COBOL statements for DIVIDE BY always
>include GIVING, that ambiguity is eliminated.
GIVING wasn't required in the Good Old Days. '68 and '74 manuals are
online at:
http://www.36bit.org/dec/manual/
Unfortunately the site is very slow, PDFs are not searchable and the
'74 manual is missing pages, including the one with DIVIDE syntax.
The '68 manual clearly shows GIVING was not required on DIVIDE BY. The
'74 seems to say the same, but without a syntax diagram I can't tell
with certainty.
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:joegk05mipj3jee12evgs016daukv6u7hm@
4ax.com...
>
> No, B is the object of by. It's correct English because By can
> occasionally introduce the object being affected.
It's correct English, but not for the reason you state.
> Consider: He came by airplane, He did right by his children.
In these cases I strongly believe that "to come by" and "to do right by"
function grammatically as *verbs* in English. That "by" is a separate --
and even separable -- word is simply another reflection of the rules of
English. The verb *in COBOL* is MULTIPLY, not MULTIPLY BY with a "separable
suffix".
> But Cobol is internally
> inconsistent. DIVIDE A BY B stores the result into A whereas MULTIPLY
> A BY B stores the result into B. That IS an error.
No, DIVIDE A BY B is a syntax error, according to the standards. There are
five DIVIDE formats: into, into-giving, by-giving, into-remainder, and
by-remainder. In both the by-giving and by-remainder cases, GIVING is
required. There may be vendors that support it, but I think it'd be a bad
idea for the very reason you suggest. It would be DIVIDE A BY B that would
be inconsistent with COBOL statement formation rules, not MULTIPLY A BY B.
> Memory aid: if you avoid MULTIPLY ..BY, the four arithmetic verbs
> store the result into the rightmost word.
So does MULTIPLY ... BY. What are your grounds for avoiding it again?
-Chuck Stevens
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:1gggk0d8jqa2gn9gn7nt8abinc71kj61ok@
4ax.com...
> Correction, I meant to say:
>
> If you avoid DIVIDE .. BY, the four arithmetic verbs store their
> result into the rightmost word.
No, once again, standard COBOL does not allow DIVIDE ... BY, it allows BY
only in DIVIDE statements of the form DIVIDE ... BY ... GIVING and DIVIDE
.... BY ... GIVING ... REMAINDER. If your implementation allows DIVIDE...BY
without GIVING, that is an extension that indeed violates the basic
precedent followed by the other arithmetic verbs, and I would argue against
both its use and its very existence on those grounds.
-Chuck Stevens
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:k5sgk01dr0sklr5vdmvt5j8srh1pat7alf@
4ax.com...
> GIVING wasn't required in the Good Old Days. '68 and '74 manuals are
> online at:
>
> http://www.36bit.org/dec/manual/
CODASYL COBOL (a COBOL-60 dialect) for the B6500 required GIVING in DIVIDE
BY.
IBM COBOL for DOS/360 (an ANSI-68 implementation) required GIVING in DIVIDE
BY.
Burroughs B6700 COBOL (another ANSI-68 implementation) required GIVING in
DIVIDE BY.
ANSI X3.23-1974 required GIVING in DIVIDE BY.
ANSI X3.23-1974 makes no mention of GIVING in DIVIDE BY as a substantive
change that might affect existing programs.
"I saw an implementation once that allowed ... " is a far cry from "COBOL
allows". Again, there may well have been implementations that allowed
DIVIDE ... BY without GIVING, but if there were, it was *clearly* an
extension to standard COBOL, and for the very reasons you've cited, it was
one that I would have argued against had I had the opportunity. The
benefits provided by this extension pale in comparison to the pitfalls.
-Chuck Stevens
| |
| Joe Zitzelberger 2004-09-15, 3:55 pm |
| In article <NI40d.47509$5s3.32560@fe40.usenetserver.com>,
LX-i <lxi0007@netscape.net> wrote:
> Howard Brazee wrote:
>
> Well, program flow has to start _somewhere_ - are you saying don't have
> an initial paragraph?
Why not allow program flow to begin with the first statement after the
procedure division....
| |
| Rick Smith 2004-09-15, 3:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:3jjgk0pbc6t3vlddptis35vmogaec33rbk@
4ax.com...
> On Wed, 15 Sep 2004 02:59:53 -0400, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
>
> No, Input is an adjecive in this case. The Input (noun) is the data
> residing in, and/or about to be written to, the file.
FDIS, page 484, 14.8.26.3 General rules (OPEN statement)
"2) The successful execution of an OPEN statement associates
the file connector referenced by file-name-1 with a physical file
if the physical file is available, and sets the open mode of the file
connector to input, output, I-O, or extend, depending on the
keywords INPUT, OUTPUT, I-O or EXTEND specified in the
OPEN statement. The open mode determines the input-output
statements that are allowed to reference the file connector as
shown in table 21, Permissible I-O statements by access mode
and open mode."
Furthermore, 14.8.26.2 Syntax rules, on the same page, use
the word 'phrase' in association with the keywords shown
above.
[for: with the object or purpose of. -- RHCD]
The object of OPEN is ('the file connector referenced by') the
file-name. The INPUT phrase is 'with the purpose of' setting the
open mode. Thus 'Open input in-file' is syntacically equivalent
to 'Open in-file for input'. The last is 'verb noun preposition noun';
but was mapped from 'verb noun noun'. The OPEN statement
is inconsistent with English syntax.
>
> It violates English because it has 'verb noun verb'. Putting quotes
> around Bake doesn't change it from verb to noun.
Bake, as an identifier, is also a noun.
[snip]
> The words Method, Action and Verb are defined as nouns. However words
> classified as one of the three, such as Invoke, Call and a method
> name, are defined as verbs and are properly used in the grammatical
> center of a predicate to describe an action performed upon an object.
I have not seen anything in the FDIS defining method names
as verbs. Perhaps, Mr Wagner, you could direct me to your
source.
FDIS, page 652, 16.1.1 New method
"The New method is a factory method that provides a standard
mechanism for creating instance objects of a class."
Mr Wagner, the word 'new' is an adjective. Are you suggesting
that, in 'Invoke CakeClass "new" ...', 'new' is a verb; because
'method name [is] defined as [a] verb'?
And, if you are free to call 'new' a verb, why am I not free to
call it a noun?
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:q6qek09c2sg4rq6hs58kttflth8m4637am@
4ax.com...
> On Tue, 14 Sep 2004 07:49:49 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
sign[color=darkred]
do![color=darkred]
>
> The standard says the sign should be stripped and then restored. For
> example:
Ummm ... yes ... figured that out a while back ...
> Who dreams up these labyrinthine rules?
Usually somebody on J4 in response to a query noting that the standard
didn't preclude the syntax but it wasn't clear what it meant.
> Common sense says it should
> not be allowed, which is why I thought it was (not).
Common sense doesn't apply if nobody happened to ask the question before the
specification for INSPECT was completed in '74 ...
> Conversely, if
> allowed for usage display with implicit type conversion to unsigned
> string, it should be allowed for all numerics.
ummm .... no ...
-Chuck Stevens
| |
| Robert Wagner 2004-09-15, 3:55 pm |
| On 9 Sep 2004 21:07:54 -0700, riplin@Azonic.co.nz (Richard) wrote:
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
>Nor can one in a file such as a data file as used by CISAM, the well
>known Informix underlying file system.
The underlying file system is irrelevant. In database view, one can
not only insert a row in the middle, it can even have a duplicate key.
Try creating duplicate subscripts in a Cobol table.
>
>While you are writing the code and debugging the rotations, I'll just
>do a SORT with an output procedure.
We can sort a file and we can sort a table (2002 & MF). Why can't we
say SORT .. GIVING tablename?
>
>Please do supply a library for this. When there is one that works and
>is generally available and generic then I may be bothered to compare
>it to the handful of code required to do this task adequately for the
>last few decades.
Most compilers already do. It's generically called a collection class,
specifically a dictionary. J4 appears to be standardizing the class.
>such
>
>Only 'nearly'.
I wish we could invoke a method the way we call an intrinsic function
-- by saying its name. A method is a verb. When a verb is the object
of another verb it becomes a gerund, which is a substantive (noun),
and should be ended with -ing. For example, 'invoke file read' is
ungrammatical; it should be 'invoke file reading', or better 'invoke
reading of file'. Replace 'invoke' with 'start' to see the error more
clearly.
A possible solution is turning the verb into an infinitive (noun) by
adding the word 'to'. 'He toils to read the file' is equivalent to
'He is reading the file'. But we want to avoid split infinitives,
which have another word between 'to' and the verb. For instance, 'To
boldly go where no man has gone before.' Bad adverb .. bad, BAD.
Infinitives won't work in Cobol because the noun (object) is between
invoke and the verb.
Literate programmers will just have to name their methods in gerundial
form -- opening, reading, finding, etc.
[Gerunds should not be  with present participles, which also
end -ing but function as adjectives.]
> I would have no problem using a collection class, what
>I am criticising is your 'what C did in the 70s approach'.
You object to MY approach? Perhaps I should post under an alter ego.
> If I want an infinite sized
>collection to be searched and ordered I'll throw it at a database
>table or even an ISAM file where it has the advantages of being shared
>and permanent (if required).
Informix temp tables reside in memory and are automagically defined.
They offer the benefit of database logic without the overhead of disk
access, separate definition and security issues. When the job ends,
they disappear in puff of smoke.
>
>You'll have to explain that one, or was it just a meaningless random
>crack.
It was a swipe at simplicity advocates. For example, operations people
who try to do real programming with scripting languages.
>
>Exactly. It works, it is standard, everyone can see how it works at
>2am.
Everyone's not a dumb consumer. Someone has to write those easy-to-use
tools. I was talking to the tool makers and anyone curious about the
subject.
>Even if (and I emphasise if) the tree is faster then CPU time is a
>trivial saving compared to programmer complexity costs.
Like matter and energy, complexity is conserved. It doesn't go away,
it just gets repackaged. When you say "programmer complexity", you are
referring to Application Programmers, not all programmers. An analogy
is PC hardware. In the early '80s, we had to deal with IRQs, port
addresses and DMA channels. The life of a computer consumer was
complicated. Today, those things (or their analogs) are still inside
the computer but they are hidden from your view. They are managed by
software (Plug 'n Play) or hardware (SCSI controller). Complexity
didn't decrease; it moved upstream .. from the user's desk to the
factory. In the same way, software complexity is moving from the
Application Programmer domain to the software factory e.g. database
provider.
>What was cost effective in the 70s is irrelevant today.
Consider airline reservations. In the '70s, the industry handled
speed and volume problems by writing everything in assembly language,
and paid the complexity price. Later, their complex code base was no
longer necessary or relevant, so they rewrote in modern languages,
Unix and MySQL. Complexity hadn't changed, it moved from application
code to MySQL code.
>
>Do you do this by dividing the pointer by 2 ?
By using SEARCH ALL. In the demo, tree nodes lived in a table.
| |
| Michael Wojcik 2004-09-15, 3:55 pm |
|
In article <chq4ih$rss$1@panix5.panix.com>, docdwarf@panix.com writes:
> In article <chpvr102j6d@news1.newsguy.com>,
> Michael Wojcik <mwojcik@newsguy.com> wrote:
>
>
> 'Only a fool blames his tools, but... (skritch scratch skritch)...
> damnation, stupid pen's out of ink.'
Heh. Actually, I think it's quite reasonable to blame tools at
times, because tools can be poor. If you're trying to turn a screw
and the handle of your screwdriver shatters, that's a defective tool
(assuming the screwdriver's only been used in the intended manner).
And, as I suggested above, I do think it's reasonable to claim that
you might be able to do a better job with tools more suited to you
personally, even if the tools available are not in themselves
defective. I find it much easier to write on a whiteboard than on a
chalkboard, for example; that doesn't say anything negative about
the latter. (I suppose whether that's "blaming the tool" or simply
admitting my own deficiency in using it is a matter of semantics.)
In fairness to Robert, I should admit that vi has a large number of
commands; that it is terse and not overly informative (here again
many of the clones improve on classic vi); and that it is almost
certainly unfamiliar (which is what people mean when they say
"unintuitive") to new users. (I don't know of any editors other than
vi and its clones which have a similar interface, so newcomers are
likely to find it strange.) These are barriers to quickly becoming
an expert, and a non-expert is likely to find vi difficult.
--
Michael Wojcik michael.wojcik@microfocus.com
A coding theorist is someone who doesn't think Alice is crazy. -- John Gordon
| |
| Warren Simmons 2004-09-15, 3:55 pm |
| Chuck, I found your comments interesting. Why?
Well, IDS (GE Bachman) was available on the GE 200 systems. A tire
company in Ohio, I think it was Goodyear, but memory fails me. Had
IDS and was very happy. Then, the Corporate controls said, you've
got to install this IBM machine. The person most badly hurt by this
was someone I used to talk to, and I know that he and his group
did IDS for the IBM system to retain the procedural system they were
using. That person eventually became Culligan. And what ever thereafter.
I chaired the DBTG for three years, and was a member for about 7 years.
In the process, we had a GM Lab member who used a similar method on
their 360 where they developed a design system for the engineers for
GM. Bachman and the GM person took the DBTG through the whole basic
logic of their almost identical systems. We, the DBTG, published a paper
on our findings and direction. Both Westinghouse, and Cincome created
packages using the basic methods. The people at Cincom had been IBM
Systems people helping customers install Bill of Material systems, and
decided that since the only thing IBM had at the time was a book
telling people how to do this kind of application. Some of those
IBM people became Cincom. They produced TOTAL. Our company used
IDS on GE 200's at one plant, and TOTAL ELSEWHERE.
While IBM was a member of the DBTG, they were not that helpful as they
kept telling us that this guy had written a book on use of a better
method based on math.
Short story, IBM managed to keep the IDS methods out of the proposed
extensions to COBOL, but Bachmand's system design became the basis
of lots of OTHER approaches. I wish I knew the names of all of them
that use networking of records. Ir's about the only thing I can hold
my head up about. GE, and GM put their methods in the public domain.
Every time I see the term MySQL or anything like it, I begin to burn.
I still believe the Bachman approach is a better way to design a
database, and that and a dime will get me zilch. At least ACM
gave Bachman a $1000 prize.
Warren Simmons
Chuck Stevens wrote:
> "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:2m72k0t8ndm460rk1ttnqk49lrhm3iu1rn@
4ax.com...
>
>
>
>
> It may sound like it, but alas, your encyclopedic knowledge has failed you
> once more.
>
> The software that started life as Burroughs DMSII back in the very early
> 1970's, and implemented and supplied on Burroughs Small, Medium and Large
> Systems -- almost certainly predated IDMS, and in my opinion, throughout its
> life far outstripped it in terms of power, robustness and recoverability. I
> have heard that some databases are *starting* to catch up to DMSII in these
> areas, but that there are a number of areas in which DMSII leaves everybody
> else in the dust. It's now called "Database Server for ClearPath MCP
> Systems", by the way.
>
> Cullinane acquired the rights to IDMS in 1973, and it did become their
> flagship product. Cullinane was bought by Computer Associates in 1989.
>
> When I first joined Burroughs in 1974 I was peripherally involved in
> demonstrations of DMSII/GEMCOS synchronized recovery in which every terminal
> on the system was restored to its last-refreshed state, automatically, after
> what would ordinarily be a catastrophic failure. One of the big strengths
> of DMSII has always been its recoverability and its robustness, and that was
> demonstrable before Cullinane even began marketing IDMS.
>
> So far as I have been able to determine, there is not now nor has there ever
> been any sort of relationship among Burroughs DMSII, Cullinane, Computer
> Associates and IDMS.
>
>
>
>
> Even in an environment in which there is One True Religion, I believe people
> should have the fundamental right to choose whether to adhere to it. In
> the case of DMSII, you have the ability to design a "normalized" data base
> just as you have the ability to declare a data base with the most horrendous
> examples of hierarchical embedding of structures you can imagine (which
> were, at one time, viewed as examples of the heighths of elegance,
> cleverness and economy in data-base design). I saw examples of both, in the
> middle 1970's!
>
>
>
>
> If by "fat" you mean "profitable and successful", yes, I'd say they are. As
> to dumb: Yes, they *could* redesign and reorganize, say, a hierarchical
> data base so that it met the Latest Stylistic Standards, but it's not clear,
> if the database runs just fine the way it is, that there's a *financial*
> reason for them to do so.
>
>
>
> database
>
>
>
>
>
> Ah. Now we come to the qualification.
>
> You want to build a brand-new ANSI SQL-compliant database on your ClearPath
> Plus Libra system? Sure, no problem.
>
> You want to bring your 1975-vintage manufacturing data base with fifteen
> levels of parts explosion implemented using hierarchical nesting of
> structures up without change in the same system? Sure, no problem.
>
> You want both applications to recover every interactive device to the last
> transmission sent to it, without any manual intervention, on any
> catastrophe, including a bomb hit on the main data center (so long as you've
> set up Remote Database Backup, which is done independent of the applications
> accessing the data base)? Sure, no problem.
>
> The infrastructure for *both* databases is that product which began life as
> Burroughs Large Systems DMSII.
>
>
>
>
> Well, I'm sorry they didn't like IDMS, too. That must make CA indeed.
> But I'm not sure what that has to do with the topic at hand!
>
> As to users speaking through their wallets: I would say there exists a
> quantity of contented Unisys customers who state, through their wallets,
> that the "Database Server for ClearPath MCP Systems" (AKA DMSII) is a MAJOR
> reason to choose the MCP environment over any other on the market,
> sometimes for the sole purpose of providing support for an enterprise-wide
> data base!
>
> -Chuck Stevens
>
>
| |
| Richard 2004-09-15, 3:55 pm |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
> The underlying file system is irrelevant.
It was you that started arguing that there was a relevant similarity
between a table and a database table. Now its all hand waving on your
part.
> In database view, one can not only insert a row in the middle,
You cannot insert a record into the middle of a phyical file (without
moving all the data beyond that point), a logical insert puts it at
the end.
If there actually is a requirement to keep a path through records
without a physical insert it is easy enough to have 'next' and 'prior'
subscripts in the table, of course this then defeats the SEARCH ALL.
> it can even have a duplicate key.
> Try creating duplicate subscripts in a Cobol table.
Subscripts are not 'keys' they are equivalent to a record number. Try
having a file with two records with the same number.
> We can sort a file and we can sort a table (2002 & MF). Why can't we
> say SORT .. GIVING tablename?
What's your point ? It is only a handful of lines of code.
> Most compilers already do. It's generically called a collection class,
> specifically a dictionary. J4 appears to be standardizing the class.
If you were promoting the use of collection classes this would be a
different discussion. You weren't, you were promoting hand coding low
level address fiddling as done by C in the 70s.
> Informix temp tables reside in memory and are automagically defined.
> They offer the benefit of database logic without the overhead of disk
> access, separate definition and security issues. When the job ends,
> they disappear in puff of smoke.
Exactly, I don't have to care how it does this, I just throw the data
at it and ask for it back as I want it. This is far more valuble than
how to fiddle non-standard memory addresses. They can read that in
'Computer Science' if they care.
> Everyone's not a dumb consumer. Someone has to write those easy-to-use
> tools. I was talking to the tool makers and anyone curious about the
> subject.
How many 'tool makers' do you think visit clc ? Your code and example
was directly aimed at applications programmers, ie those who visit
here.
>
> By using SEARCH ALL. In the demo, tree nodes lived in a table.
Well bang goes the only advantage of lists and trees, the freedom from
a limit imposed by having a table. Presumably you have to sort the
table so that SEARCH ALL can work.
You seem to have gone full circle and just picked up a huge baggage on
the way.
| |
| Richard 2004-09-15, 3:55 pm |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> But Cobol is internally inconsistent.
> DIVIDE A BY B stores the result into A
It never does that. Without a 'giving' the compiler will flag this as
an error.
There is no inconsistency.
(I may have to repeat this over the next two w s until you test it
and find it is what your compiler does ;-).
> whereas MULTIPLY
> A BY B stores the result into B. That IS an error.
No. It isn't an error at all. It is exactly what is defined for the
Cobol syntax.
> Memory aid: if you avoid MULTIPLY ..BY, the four arithmetic verbs
> store the result into the rightmost word.
Memory aid for Robert: it was DIVIDE .. BY that you wrongly claimed as
the exception.
| |
| Richard 2004-09-15, 3:55 pm |
| docdwarf@panix.com wrote
> Hmmmmm... and what are the criteria used for evaluation which rated this
> beneath, say, whacking roundly with a stout shilleleagh?
But that would be part of the Irish language and thus completely off
topic in an English vs Cobol discussion.
| |
| Chuck Stevens 2004-09-15, 3:55 pm |
| Let's try that again:
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:icmek0dhec01s1pjkbbg26o6pk6p7ahmdh@
4ax.com...
> Yes, they do. (For simplicity, I omitted + Punctuation.) I can't think
> of a case where Cobol's procedure division syntax violates English
> syntax. Can you?
Sure I can. Scope terminators!
I also think the "direct" and "indirect" objects (for want of a better
"offhand" term) in "MULTIPLY A BY B ROUNDED ..." are in direct conflict with
English syntax.
And if the VALUE clause in the data division is to mimic English syntax, the
fact that there is no requirement in COBOL that the number of literals used
in the list agree with the introductory keyword in number.
> The rule-breaker is INVOKE (or CALL) taking as its
> object a method name written as a non-gerundial verb. Defenders of
> INVOKE can say 'The standard didn't tell you how to name a method.
> Don't blame Cobol because YOU chose the ungrammatical word.' ...
It appears to me that the purpose of making COBOL "simple English or
pseudo-English" was to make it, insofar as possible, self-documenting.
Whether the syntax violates the rules of *English grammar* is irrelevant so
long as the grammar to which the syntax belongs is unambiguously defined.
That leads to my opinion that the appropriate response to the complaint "But
INVOKE violates the rules of English grammar!" is thus "feh."
-Chuck Stevens
>
>
| |
| Robert Wagner 2004-09-15, 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.
| |
| William M. Klein 2004-09-15, 3:55 pm |
| *all* current J4 papers can be found off the main J4 web page at:
http://www.cobolportal.com/j4/index.asp?bhcp=1
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:gia2k0duru6vov6etm8d1chb483pfreeb4@
4ax.com...
> On Fri, 10 Sep 2004 01:36:17 GMT, "James J. Gavan" <jjgavan@shaw.ca>
> wrote:
>
>
>
>
> In your enthusiastic reportage, you forgot to mention where these
> important works can be found.
>
| |
| James J. Gavan 2004-09-15, 8:55 pm |
| Richard wrote:
>docdwarf@panix.com wrote
>
>
>
>
>But that would be part of the Irish language and thus completely off
>topic in an English vs Cobol discussion.
>
>
Now why would yers want to ignore shillelagh ? Jutst t'ink of all them
Micks, back in the Auld Sod, them as was unfortunate enough to settle in
Perfide Albion, and them as took off to N. America - and their
contribution to English literature. Would yers be dicounting Anglo words
loike bungalow or verandah. Tis sure down there near the Antartic yers
proably has introduced Maori-isms to the English language.
PS: Never seen a shillelagh - but my maternal grandfather 'sported' a
cracked nose where somebody took a swipe at him in his youth - playing
the horrendous five-a-side hurley on a soccer-sized pitch.
Jimmy
| |
| Rick Smith 2004-09-15, 8:55 pm |
|
"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-921801.09193115092004@knology.usenetserver.com...
> In article <10kfco0g8drct62@corp.supernews.com>,
> "Rick Smith" <ricksmith@mfi.net> wrote:
>
able[color=darkred]
>
> A computer *understands* the commands it was built to understand. It
> does not sit around reflecting on the political and social ramifications
> of those commands, so it certainly does not qualify as philosophical
> understanding. Rather, it understands in the sense of a cat
> understanding the word 'tuna'.
Let's see. Think logically.
Tuna live in the ocean.
Cats are not ocean-going mammals.
Therefore, cats are not natural predators of tuna.
What are the social ramifications of cats eating an unnatural diet
of tuna?
Should cats lobby for greater control of their diet?
[snip]
> I suspect I've gone on far to long about your misunderstanding of my use
> of the word 'understand'.
No, Mr Zitzelberger, you haven't. Indeed, I enjoyed your
discussing Albert. While I do not currently have a pet, your
mentioning Albert helped me to recall images and fond
memories of Fluffy, my family's dog.
[I used 'recall images' for the benefit of Mr Wagner. In an
earlier post, I did not respond to a question he had raised
concerning my complaint about his use of 'Terms ... recall
images'. What I show here is that people have an ability to
'recall images' but terms (or words) have no such ability.
My complaint was based on a logical inconsistency.]
There's that 'think logically', again.
| |
| Richard 2004-09-15, 8:55 pm |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> No, Input is an adjecive in this case.
Completely wrong. Cobol does not have 'adjectives'. 'INPUT' is clearly
a 'phrase' as this is how it is referred to in the specification. It
may casually be taken as being a qualifier to the OPEN.
> The Input (noun) is the data
> residing in, and/or about to be written to, the file.
It is irrelevant whether you read it as:
Open [as/for] input [the file] filename
or Open [the] input [called] filename
because the [] bits are entirely figments of your imagination and have
no significance either way, certainly not to the language, the
compiler, or the effect of running the program. Claiming that one of
these meanderings of your mind is 'superior' is simply mental
masterbation on your part.
> It violates English because ..
It is irrelevant whether it 'violates' or ignores or parodies English
or Serbo-Croatian or even Java.
It is Cobol. It only needs to follow the rules set for Cobol. These
rules may be made with some sympathty towards how that may be
understood by someone who speaks English, but once made they _are_ the
rules and only those rules are relevant.
If you don't like the way that Cobol is made then I would suggest that
you change to some other language. I am sure that comp.lang.perl
would just love to hear your assesment of how it should follow the
rules of something else entirely.
| |
| Chuck Stevens 2004-09-15, 8:55 pm |
|
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:q6qek09c2sg4rq6hs58kttflth8m4637am@
4ax.com...
> The standard says the sign should be stripped and then restored. ...
Actually, that depends on *which* standard you're talking about. True for
ANSI X3.23-1985 (page VI-96, 6.18.4, INSPECT statement, general rule 2c last
sentence) and for ISO/IEC 1989:2002 (page 464, 14.8.21.3, INSPECT statement
general rule 3d), but I don't see similar wording in ANSI X3.23-1974 (page
II-69, 5.144, INSPECT statement, general rule 2c or anywhere else).
Note that the INSPECT statement was introduced in the '74 standard; although
the specification that the sign is retained for a signed item seems to have
been added in the '85 standard I don't see anything in the "substantive
change" list (of either the '85 standard itself or of the corrections
amendment) that indicates it's a difference.
-Chuck Stevens
| |
| Donald Tees 2004-09-15, 8:55 pm |
| docdwarf@panix.com wrote:
> In article <pcY1d.14445$0h7.1114235@news20.bellglobal.com>,
> Donald Tees <donald_tees@sympatico.ca> wrote:
>
>
>
> Hmmmmm... and what are the criteria used for evaluation which rated this
> beneath, say, whacking roundly with a stout shilleleagh?
>
> DD
>
A mouse by any other name would not click near so sweet.
Donald
| |
| Joe Zitzelberger 2004-09-15, 8:55 pm |
| In article <cht3ev04sb@news3.newsguy.com>,
mwojcik@newsguy.com (Michael Wojcik) wrote:
> In fairness to Robert, I should admit that vi has a large number of
> commands; that it is terse and not overly informative (here again
> many of the clones improve on classic vi); and that it is almost
> certainly unfamiliar (which is what people mean when they say
> "unintuitive") to new users. (I don't know of any editors other than
> vi and its clones which have a similar interface, so newcomers are
> likely to find it strange.) These are barriers to quickly becoming
> an expert, and a non-expert is likely to find vi difficult.
Don't sugar coat it.
I'm conversant with vi. I've used vi. I can and often find myself
using vi. It works, it will edit quickly and easily in a terminal
window. I am not scared of vi.
But let us face reality.
vi sucks.
It doesn't just suck in a normal, everyday lame tool way. It really
sucks.
vi sucks so badly that the entire viewership of alt.flame could not put
voice to the expansive sucky-ness of vi. The length and breath of the
sucky-ness that is vi is beyond the bounds of human understanding.
Just in case I haven't made my point. I think vi really sucks.
Sometime, the tool just sucks.
If, for example, you had a screwdriver that required you to key
"<escape><cntl><shift>+" and hold the screwdriver with your left big toe
in order to turn a screw clockwise. (Although a philips head would
require the '+' on the keypad, while a prince-reed would require
"<escape><cntl><meta><F3>".) And if this screwdriver required you to
key "<escape><cntl>\+a", while holding the screwdriver in your elbow, in
order to turn the screw anti-clockwise. Well, you could assume that
that tool would suck as well.
But even if such a screwdriver existed. Even though such a screwdriver
would indeed suck. The sucky-ness of that screwdriver would be dwarfed
by the imense sucky-ness of the editor that is vi.
| |
| Donald Tees 2004-09-15, 8:55 pm |
| Joe Zitzelberger wrote:
> mwojcik@newsguy.com (Michael Wojcik) wrote:
>
>
>
>
> Don't sugar coat it.
>
> I'm conversant with vi. I've used vi. I can and often find myself
> using vi. It works, it will edit quickly and easily in a terminal
> window. I am not scared of vi.
>
> But let us face reality.
>
> vi sucks.
>
> It doesn't just suck in a normal, everyday lame tool way. It really
> sucks.
>
> vi sucks so badly that the entire viewership of alt.flame could not put
> voice to the expansive sucky-ness of vi. The length and breath of the
> sucky-ness that is vi is beyond the bounds of human understanding.
>
> Just in case I haven't made my point. I think vi really sucks.
>
> Sometime, the tool just sucks.
>
> If, for example, you had a screwdriver that required you to key
> "<escape><cntl><shift>+" and hold the screwdriver with your left big toe
> in order to turn a screw clockwise. (Although a philips head would
> require the '+' on the keypad, while a prince-reed would require
> "<escape><cntl><meta><F3>".) And if this screwdriver required you to
> key "<escape><cntl>\+a", while holding the screwdriver in your elbow, in
> order to turn the screw anti-clockwise. Well, you could assume that
> that tool would suck as well.
>
> But even if such a screwdriver existed. Even though such a screwdriver
> would indeed suck. The sucky-ness of that screwdriver would be dwarfed
> by the imense sucky-ness of the editor that is vi.
>
Tell us how you *really* feel.
Donald
;< )
| |
| William M. Klein 2004-09-15, 8:55 pm |
| "Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:2514k09nj41epdgrmsgiejth6lh0kpc8n5@
4ax.com...
> On 9 Sep 2004 21:07:54 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
<snip>
>
> I wish we could invoke a method the way we call an intrinsic function
> -- by saying its name. A method is a verb. When a verb is the object
> of another verb it becomes a gerund, which is a substantive (noun),
> and should be ended with -ing. For example, 'invoke file read' is
> ungrammatical; it should be 'invoke file reading', or better 'invoke
> reading of file'. Replace 'invoke' with 'start' to see the error more
> clearly.
>
Don't you like the "inline invocation" syntax? If not, do you like the Micro
Focus (extension) "vocabulary" feature? (Personally, I don't - but I know some
people do)
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| Donald Tees 2004-09-15, 8:55 pm |
| James J. Gavan wrote:
> Donald Tees wrote:
>
> Correct me if I'm wrong Donald but that isn't an in-line invocation so
> far as I know - or is it ? In-line invocation is dependent upon that
> "double colon". Following from the N/E 4.0 manual - which is very much
> up-to-date :-
> ------------------------------------
>
AH! now I can see why Robert dislikes it. Sorry about the misnomer.
Donald
| |
| Richard 2004-09-15, 8:55 pm |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
> GIVING wasn't required in the Good Old Days. '68 and '74 manuals are
> online at:
> The '68 manual clearly shows GIVING was not required on DIVIDE BY. The
> '74 seems to say the same, but without a syntax diagram I can't tell
> with certainty.
I can assure you that in the '74 standard DIVIDE BY required the
GIVING. I have several references that indicate this clearly. eg MF
CIS Cobol and Level II Cobol.
In "Writing Structured Cobol", David L. Johnson describes ANS'74 and
explains differences from ANS'68. He takes pains to qualify DIVIDE BY
as not permitted without the GIVING and raises no issues that this is
different from ANS'68, yet the book has many marginal notes on
differences.
I can distinctly remember that with earlier versions of Cobol (pre
'68) there was no DIVIDE BY at all, there was only DIVIDE INTO, at
least with the compilers that I used, it was a source of some
discussion. The '68 compiler introduced DIVIDE BY GIVING.
It may be that the TOPS compiler was non-standard in this respect.
| |
| Joe Zitzelberger 2004-09-15, 8:55 pm |
| In article <217e491a.0409151103.42bf4b4a@posting.google.com>,
riplin@Azonic.co.nz (Richard) wrote:
> docdwarf@panix.com wrote
>
>
> But that would be part of the Irish language and thus completely off
> topic in an English vs Cobol discussion.
<bomb-throwing-flamebait>
Gaelic, the original Irish language, has been watered down by centuries
of the British pissing all over it, Ireland and her people.
Considering the current official tongue of Ireland, it might fit if we
drifted into a discussion of English-UK vs Cobol...
</bomb-throwing-flamebait>
Joe O'Zitzelberger
| |
|
| Joe Zitzelberger wrote:
>
> Don't sugar coat it.
>
> I'm conversant with vi. I've used vi. I can and often find myself
> using vi. It works, it will edit quickly and easily in a terminal
> window. I am not scared of vi.
>
> But let us face reality.
>
> vi sucks.
>
> It doesn't just suck in a normal, everyday lame tool way. It really
> sucks.
>
> vi sucks so badly that the entire viewership of alt.flame could not put
> voice to the expansive sucky-ness of vi. The length and breath of the
> sucky-ness that is vi is beyond the bounds of human understanding.
>
> Just in case I haven't made my point. I think vi really sucks.
>
> Sometime, the tool just sucks.
>
> If, for example, you had a screwdriver that required you to key
> "<escape><cntl><shift>+" and hold the screwdriver with your left big toe
> in order to turn a screw clockwise. (Although a philips head would
> require the '+' on the keypad, while a prince-reed would require
> "<escape><cntl><meta><F3>".) And if this screwdriver required you to
> key "<escape><cntl>\+a", while holding the screwdriver in your elbow, in
> order to turn the screw anti-clockwise. Well, you could assume that
> that tool would suck as well.
>
> But even if such a screwdriver existed. Even though such a screwdriver
> would indeed suck. The sucky-ness of that screwdriver would be dwarfed
> by the imense sucky-ness of the editor that is vi.
This one is in my saved mail file now... :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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 ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| docdwarf@panix.com 2004-09-16, 3:55 am |
| In article <LJ22d.15529$0h7.1207424@news20.bellglobal.com>,
Donald Tees <donald_tees@sympatico.ca> wrote:
>docdwarf@panix.com wrote:
>
>A mouse by any other name would not click near so sweet.
Perhaps it is closer to what Gregor Mendel showed, e'en before such
structures were described... 'this above all, to thine own cells be true.'
DD
| |
| Richard 2004-09-16, 3:55 am |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> DIVIDE A BY B stores the result into A
No it does not. You are quite wrong, this is just more of your
misinformation. Looking at the only reference to DIVIDE BY that does
not require the GIVING, that of TOPS-20 Cobol '68 (where it may be an
extension):
Option 2
DIVIDE {identifier-2} BY identifier-1 ....
{literal-2}
It quite clearly states:
"In option 2, the resulting quotient replaces the value of
identifier-1."
| |
| Robert Wagner 2004-09-16, 3:55 am |
| On 15 Sep 2004 12:16:18 -0400, docdwarf@panix.com wrote:
>In article <37ngk0tda284bm7asa956v15rh99v57lrv@4ax.com>,
>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:
>
>Mr Wagner, the example given above - with its accomplishment of a task and
>the understanding of what the task requires for successful completion -
>might appear to contradict that assertion.
[Initial posting to C.L.C.]
I need brick.
[First response]
The word brick doesn't tell us much. To answer your question, we need
to know the operating system, name of the brick factory and batch
number (every batch is different, you know), and the intended usage.
Do you need a structural brick or a veneer brick? Must it be
waterproof? Have you considered concrete block or galvanized sheet
metal.
[Second response]
No matter what your problem, our general-purpose Wonder Brick (tm)
will solve it. If you are building a well, we offer a single-builder
package for $4,000. In addition, we'll need to know the number of
people who'll be drawing water from your well. Given that, we can
structure a run-time package for 1-5, 6-10, 11-25, etc. Cost per user
can be as low as $59 per year, which we think you will find attractive
in comparison to other brick companies.
[Third response, quoting the Wikipedia brick standard]
"Masonry is strong in compression (vertical loads), but is relatively
weak when subject to tension or sideways loads, unless reinforced.
Walls are often strengthened against sideways loads by thickening the
entire wall, or by building masonry piers (vertical columns or ribs)
at intervals.
The strength of a masonry wall is not entirely dependent on the bond
between the building material and the mortar; the friction between the
interlocking blocks of masonry is often strong enough to provide a
great deal of strength on its own. The blocks sometimes have grooves
or other surface features added to enhance this interlocking, and some
masonry structures forego mortar altogether. Stone masonry without the
use of mortar was common in early civilizations."
Have you considered ALL the perils and researched ALL the
alternatives? Have you considered the possibility there may have been
one brick produced since the dawn of civilization that you DON'T need?
I thought not. Call back when you know what you're talking about.
[Follow-up by original poster]
What are you people yammering about? I just need bricks to build the
wall of my well. I have several pallets that some guy sent, but I
can't figure out how to get the bricks off them. They're wrapped in
plastic or something.
[RW]
Just cut the plastic off with a utility knife. The bricks underneath
are probably the common type. No problem.
[Richard]
Once again, you've done the poster a disservice by failing to
stimulate him to investigate. You don't KNOW what kind of bricks are
underneath. Besides, you were wrong about something two years ago, so
you're wrong about this too.
[DocDwarf]
Centuries before Pliny, Aristotle described precisely the phenomenon
of well water rising from and returning to the sea.
[Seventh response]
Six professionals have taken the time to respond, without
acknowledgement. Don't you love us?
[Eighth response]
Damned ingrates.
| |
| Robert Wagner 2004-09-16, 3:55 am |
| On Wed, 15 Sep 2004 13:41:11 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:
>FDIS, page 652, 16.1.1 New method
>"The New method is a factory method that provides a standard
>mechanism for creating instance objects of a class."
>
>Mr Wagner, the word 'new' is an adjective. Are you suggesting
>that, in 'Invoke CakeClass "new" ...', 'new' is a verb; because
>'method name [is] defined as [a] verb'?
Yes. New is a constructor. It 'instantiates' new objects.
>And, if you are free to call 'new' a verb, why am I not free to
>call it a noun?
I didn't choose to make New into a verb. Seems to me Construct would
have been a better choice.
You can call anything whatever you want. That doesn't make it right.
If you gotJ4 to agree, it still wouldn't be right and Cobol would be
diminished. People would say Cobol isn't faithful to its roots.
| |
| James J. Gavan 2004-09-16, 3:55 am |
| Joe Zitzelberger wrote:
>In article <217e491a.0409151103.42bf4b4a@posting.google.com>,
> riplin@Azonic.co.nz (Richard) wrote:
>
>
>
>
><bomb-throwing-flamebait>
>
>Gaelic, the original Irish language, has been watered down by centuries
>of the British pissing all over it, Ireland and her people.
>
>Considering the current official tongue of Ireland, it might fit if we
>drifted into a discussion of English-UK vs Cobol...
>
></bomb-throwing-flamebait>
>
>
>Joe O'Zitzelberger
>
>
>
Next it willl be Abraham O'Goldberg !
| |
|
| Rick Smith wrote:
> "Warren Simmons" <wsimmons5@optonline.net> wrote in message
> news:4145F413.4050303@optonline.net...
>
>
> Let's see, Mr Simmons.
>
> [invent: 1. to originate as a product of one's own device
> or contrivance. 2. to produce or create with the imagination.
> -- RHCD]
>
> The first definition includes the notion of 'contrived'. The
> second seems too general; that is, it lacks the idea that
> COBOL was the result of a plan to create a language
> for a specific purpose (business oriented). Based upon
> my knowledge of its history, I think C is closer to
> invented; while C++ might be seen as contrived (object
> oriented). Also, FORTRAN might be seen as contrived
> (scientific oriented).
This whole argument seems contrived to me... :)
(Yes, I'm anxiously awaiting Ivan's arrival - we're in the "tornado
quadrant". Looks like it should be here in all it's fury sometime in
the morning.)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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 ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| Michael Wojcik wrote:
>
> I agree that I'd expect MULTIPLY ... BY to store the result in the
> first identifier, though. If I say, in English, "now multiply your
> result by 5", I expect the listener to consider the quantity named by
> "result" to now be the product.
You know, this never made sense to me, until someone (I believe it was
in here) said that the reasoning was to make the receiving variable
always on the right, just like it is in a "move" statement. If COBOL
textbooks would include that one little gem (mine didn't), I don't think
we'd have nearly the confusion about the math verbs that we do.
So, given...
ADD a TO b
SUBTRACT a FROM b
MULTIPLY a BY b
DIVIDE a INTO b
, "b" has all our results. (They could even make a pretty chart or
something...)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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 ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
|
| Joe Zitzelberger wrote:
> In article <NI40d.47509$5s3.32560@fe40.usenetserver.com>,
> LX-i <lxi0007@netscape.net> wrote:
>
>
>
> Why not allow program flow to begin with the first statement after the
> procedure division....
That would be fine - then you'd have no "fall-through" paragraphs. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ 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 ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
| |
| Richard 2004-09-16, 3:55 am |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>
> Yes. New is a constructor. It 'instantiates' new objects.
In English the word 'new' is indeed an adjective, exactly as you have
used it above. Its use in OO is idiomatic sa in:
myClass myObject = new myClass(parameters);
in which it may be cosidered as an adjective. You should note that in
the OO idiom 'new' is _not_ the contructor, myClass(..) is.
Looking at Fujitsu, in order to fit the OO idiom into Cobol it uses
'new' as a method-id that is invoked as if it were the above form.
'New' is _not_ the constructor, 'create' is. From the docs:
"An object is created as the result of the CREATE method invoked by a
factory object. The CREATE method is invoked by the NEW method of the
FJBASE class."
While 'new' is used to return the new object reference, the contructor
is 'create'.
>
> I didn't choose to make New into a verb. Seems to me Construct would
> have been a better choice.
'New' isn't a verb, it is (in Cobol) the name of a method.
> You can call anything whatever you want. That doesn't make it right.
It doesn't make you right either.
> If you gotJ4 to agree, it still wouldn't be right and Cobol would be
> diminished. People would say Cobol isn't faithful to its roots.
J4 have to navigate a path between 'Cobol roots' and 'OO idiom' for
these OO parts. I doubt that anything they do would be to your liking.
| |
| James J. Gavan 2004-09-16, 8:55 am |
| Donald Tees wrote:
> James J. Gavan wrote:
>
> AH! now I can see why Robert dislikes it. Sorry about the misnomer.
>
> Donald
>
You are forgiven. But for your "penance" I'm going to send you some code
to see if you can get the MOVE xxx OF to work for me. Should work in
your N/E 3.0.
Jimmy
| |
| James J. Gavan 2004-09-16, 8:55 am |
| Robert Wagner wrote:
>On Sat, 11 Sep 2004 04:52:47 GMT, Warren Simmons
><wsimmons5@optonline.net> wrote:
>
>
>
>
>I was cursed with one of them -- IMS-2000, a bill of materials system
>marketed by Honeywell in the mid-70s. After half a dozen Honeywell
>people failed to make it work right, I rewrote its engine from
>scratch. The fix was to abandon the network model, replacing it with
>tree-structures. I didn't use a formal model, just common sense.
>
>
Robert,
In your own words you appear to have had such an interesting career. So
tell us, why so many moves ?
Jimmy
| |
| Howard Brazee 2004-09-16, 8:55 am |
|
On 9-Sep-2004, "James J. Gavan" <jjgavan@shaw.ca> wrote:
> As a very "lowly' student on SQL - which one ? I thought OCCURS was an
> absolute No-No, given full 'normalization'. And I certainly didn't get
> any enthusiasm for the idea from Tech Support at M/F. Truth is - I do
> have a 'hidden' OCCURS in some of my tables - or at least they become
> OCCURS when I pass the columns back through linkage to the COBOL
> program as a COBOL OCCURS record.
Full normalization of a table of, say, days of the w is silly. And any
large database has DBAs and designers working hard to make what looks to be
normalized data work more efficiently - often by de-normalizing tables.
| |
| Howard Brazee 2004-09-16, 8:55 am |
|
On 9-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
>
> Why not
>
> COPY LAMMASTP REPLACING TAPEIN-RECORD BY TAPEOUT-RECORD
> ...
>
> MOVE CORR TAPEIN-RECORD TO TAPEOUT-RECORD
I did that. Still, I would like to have that COPY REPLACING know the
difference between " 01 " and "(01)".
| |
| Howard Brazee 2004-09-16, 8:55 am |
|
On 9-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
>
> Well, program flow has to start _somewhere_ - are you saying don't have
> an initial paragraph?
You don't "fall through" to the initial paragraph. You start there.
| |
| Howard Brazee 2004-09-16, 8:55 am |
|
On 10-Sep-2004, LX-i <lxi0007@netscape.net> wrote:
>
> That would be fine - then you'd have no "fall-through" paragraphs. :)
If CoBOL had been designed without fall-through paragraphs, there would have
been no reason for a MAIN() label on the initial code. Why bother putting a
label on the first "paragraph" that doesn't get explicitly performed?
| |
| docdwarf@panix.com 2004-09-16, 8:55 am |
| In article <HO62d.423040$M95.10738@pd7tw1no>,
James J. Gavan <jjgavan@shaw.ca> wrote:
>Joe Zitzelberger wrote:
[snip]
>Next it willl be Abraham O'Goldberg !
Well... reminds me of the story of the rabbi who spent his time in
crossing the Atlantic in steerage trying to learn some English; he'd heard
that upon arriving at Ellis Island the first question he'd be asked was
'Can you speak English?' and he wanted to improve his chances.
He gets up to the desk where a bored civil servant, himself an immigrant
from County Cork, looks down at him and barks out 'What's yer name?'...
and those hours spent studying in the hold of the ship slip right out of
his brain. Mly he whispers -
'hab' ich schon vergessen' ('i already forgot')
- and the immigration official can barely hear this so he asks again,
'What's Your Name?'... and the rabbi repeats, with a bit more volume -
'Hab' Ich schon vergessen!'
.... and the official frowns... and shrugs... and writes down what he
heard... and years later, folks were amazed when they walked past a small
synagogue on the Lower East Side of Manhattan and saw the sign, telling
the world that this congregation had:
RABBI: Shawn Fergusson
DD
| |
| Richard 2004-09-16, 8:55 am |
| Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
> <someObject> is just a qualifier. The gist of the statement is INVOKE
> <someObject> "Method". The program is performing an action and the
> double verb reveals grammatical clunkiness.
I would suggest that you may be happier with some other language.
Perhaps you should try comp.lang.perl. There you can write the
programs using just about any word order you would prefer.
> It seems to me that English grammar has a better handle on what makes
> sense than illiterate techie constuctions .. however cloaked they are
> in polysyllabic words. Techies just don't get it. They try to conceal
> their ignorance under a panoply of abstruse constructions.
I would suggest that you may be happier if you design your own
language that would suit your own ideas of perfection. I would be
quite happy to give pointers on how to set up
comp.lang.wagner_is_perfect.
| |
| Robert Wagner 2004-09-16, 8:55 am |
| On 9 Sep 2004 18:53:51 -0400, docdwarf@panix.com wrote:
>In article <chqg2m$oj9$1@peabody.colorado.edu>,
>Howard Brazee <howard@brazee.net> wrote:
>
>Some are, some aren't... I guess it depends on how principled they are.
..
Noting the success of Pibors and zero-strips, the US Treasury has
announced a new series of bonds with missing components. The new
series will be named after former Presidents and Vice-Presidents.
There will be the Dan Quayle Bond, which has no maturity. There will
be a Gerald Ford Bond, which has no interest. Finally, there will be a
Bill Clinton Bond, which has no principal.
| |
| Robert Wagner 2004-09-16, 8:55 am |
| On 15 Sep 2004 14:52:40 GMT, mwojcik@newsguy.com (Michael Wojcik)
wrote:
>In article <joegk05mipj3jee12evgs016daukv6u7hm@4ax.com>, Robert Wagner <robert@wagner.net.yourmammaharvests> writes:
>
>Specifically, "B" is the object of the preposition "by", forming the
>prepositional phrase "by B", which acts as an adverb modifying the
>predicate "multiply A". "A" is the direct object of the verb
>"multiply".
That's what I should have said. :)
>
>It's "correct English" (that is, standard usage) because prepositional
>phrases are often adverbial. I'm not sure exactly what you mean by
>"the object being affected", but "B" is the object of one thing only,
>and that is the preposition "by", and a preposition does not name an
>effect.
That doesn't seem right. The sentence 'Copy A into B' indicates B will
be affected.
>
>"by airplane", again, is an adverbial prepositional phrase. The verb
>"came" here has no object (as we'd expect, since it's intransitive).
Ok.
>
>Here "right" is the direct object and "by his children" is still an
>adverbial prepositional phrase. (Well, arguably it's an adjectival
>prepositional phrase, modifying "right" - ie, describing the scope of
>"rightness" - because English is, after all, ambiguous. But it
>definitely is not an object of the verb "did".)
How about 'He gave money to his children'?
>I agree that I'd expect MULTIPLY ... BY to store the result in the
>first identifier, though. If I say, in English, "now multiply your
>result by 5", I expect the listener to consider the quantity named by
>"result" to now be the product.
It has the same structure as the airplane sentence, except transitive.
You're right. Very good.
| |
| Robert Wagner 2004-09-16, 8:55 am |
| On Wed, 15 Sep 2004 10:02:06 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:1gggk0d8jqa2gn9gn7nt8abinc71kj61ok@
4ax.com...
>
>No, once again, standard COBOL does not allow DIVIDE ... BY, it allows BY
>only in DIVIDE statements of the form DIVIDE ... BY ... GIVING and DIVIDE
>... BY ... GIVING ... REMAINDER. If your implementation allows DIVIDE...BY
>without GIVING, that is an extension that indeed violates the basic
>precedent followed by the other arithmetic verbs, and I would argue against
>both its use and its very existence on those grounds.
Apparently DIVIDE BY without GIVING was allowed by at least two
compilers before '68. We don't know whether the form was in CODASYL or
an extension.
Richard and Realia convinced me the result was stored in the rightmost
word, the denominator. That follows the righty-tighty rule but is
backwards from DIVIDE INTO, which alters the numerator.
| |
| Robert Wagner 2004-09-16, 8:55 am |
| On Wed, 15 Sep 2004 10:25:35 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:
>"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> news:k5sgk01dr0sklr5vdmvt5j8srh1pat7alf@
4ax.com...
>
>
>CODASYL COBOL (a COBOL-60 dialect) for the B6500 required GIVING in DIVIDE | | |