COBOL ain't quite dead - yet ! - cobol

"Richard" <riplin@azonic.co.nz> wrote in message
news:18e8bb27-c836-4a0e-b611-04c111a41ee8@r37g2000prr.googlegroups.com...
> On Oct 30, 10:12 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> "Howard Brazee" <how...@brazee.net> wrote in message
>>
>> news:747hg4965hgegcuojhe10um7ic1f5lnccg@4ax.com...
>>
>> >I have seen
>>
>> > PERFORM AAA THRU AAA-EXIT.
>>
>> > AAA SECTION.
>> > AAA-PARAGRAPH.
>> > ...
>> > AAA-EXIT.
>> > EXIT.
>>
>> > I hate that, but apparently it works. When I maintain this,
>> > sometimes I will replace the EXIT. with CONTINUE, when I add debugging
>> > statements.
>>
>> Back in the late 60s as we started to evolve into "best practices",
>> having
>> tried all the various permutations of PERFORM.. PERFORM.. THRU...
>> SECTIONs
>> and paragraphs, the place where I was working decided (by general
>> consensus)
>> that SECTIONs would be used. They would be structured as you showed
>> above,
>> except that they could contain multiple paragraphs, the last of which
>> would
>> be an EXIT. It was permitted to code GO TO as long as the target was
>> within
>> the SECTION, but not outside of it, and any premature exit from the
>> SECTION
>> was via the last paragraph.
>>
>> The rule was you must ONLY PERFORM a SECTION, NOT a paragraph. You
>> rightly
>> picked up that mixing PERFORMS of paragraphs AND SECTIONs just leads to
>> chaos. (The primary purpose of any paragraphs other then the first and
>> last
>> one in the section was to aid documentation;
>
> In what way did this 'aid documentation' that would not occur if the
> label had an asterisk placed in column 7 ?
>
> Making it as a comment indicates that it _is_ documentation and not
> structural.

But a comment is not visible from 10 pages on down the listing. The Section
name, on the other hand, is referenced in the PERFORM from ANYWHERE in the
program that the code is activated.


>
> Of course if it is 'structural' to the extent that the label and the
> following code is a specific type of processing that is subsiduary to
> the main part of the section then make it so. Make it separate and
> perform it.
>
> The problem with that it that breaking down the sections in a logical
> way is too much effort. Putting in a paragraph label is a lightweight
> solution that makes you feel that the code is properly structured when
> it is not. The style of having 3 labels and an EXIT for everything
> makes it too laborious to properly compose, the style gets in the way
> of expression.

I never found that. But I have little difficulty expressing myself... :-)
>
>> most of the time SECTIONS did
>> not contain paragraphs other then the first and last one. Most of the
>> time
>> the last paragraph was never referenced, but it served to tie up
>> everything
>> and was there should you ever need it. It costs you nothing...
>
> Yes it does. It 'costs' the potential for errors being made.
> Unreferenced paragraph labels (ie drop-through) causes additional time

There is no "drop through" of a sectioned program written by me.

Sections (with the exception of the main one at the start, and this
terminates with a GOBACK, EXIT METHOD, or STOP RUN) can ONLY be PERFORMed,
and ONLY a section can be PERFORMed.

> for the next programmer who has to check whether this would cause a
> logic change. For example if the PERFORM had been done in error to the
> first paragraph name instead of the section name then the spurious
> paragraph label would end the perform while a comment line would not.

If the site standard is that ONLY sections get PERFORMed, there won't be
erroneous PERFORMs of paragraphs. After working this way for a few weeks you
stop thinking about paragraphs altogether.

>
> Having the section and first paragraph labels 'costs' the possibility
> of the wrong one being performed.

In theory, maybe. In practise, at least in my experience, never.

>Having an exit label 'costs' the
> possibility of errors such as goto the wrong one, or having a goto
> added when the paragraph was performed in error.
>
> Some of those errors would still have the program perform perfectly
> _until_, for example, a goto exit was added.

It has never happened.

>
> As the only validation for the correctness of the style is by visual
> inspection of the whole program then it is not a style that I would
> use.
>

Fair enough.

It works for me. (And ,over the years, I have never had people complain
about maintaining my code.)

I am not advocating that everyone SHOULD code this way, I'm simply
documenting why I code this way.
>
>> This is very
>> similar conceptually to PERFORMing a single paragraph,
>
> No it isn't. It is a cluttered and error prone version that is only
> used to allow unstructured gotos when it is too arduous to construct
> logic that does not require gotos.

Obviously, I strongly disagree :-)

As I avoid the use of GO TO and most of the places where I've worked
discourage them too, your objection is simply academic.
>
> Of course the gotos are allowed because the sections become large and
> unwieldy because of the overhead of the excessive labels. With simple
> paragraphs the 'cost' of breaking down the code into smaller parts and
> is trivial, so the logic can be used to avoid the need for goto
> _without_ deep indending.
>
>
>> but the SECTIONing of
>> code simply documents specific functionality better than a paragraph. A
>> series of paragraphs is just a program. A series of SECTIONS delineates
>> specific functions more visibly, in my opinion.)
>>
>> Some of us who were fond of PERFORM... THROUGH grumbled a bit and pointed
>> out that the "range" of a SECTION was not specifc and things could be
>> added
>> to the wrong SECTION, or a SECTION PERFORMED from different places might
>> sometimes need the new paragraph and other times not need it; with
>> PERFORM
>> ...THRU you always knew exactly what was being performed. However, we all
>> agreed to give the new idea a try.
>>
>> After a few weeks of implementing the new standard we all agreed it was
>> excellent. It is simple, and clear. It avoided spaghetti code in a time
>> when
>> most COBOL sites were like Italian restaurants.
>>
>> To this day I code COBOL In that way and I don't apologise for it.
>
> Well you should do ;-)

No, I'd rather fight my corner on it, as i am doing here... :-)
>
>> With OO
>> COBOL each SECTION often becomes a METHOD and gets invoked on SELF,
>> rather
>> than PERFORMED. This has the advantage that you can pass parameters to it
>> and keep data within the code that uses it, rather than everything having
>> to
>> be global like it is if you PERFORM it. For "internal" (private) methods
>> like this I don't mind sending them parameters, but I don't generally do
>> this for public methods which are visible to the outside world, because
>> that
>> complicates the interface and has knock on effects on general
>> maintenance. I
>> use Properties, GETters and SETters for these instead.
>>
>> Many people object to SECTIONing COBOL, seeing it as a relic from the
>> days
>> of overlaying and segmentation. I don't. Certainly, I used it for
>> segmentation on different platforms and found it very useful, but I was
>> always keenly aware that the SECTIONing was not about overlaying, it was
>> about functionality.
>>
>> In 35 years, since I adopted this approach, I have NEVER had a program go
>> out of control, and that applies on platforms where PERFORM is
>> implemented
>> by returning on a modified address in memory, on a specific register, or
>> on
>> a stack based architecure where the return address is POPped from the
>> stack.
>>
>> It works for me, YMMV.
>
> What is 'easy' is entirely what you are used to.

Agreed. But remember thta applies to you equally as much as it does to me...
:-)


> When one writes code
> in a particular style one knows exactly the idiom and thus makes no
> (or fewer) mistakes. I have worked on code that is as you describe
> that had many errors and bug-traps. It was obvious that some other
> programmer had later worked on the code and didn't understand the
> idiom, or didn't adhere to the style correctly.

Or didn't implement the site standards.

Pete.
--
"I used to write COBOL...now I can do anything."

<docdwarf@panix.com> wrote in message news:gec9p1$9b1$1@reader1.panix.com...
> In article <6mtfb8Figc16U1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>>Speaking of that, I had an unexpected visit from a lady I know and had not
>>seen for some time.
>
> [snip]
>
>>"What about a downloadable guitar tuner, that you could have on your cell
>>phone?"
>>
>>I realised this was a stroke of brilliance and wheels in the back of my
>>head
>>started spinning, processing what would be involved.
>
> How curious... I recall reading, decades on back, in a Very Reputable
> Source (I think it was 'The Reader's Digest') that there was a
> telephone-number one could dial in Austria and get - granted, with the
> quality available in the late 1960s, rotary-dial telephones and actual
> copper-wire connections - a 'concert A', 440 cycles, in the same way that
> one could, during those days, call a local number in some parts of the USA
> and get the time of day.

I never heard about that. It's impressive, for the time.

>
> [snip]
>
>>The trouble with really good ideas is that if you have them, other people
>>probably do too... :-)
>>
>>In seconds I found 15 different applications that could be loaded to a
>>cell
>>phone and would enable it to act as a guitar tuner. :-)
>
> It has been my experience, Mr Dashwood, that *very* few people are
> sufficiently creative to want something Truly New... in the business-world
> I inhabit I usually see 'Well, what I want is more-or-less what Jim gets
> for the quarterlies and Jane gets for the semi-annuals... but sorted
> differently... and could you somehow get it to underline the deleted
> entries that aren't there any more?'

Yes, but we should live in hope... right, Doc? :-)

Pete.
--
"I used to write COBOL...now I can do anything."

"Richard" <riplin@azonic.co.nz> wrote in message
news:84113dcc-2936-401a-861d-712ac9f93533@e1g2000pra.googlegroups.com...
> On Oct 30, 11:07 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>> "Robert" <n...@e.mail> wrote in message
>>
>> newse6ig4t8nhvj7tv9uakknckth23q08ru51@4ax.com...
>>
>>
>>
>> > On Mon, 27 Oct 2008 12:02:29 -0600, "James J. Gavan"
>> > <jgavandeletet...@shaw.ca> wrote:
>>
>> >>+Micro Focus ACTION Program exceeds 50 U.S member Universities
>>
>> >>ACTION-assisted courses ensure graduates are skilled in high-demand
>> >>COBOL
>>
>> > To see demand for Cobol in job ads, go to:
>>
>> >http://www.indeed.com/jobtrends
>>
>> > Enter "cobol" without quotes. Note the trend is declining, has fallen
>> > about 30% in three
>> > years.
>>
>> > Enter "cobol, c#" without quotes. This undocumented feature allows you
>> > to
>> > compare multiple
>> > trends on one graph. Note that c# doubled in three years, is about four
>> > times Cobol.
>>
>> > Enter "cobol, java, c#, pl/sql" without quotes. Note that java is about
>> > double the other
>> > three combined, and pl/sql is double Cobol.
>>
>> Interesting figures, Robert.
>>
>> Jobs are only an indicator of actual use though.
>
> And Robert wasn't even measuring jobs, but was seeing 'empty seats'.
> The ads were trying to find people to sit at desks that are currently
> _not_ doing any programming.
>
> The number of ads may just be an indication of the turn over rate of
> the programmers. If COBOL programmers stay at the same position for
> decades (because they are married, have kids, own houses and are
> stable) while C# programmers are just out of school and keep
> travelling, bumming out, OEs etc, then they need to be replaced -
> hence ads.
>
> Alternately it may indicate shortage of programmers in that language,
> the more ads the less programmers that there are.
>
>> For example, there are
>> millions of people using C# and Java who don't have programming jobs, do
>> not
>> consider themselves professional programmers, and are maybe writing
>> applications for their friends and family... then ther are all the "one
>> man
>> bands" who won't appear in the job ads but are beavering away in the
>> eternal
>> hope of finding the "killer application".
>>
>> Speaking of that, I had an unexpected visit from a lady I know and had
>> not
>> seen for some time. She had been in Cuba making music videos and was
>> passing
>> through, Tauranga where she was judging a Salsa dancing contest. She took
>> time to drop by and have lunch with me. We've been friends for years and
>> our
>> connection is through the Arts and music. Anyway, she saw my laptop
>> sitting
>> on the coffee table and asked me what I was writing. So I told her (both
>> in
>> the prose sense and in the programming sense). She got quite
>> enthusiastic...
>>
>> "Could you write an application for a mobile device, like a cell phone or
>> iPod?".
>>
>> I confirmed that I had the tools to do so and had been thinking about
>> this
>> for some time. Unfortunately, it is on a back burner while I complete the
>> things I'm doing currently.
>>
>> I asked her what she had in mind.
>>
>> "What about a downloadable guitar tuner, that you could have on your cell
>> phone?"
>>
>> I realised this was a stroke of brilliance and wheels in the back of my
>> head
>> started spinning, processing what would be involved. Finally the little
>> ticket emerged which said "Viable, and a very interesting task".
>>
>
> I suspect that the speaker size and quality will have a significant
> effect on whether it would be viable or not.

No, it is about frequency, not quality. The quality of the microphone is
important, but the speakers don't matter at all. In fact the device I use
has no speakers.

>
>
>> "Lizzie, that's a brilliant idea... I'd really like to write that." She
>> beamed.
>>
>> "While I was in Havana the guys in the band were always misplacing their
>> guitar tuners... but they always had their cell phones to hand. Seems to
>> me
>> if the cell phones could act as tuners it would be really cool..."
>>
>> I promised to look into it and told her if I did it, and made money from
>> it,
>> I'd see she got a fair cut... She looked at me and said: "I know you
>> would
>> Pete. But it isn't about the money. I just think it would be a useful
>> thing
>> to have..."
>>
>> After she'd gone I was quite excited and found it difficult to continue
>> with
>> normal work...
>>
>> I hopped onto GOOGLE and searched, hoping that I wouldn't find anything.
>> I
>> started thinking this could be the "killer application"....
>>
>> The trouble with really good ideas is that if you have them, other people
>> probably do too... :-)
>>
>> In seconds I found 15 different applications that could be loaded to a
>> cell
>> phone and would enable it to act as a guitar tuner. :-)
>>
>> My other idea (letting a cell phone act as a wireless router to provide
>> Internet and WLAN connection for wireless enabled devices within the
>> range
>> of the phone) has also been done, quite recently, for Windows based
>> phones...
>
> I use, and program, a Nokia 800 - its a computer not a phone. It can
> connect to a Nokia phone (or similar) over Bluetooth to access the
> internet (or use WiFi), has done for years.

Yes, I have a Sony cellphone which I connect to my computer via Bluetooth.
Mine is a T86. I bought it in the U.K.with a deal through BT, and was
surprised to find that it worked anywhere on Earth, including the USA.
Really old now, but state-of-the-art in it's day. As I don't use a mobile
very much, it serves me adequately. I connect using "Float" (Open Source)
software. It is an excellent package.

Pete.
--
"I used to write COBOL...now I can do anything."

On Oct 31, 11:34 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@azonic.co.nz> wrote in message
>
> news:18e8bb27-c836-4a0e-b611-04c111a41ee8@r37g2000prr.googlegroups.com...
>
>
>
> > On Oct 30, 10:12 am, "Pete Dashwood"
> > <dashw...@removethis.enternet.co.nz> wrote:
> >> "Howard Brazee" <how...@brazee.net> wrote in message
>
> >>news:747hg4965hgegcuojhe10um7ic1f5lnccg@4ax.com...
>
> >> >I have seen
>
> >> > PERFORM AAA THRU AAA-EXIT.
>
> >> > AAA SECTION.
> >> > AAA-PARAGRAPH.
> >> > ...
> >> > AAA-EXIT.
> >> > EXIT.
>
> >> > I hate that, but apparently it works. When I maintain this,
> >> > sometimes I will replace the EXIT. with CONTINUE, when I add debugging
> >> > statements.
>
> >> Back in the late 60s as we started to evolve into "best practices",
> >> having
> >> tried all the various permutations of PERFORM.. PERFORM.. THRU...
> >> SECTIONs
> >> and paragraphs, the place where I was working decided (by general
> >> consensus)
> >> that SECTIONs would be used. They would be structured as you showed
> >> above,
> >> except that they could contain multiple paragraphs, the last of which
> >> would
> >> be an EXIT. It was permitted to code GO TO as long as the target was
> >> within
> >> the SECTION, but not outside of it, and any premature exit from the
> >> SECTION
> >> was via the last paragraph.
>
> >> The rule was you must ONLY PERFORM a SECTION, NOT a paragraph. You
> >> rightly
> >> picked up that mixing PERFORMS of paragraphs AND SECTIONs just leads to
> >> chaos. (The primary purpose of any paragraphs other then the first and
> >> last
> >> one in the section was to aid documentation;
>
> > In what way did this 'aid documentation' that would not occur if the
> > label had an asterisk placed in column 7 ?
>
> > Making it as a comment indicates that it _is_ documentation and not
> > structural.
>
> But a comment is not visible from 10 pages on down the listing. The Section
> name, on the other hand, is referenced in the PERFORM from ANYWHERE in the
> program that the code is activated.

Your claim was: "(The primary purpose of any paragraphs other then the
first and last one in the section was to aid documentation;". This was
what I directly answered by asking if this was any more useful than
the exactly the same label made into a comment. It has nothing to do
with section name or being performed.

Do try and keep up.


> > Of course if it is 'structural' to the extent that the label and the
> > following code is a specific type of processing that is subsiduary to
> > the main part of the section then make it so. Make it separate and
> > perform it.
>
> > The problem with that it that breaking down the sections in a logical
> > way is too much effort. Putting in a paragraph label is a lightweight
> > solution that makes you feel that the code is properly structured when
> > it is not. The style of having 3 labels and an EXIT for everything
> > makes it too laborious to properly compose, the style gets in the way
> > of expression.
>
> I never found that. But I have little difficulty expressing myself... :-)
>
>
>
> >> most of the time SECTIONS did
> >> not contain paragraphs other then the first and last one. Most of the
> >> time
> >> the last paragraph was never referenced, but it served to tie up
> >> everything
> >> and was there should you ever need it. It costs you nothing...
>
> > Yes it does. It 'costs' the potential for errors being made.
> > Unreferenced paragraph labels (ie drop-through) causes additional time
>
> There is no "drop through" of a sectioned program written by me.

Your claim was: "(The primary purpose of any paragraphs other then the
first and last one in the section was to aid documentation;". These
are the 'unreferenced labels' that _ARE_ dropped thru.

Do try and keep up.

> Sections (with the exception of the main one at the start, and this
> terminates with a GOBACK, EXIT METHOD, or STOP RUN) can ONLY be PERFORMed,
> and ONLY a section can be PERFORMed.

Of course if the word 'SECTION' is omitted by mistake then the
compiler won't care, or warn you. There is also no check that every
label referenced by a PERFORM _is_ a section label.

OTOH is is simple to verify the reverse. A grep will confirm that
there are no SECTION words in the procedure division and thus performs
are _only_ of paragraph labels. A grep will confirm there is no use of
THRU. What do you have ?


> > for the next programmer who has to check whether this would cause a
> > logic change. For example if the PERFORM had been done in error to the
> > first paragraph name instead of the section name then the spurious
> > paragraph label would end the perform while a comment line would not.
>
> If the site standard is that ONLY sections get PERFORMed, there won't be
> erroneous PERFORMs of paragraphs. After working this way for a few weeks you
> stop thinking about paragraphs altogether.

What mechanism guarantees this, other than visusal inspection of every
perform and the label it references ?

Oh, wait. You just trust other programmers assurances that they never
make mistakes ?


> > Having the section and first paragraph labels 'costs' the possibility
> > of the wrong one being performed.
>
> In theory, maybe. In practise, at least in my experience, never.

Or maybe you never noticed because performing the first paragraph
gives identical results in testing so the program is 'bug free' -
until someone adds a goto exit or exit section or a 'commentary'
paragraph label.

The issue isn't whether programmers are perfect, not even I am that,
but whether the code can be verified to match the standard.

> >Having an exit label 'costs' the
> > possibility of errors such as goto the wrong one, or having a goto
> > added when the paragraph was performed in error.
>
> > Some of those errors would still have the program perform perfectly
> > _until_, for example, a goto exit was added.
>
> It has never happened.

Well, OK, you _are_ perfect then. But others may not be so.


> > As the only validation for the correctness of the style is by visual
> > inspection of the whole program then it is not a style that I would
> > use.
>
> Fair enough.
>
> It works for me. (And ,over the years, I have never had people complain
> about maintaining my code.)
>
> I am not advocating that everyone SHOULD code this way, I'm simply
> documenting why I code this way.

And I am saying why I progressed beyond that.

> >> This is very
> >> similar conceptually to PERFORMing a single paragraph,
>
> > No it isn't. It is a cluttered and error prone version that is only
> > used to allow unstructured gotos when it is too arduous to construct
> > logic that does not require gotos.
>
> Obviously, I strongly disagree :-)
>
> As I avoid the use of GO TO and most of the places where I've worked
> discourage them too, your objection is simply academic.

If you eliminate the use of goto then there is never any need to have
the clutter of the exit paragraph. A simple line of hyphens or equals
is what I use to separate parts of the program.

If you eliminate the exit paragraphs and have already stated that the
'first paragraph' is unreferenced then you can eliminate that and, by
removing all the SECTION words you have an actual assurance that all
the performs _are_ consistent.

>
> > Of course the gotos are allowed because the sections become large and
> > unwieldy because of the overhead of the excessive labels. With simple
> > paragraphs the 'cost' of breaking down the code into smaller parts and
> > is trivial, so the logic can be used to avoid the need for goto
> > _without_ deep indending.
>
> >> but the SECTIONing of
> >> code simply documents specific functionality better than a paragraph. A
> >> series of paragraphs is just a program. A series of SECTIONS delineates
> >> specific functions more visibly, in my opinion.)
>
> >> Some of us who were fond of PERFORM... THROUGH grumbled a bit and pointed
> >> out that the "range" of a SECTION was not specifc and things could be
> >> added
> >> to the wrong SECTION, or a SECTION PERFORMED from different places might
> >> sometimes need the new paragraph and other times not need it; with
> >> PERFORM
> >> ...THRU you always knew exactly what was being performed. However, we all
> >> agreed to give the new idea a try.
>
> >> After a few weeks of implementing the new standard we all agreed it was
> >> excellent. It is simple, and clear. It avoided spaghetti code in a time
> >> when
> >> most COBOL sites were like Italian restaurants.
>
> >> To this day I code COBOL In that way and I don't apologise for it.
>
> > Well you should do ;-)
>
> No, I'd rather fight my corner on it, as i am doing here... :-)
>
>
>
>
>
> >> With OO
> >> COBOL each SECTION often becomes a METHOD and gets invoked on SELF,
> >> rather
> >> than PERFORMED. This has the advantage that you can pass parameters to it
> >> and keep data within the code that uses it, rather than everything having
> >> to
> >> be global like it is if you PERFORM it. For "internal" (private) methods
> >> like this I don't mind sending them parameters, but I don't generally do
> >> this for public methods which are visible to the outside world, because
> >> that
> >> complicates the interface and has knock on effects on general
> >> maintenance. I
> >> use Properties, GETters and SETters for these instead.
>
> >> Many people object to SECTIONing COBOL, seeing it as a relic from the
> >> days
> >> of overlaying and segmentation. I don't. Certainly, I used it for
> >> segmentation on different platforms and found it very useful, but I was
> >> always keenly aware that the SECTIONing was not about overlaying, it was
> >> about functionality.
>
> >> In 35 years, since I adopted this approach, I have NEVER had a program go
> >> out of control, and that applies on platforms where PERFORM is
> >> implemented
> >> by returning on a modified address in memory, on a specific register, or
> >> on
> >> a stack based architecure where the return address is POPped from the
> >> stack.
>
> >> It works for me, YMMV.
>
> > What is 'easy' is entirely what you are used to.
>
> Agreed. But remember thta applies to you equally as much as it does to me...
> :-)

Well I was 'used to' using sections, exactly as you said. Then I
realised the steps as above and noticed that I had several less things
that needed checking to make the program work correctly.

For example when coding using your style I noticed that every time I
did a perform I checked it was the section name, that there was an
exit paragraph, that the following label was indeed a section header.
Everytime I split a section I went through the same checks and had to
key in the clutter.

As soon as I changed to paragraphs only I immediately noticed that
there was almost nothing that needed checking. What I did
automatically and treated as a normal part of all programming simply
was not needed. This sped up my programming and resulted in less
testing and correction being required.




> > When one writes code
> > in a particular style one knows exactly the idiom and thus makes no
> > (or fewer) mistakes. I have worked on code that is as you describe
> > that had many errors and bug-traps. It was obvious that some other
> > programmer had later worked on the code and didn't understand the
> > idiom, or didn't adhere to the style correctly.
>
> Or didn't implement the site standards.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."

Pete Dashwood wrote:
> <docdwarf@panix.com> wrote in message news:gec9p1$9b1$1@reader1.panix.com...
>> In article <6mtfb8Figc16U1@mid.individual.net>,
>> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>>
>> [snip]
>>
>>> Speaking of that, I had an unexpected visit from a lady I know and had not
>>> seen for some time.
>> [snip]
>>
>>> "What about a downloadable guitar tuner, that you could have on your cell
>>> phone?"
>>>
>>> I realised this was a stroke of brilliance and wheels in the back of my
>>> head
>>> started spinning, processing what would be involved.
>> How curious... I recall reading, decades on back, in a Very Reputable
>> Source (I think it was 'The Reader's Digest') that there was a
>> telephone-number one could dial in Austria and get - granted, with the
>> quality available in the late 1960s, rotary-dial telephones and actual
>> copper-wire connections - a 'concert A', 440 cycles, in the same way that
>> one could, during those days, call a local number in some parts of the USA
>> and get the time of day.
>
> I never heard about that. It's impressive, for the time.

Back in the 70s when I was working in broadcasting in the US, before the
breakup of the Bell (AT&T) System, Ohio Bell in Columbus (at least) had
not only a tone source but also a dialable termination (for measuring
noise) and a line pair switch, ie the tip and ring wires were switched
every so many seconds.

>
>> [snip]
>>
>>> The trouble with really good ideas is that if you have them, other people
>>> probably do too... :-)
>>>
>>> In seconds I found 15 different applications that could be loaded to a
>>> cell
>>> phone and would enable it to act as a guitar tuner. :-)
>> It has been my experience, Mr Dashwood, that *very* few people are
>> sufficiently creative to want something Truly New... in the business-world
>> I inhabit I usually see 'Well, what I want is more-or-less what Jim gets
>> for the quarterlies and Jane gets for the semi-annuals... but sorted
>> differently... and could you somehow get it to underline the deleted
>> entries that aren't there any more?'
>
> Yes, but we should live in hope... right, Doc? :-)
>
> Pete.

Jeff


----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= - Total Privacy via Encryption =---

In article <6muradFirp0kU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
><docdwarf@panix.com> wrote in message news:gec9p1$9b1$1@reader1.panix.com...

[snip]

>> How curious... I recall reading, decades on back, in a Very Reputable
>> Source (I think it was 'The Reader's Digest') that there was a
>> telephone-number one could dial in Austria and get - granted, with the
>> quality available in the late 1960s, rotary-dial telephones and actual
>> copper-wire connections - a 'concert A', 440 cycles, in the same way that
>> one could, during those days, call a local number in some parts of the USA
>> and get the time of day.
>
>I never heard about that. It's impressive, for the time.

What I drew from it was that different societies consider *very* different
Should Be available from a given technology... but I was a bit younger
then.

[snip]

>> It has been my experience, Mr Dashwood, that *very* few people are
>> sufficiently creative to want something Truly New... in the business-world
>> I inhabit I usually see 'Well, what I want is more-or-less what Jim gets
>> for the quarterlies and Jane gets for the semi-annuals... but sorted
>> differently... and could you somehow get it to underline the deleted
>> entries that aren't there any more?'
>
>Yes, but we should live in hope... right, Doc? :-)

One may desire the finest of chicken-meat, Mr Dashwood, but it is not a
bad idea to be ready to deal with the meanest of sausages...

.... so hope for the breast but prepare for the wurst.

DD

>>worse yet, "GO TO DEPENDING ON" where the targets are also the targets of
>>ALTER statements
>
> That's not highly-demanding... that's piteously mewling for '... help....
> help!'
>


The site is a state university, and the code was written in the late 70's.
according to a few of the folks that had been there forever, the original
author had a habit of oing to the campus pub (remember those?) for a few
hours every afternoon, and then went back to work.


It ended up being a complete rewrite, after completed the original
1500 loc condensed into about 175, as most of what was in the original was
either dead code or stuff that just could not logically happen.



--
Silfax

In article <pan.2008.10.31.11.03.37.792025@localhost.localdomain>,
Silfax <root@localhost.localdomain> wrote:
>
>>>worse yet, "GO TO DEPENDING ON" where the targets are also the targets of
>>>ALTER statements
>>
>> That's not highly-demanding... that's piteously mewling for '... help....
>> help!'
>>
>
>
>The site is a state university, and the code was written in the late 70's.
>according to a few of the folks that had been there forever, the original
>author had a habit of oing to the campus pub (remember those?) for a few
>hours every afternoon, and then went back to work.

Do I remember 'the campus pub'? Well... perhaps that accounts for some of
my current porosity.

>
>
>It ended up being a complete rewrite, after completed the original
>1500 loc condensed into about 175, as most of what was in the original was
>either dead code or stuff that just could not logically happen.

As Wittgenstein put it, 'Logic is a game played by a certain set of
rules'... perhaps a bit of ethanol could ALTER RULE-SET TO PROCEED TO
PLACE-NOT-POSSIBLE?

(no, I don't need the Goldilocks story again... but thanks for offering)

DD

On Fri, 31 Oct 2008 11:34:42 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>If the site standard is that ONLY sections get PERFORMed, there won't be
>erroneous PERFORMs of paragraphs. After working this way for a few weeks you
>stop thinking about paragraphs altogether.
>
>>
>> Having the section and first paragraph labels 'costs' the possibility
>> of the wrong one being performed.
>
>In theory, maybe. In practise, at least in my experience, never.

I have seen it happen. People come from all sorts of backgrounds,
even to shops with strict structural coding standards.

I've also seen people put paragraphs after exit paragraphs, without
noticing that the new performed paragraphs are part of a section.

Hmmm, I wonder if shops with such standards should end each section
with an EXIT SECTION command, if it was available. Trouble is, I
expect most shops with such standards don't have it available.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison