Home > Archive > Cobol > June 2007 > Use of Class conditions in COBOL (was: Re: for a laught (???)_
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 |
Use of Class conditions in COBOL (was: Re: for a laught (???)_
|
|
| Rick Smith 2007-06-18, 7:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dm9m3F34unkmU1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:137bqa93d3t9kb4@corp.supernews.com...
>
> And you certainly realize, Rick, that a lot more than COBOL gets covered
> here... :-)
>
> People who are making the transition from COBOL to "something else" (and
> there is an increasing number of them) are certainly interested in other
> solutions. That doesn't mean they are not interested in COBOL; solutions
are
> not necessarily mutually exclusive...(I have a number of C# solutions that
> still utilise COBOL, for example...)
Or, perhaps there is one who is interested in getting people
to make "the transition from COBOL to 'something else'" and
regularly mentions C#. <g>
in[color=darkred]
>
> Pretty trivial, huh?
I never said it was trivial, only "hardly overwhelming".
> Perhaps you'd like to post it? :-)
Shown below, 193 lines. Note that I do more than the
regular expression given above.
[I really had no interest in writing the code; but, I couldn't
sleep (a predator, who wanted to mow my yard, showed
up at my doorstep triggering one of my OCD reactions) and
I could not recall any recent discussion of class conditions.]
>
> So POSIX has RegExs available to COBOL? That's interesting. As mentioned
> earlier, I was considering getting the VB regEx engine (which is actually
a
> COM component) working with Fujitsu COBOL, but moving to C# meant I didn't
> have to. In fact, moving to Perl, PHP, Ruby, Java, or just about ANYTHING
> would have provided support for RegExs...
>
>
>
> No, my point was about RegExs, not about C# (although I really like using
C#
> :-))
I reviewed the thread and found that your comments about
regular expressions were hardly separable from C#, including
your using Microsoft's perversion of the ISO standard for
regular expressions. But, maybe I have some bias. <G>
-----
$set ans85 flag"ans85" flagas"s"
identification division.
program-id. emailadr.
*
* Demonstration program to validate email addresses;
* but does not necessarily recognize all valid
* email addresses.
*
* In particular, it demonstrates the use of class
* conditions to validate the character content of fields.
*
environment division.
configuration section.
special-names.
alphabet email is standard-1
class local-chars is "A" thru "Z" "a" thru "z"
"0" thru "9" "_" "%" "-"
* domain-chars also used for server
class domain-chars is "A" thru "Z" "a" thru "z"
"0" thru "9" "-"
* domain-type-chars also used for country
class domain-type-chars is "A" thru "Z" "a" thru "z"
| |
| Pete Dashwood 2007-06-18, 9:56 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:137cjk4fgjh1hef@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dm9m3F34unkmU1@mid.individual.net...
> are
>
> Or, perhaps there is one who is interested in getting people
> to make "the transition from COBOL to 'something else'" and
> regularly mentions C#. <g>
>
(OK, the following is serious and I promise I am not being mischievous...)
If you mean me, I plead "not guilty".
(I'm "guilty" of mentioning C#, certainly, but only in the context of
alternatives to COBOL. Why should we consider alternatives to COBOL? See
below...)
I have no vested interest in this and am not on commission to anyone.
What possible gain is there for me in persuading people away from COBOL?
None, whatsoever. But then, I don't have to; they are voting with their
feet...
I see a trend. I try to understand why it is a trend, and I find a paradigm
shift is occurring that will leave COBOL out in the cold, within a few
years. As always, I call them like I see them.
What can be done about it? Many people here (like myself) have a huge
investment in COBOL, accrued over many years. So any alternative needs to
consider that investment. That's how I arrived at C#. It offers great
Interoperability and that was what first attracted me to it. I needed a
DotNET solution and I couldn't get a COBOL one. C# offered easy entry into
DotNET with no loss of COBOL assets, and a MUCH more productive IDE than I
had ever had (on PC or mainframe) previously.
End of story.
I know COBOL will be around for some time yet and I'm glad about that. But I
also know it won't be indefinite or even for the foreseeable future.
I have had a history here of promoting unpopular viewpoints.
1. I recommended RDBs when everyone said there was nothing wrong with ISAM.
2. I tried very hard (and, generally, failed dismally :-)) to encourage
people to look at OO and maybe learn Java or extend their COBOL skillsets.
3. I brought the message about components here. (24000 people read an
article I wrote on it, the link to which was ONLY published here.)
4. Now I'm saying COBOL has a limited life and it's time to look at
alternatives.
Does any of that sound irresponsible or wrong? (It may be debatable,
certainly, but these are viewpoints I hold.)
So many times I've debated these issues here and been beat up and abused.
But sometimes, something I say strikes a chord with someone and they go and
do it. And at least I know I tried... :-)
Outside of this forum what is the world doing?
Using OO, accessing RDBs, gluing components together, implementing
component based designs, and considering new ways of doing things. Ways
that are unknown to COBOL people generally. Genetic algorithms, Regular
expressions, Lambda functions, heuristic programming... Should these
subjects be taboo because COBOL does not support them?
I don't think so, and there's no way you can shut me up :-) (Thank God for
free speech and unmoderated Usenet forums...:-))
If you don't like what I say here, put me on your kill list (Usenet please,
not in the real world :-)), simply don't read or respond to my mail, or make
your case against it, but don't ascribe ulterior motives to me or accuse me
of doing things I'm not.
I am nothing if not up front and honest in my positions. Yes, I like C# (it
has grown on me since I started using it), but I also like COBOL and Java.
Yes, I think the lifetime for COBOL is limited, but I am certainly not alone
in that. I'd like to see people here preparing for the end of it and, to
that extent, I may suggest other alternatives, and document my experience in
moving away from it. Some people find that helpful. Others, take it as a
personal attack on COBOL; it isn't.
Finally, I DIDN'T post the C# code until someone asked me to
</end of very strong serious statement>
Now, back to Regular expressions... :-)
> in
>
> I never said it was trivial, only "hardly overwhelming".
>
>
> Shown below, 193 lines. Note that I do more than the
> regular expression given above.
>
> [I really had no interest in writing the code; but, I couldn't
> sleep (a predator, who wanted to mow my yard, showed
> up at my doorstep triggering one of my OCD reactions) and
> I could not recall any recent discussion of class conditions.]
Well, full credit for coding it anyway, Rick.
>
> a
> C#
>
> I reviewed the thread and found that your comments about
> regular expressions were hardly separable from C#, including
> your using Microsoft's perversion of the ISO standard for
> regular expressions. But, maybe I have some bias. <G>
I think we both have :-) Nevertheless, I respect your posts here and have
always done so.
My background for RegExs is certainly a MicroSoft one so I have been exposed
to their examples. I'm not as sensitive about standards as you are. But we
won't go there...:-) suffice to say, if something works (and saves me time),
but violates a "standard" (which may be non-existent outside the paper it is
written on), I'll bend the standard every time. I don't consider this
perverted, or even perverse; I consider it pragmatic.
>
> -----
> $set ans85 flag"ans85" flagas"s"
> identification division.
> program-id. emailadr.
> *
> * Demonstration program to validate email addresses;
> * but does not necessarily recognize all valid
> * email addresses.
> *
> * In particular, it demonstrates the use of class
> * conditions to validate the character content of fields.
> *
> environment division.
> configuration section.
> special-names.
> alphabet email is standard-1
> class local-chars is "A" thru "Z" "a" thru "z"
> "0" thru "9" "_" "%" "-"
> * domain-chars also used for server
> class domain-chars is "A" thru "Z" "a" thru "z"
> "0" thru "9" "-"
> * domain-type-chars also used for country
> class domain-type-chars is "A" thru "Z" "a" thru "z"
> .
> data division.
> working-storage section.
> 77 current-position binary pic 9(4) value 1.
> 01 work-area.
> 02 work-status binary pic s9(4) value +0.
> 02 local-count binary pic 9(4) value 0.
> 02 local-delimiter pic x value space.
> 02 local-part pic x(31) value space.
> 02 domain-part-count binary pic 9(4) value 0.
> 02 domain-count-1 binary pic 9(4) value 0.
> 02 domain-delimiter-1 pic x value space.
> 02 domain-part-1 pic x(31) value space.
> 02 domain-count-2 binary pic 9(4) value 0.
> 02 domain-delimiter-2 pic x value space.
> 02 domain-part-2 pic x(31) value space.
> 02 domain-count-3 binary pic 9(4) value 0.
> 02 domain-delimiter-3 pic x value space.
> 02 domain-part-3 pic x(31) value space.
> 02 domain-count-4 binary pic 9(4) value 0.
> 02 domain-delimiter-4 pic x value space.
> 02 domain-part-4 pic x(31) value space.
> linkage section.
> 01 email-address pic x(256).
> 01 validation-status binary pic s9(4).
> procedure division
> using email-address validation-status.
> begin.
> initialize work-area
> move 1 to current-position
> unstring email-address
> delimited by "@" or all space
> into local-part
> delimiter in local-delimiter
> count in local-count
> with pointer current-position
> on overflow
> if local-delimiter = "@"
> if local-part (1:local-count) is local-chars
> perform get-domain-part
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> not on overflow
> move -1 to work-status
> end-unstring
> move work-status to validation-status
> exit program
> .
> end-of-program.
> stop run
> .
>
> get-domain-part.
> unstring email-address
> delimited by "." or all space
> into domain-part-1
> delimiter in domain-delimiter-1
> count in domain-count-1
> domain-part-2
> delimiter in domain-delimiter-2
> count in domain-count-2
> domain-part-3
> delimiter in domain-delimiter-3
> count in domain-count-3
> domain-part-4
> delimiter in domain-delimiter-4
> count in domain-count-4
> with pointer current-position
> tallying domain-part-count
> end-unstring
> evaluate domain-part-count
> when 2
> * domain.type
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 >= 2 and <= 4
> and domain-part-2 (1:domain-count-2)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> when 3
> * domain.type.country or
> * server.domain.type
> perform try-domain-type-country
> if work-status not = 0
> move 0 to work-status
> perform try-server-domain-type
> end-if
> when 4
> * server.domain.type.country
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 > 0
> and domain-part-2 (1:domain-count-2)
> is domain-chars
> if domain-count-3 >= 2 and <= 4
> and domain-part-3 (1:domain-count-3)
> is domain-type-chars
> if domain-count-4 = 2
> and domain-part-4 (1:domain-count-4)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> when other
> move -1 to work-status
> end-evaluate
> .
> try-domain-type-country.
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 >=2 and <=4
> and domain-part-2 (1:domain-count-2)
> is domain-chars
> if domain-count-3 = 2
> and domain-part-3 (1:domain-count-3)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> .
> try-server-domain-type.
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 > 0
> and domain-part-2 (1:domain-count-2)
> is domain-chars
> if domain-count-3 >= 2 and <= 4
> and domain-part-3 (1:domain-count-3)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> .
> end program emailadr.
> -----
>
Well, I think that's a work of art :-).
Good job.
I s'pose it isn't fair to mention at this point that the C# solution did it
with one line of code? :-) OK, I won't mention that...besides, it used a
perverted MS implementation.... :-)
This is a perfect example of why procedural coding cannot continue. It
simply costs too much to write code line by line and have thousands of lines
of it. Fortunately, in the 21st century, we don't have to (unlike the latter
half of the 20th century where there really wasn't much choice...)
Do you think it might be useful to have Regular Expressions in COBOL? (Or
might it have been...?)
Pete.
| |
| Richard Brady 2007-06-18, 9:56 pm |
| Rick Smith wrote:
[snip]
> I reviewed the thread and found that your comments about
> regular expressions were hardly separable from C#, including
> your using Microsoft's perversion of the ISO standard for
> regular expressions. But, maybe I have some bias. <G>
>
> -----
> $set ans85 flag"ans85" flagas"s"
> identification division.
> program-id. emailadr.
> *
> * Demonstration program to validate email addresses;
> * but does not necessarily recognize all valid
> * email addresses.
> *
> * In particular, it demonstrates the use of class
> * conditions to validate the character content of fields.
> *
> environment division.
> configuration section.
> special-names.
> alphabet email is standard-1
> class local-chars is "A" thru "Z" "a" thru "z"
> "0" thru "9" "_" "%" "-"
> * domain-chars also used for server
> class domain-chars is "A" thru "Z" "a" thru "z"
> "0" thru "9" "-"
> * domain-type-chars also used for country
> class domain-type-chars is "A" thru "Z" "a" thru "z"
> .
> data division.
> working-storage section.
> 77 current-position binary pic 9(4) value 1.
> 01 work-area.
> 02 work-status binary pic s9(4) value +0.
> 02 local-count binary pic 9(4) value 0.
> 02 local-delimiter pic x value space.
> 02 local-part pic x(31) value space.
> 02 domain-part-count binary pic 9(4) value 0.
> 02 domain-count-1 binary pic 9(4) value 0.
> 02 domain-delimiter-1 pic x value space.
> 02 domain-part-1 pic x(31) value space.
> 02 domain-count-2 binary pic 9(4) value 0.
> 02 domain-delimiter-2 pic x value space.
> 02 domain-part-2 pic x(31) value space.
> 02 domain-count-3 binary pic 9(4) value 0.
> 02 domain-delimiter-3 pic x value space.
> 02 domain-part-3 pic x(31) value space.
> 02 domain-count-4 binary pic 9(4) value 0.
> 02 domain-delimiter-4 pic x value space.
> 02 domain-part-4 pic x(31) value space.
> linkage section.
> 01 email-address pic x(256).
> 01 validation-status binary pic s9(4).
> procedure division
> using email-address validation-status.
> begin.
> initialize work-area
> move 1 to current-position
> unstring email-address
> delimited by "@" or all space
> into local-part
> delimiter in local-delimiter
> count in local-count
> with pointer current-position
> on overflow
> if local-delimiter = "@"
> if local-part (1:local-count) is local-chars
> perform get-domain-part
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> not on overflow
> move -1 to work-status
> end-unstring
> move work-status to validation-status
> exit program
> .
> end-of-program.
> stop run
> .
>
> get-domain-part.
> unstring email-address
> delimited by "." or all space
> into domain-part-1
> delimiter in domain-delimiter-1
> count in domain-count-1
> domain-part-2
> delimiter in domain-delimiter-2
> count in domain-count-2
> domain-part-3
> delimiter in domain-delimiter-3
> count in domain-count-3
> domain-part-4
> delimiter in domain-delimiter-4
> count in domain-count-4
> with pointer current-position
> tallying domain-part-count
> end-unstring
> evaluate domain-part-count
> when 2
> * domain.type
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 >= 2 and <= 4
> and domain-part-2 (1:domain-count-2)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> when 3
> * domain.type.country or
> * server.domain.type
> perform try-domain-type-country
> if work-status not = 0
> move 0 to work-status
> perform try-server-domain-type
> end-if
> when 4
> * server.domain.type.country
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 > 0
> and domain-part-2 (1:domain-count-2)
> is domain-chars
> if domain-count-3 >= 2 and <= 4
> and domain-part-3 (1:domain-count-3)
> is domain-type-chars
> if domain-count-4 = 2
> and domain-part-4 (1:domain-count-4)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> when other
> move -1 to work-status
> end-evaluate
> .
> try-domain-type-country.
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 >=2 and <=4
> and domain-part-2 (1:domain-count-2)
> is domain-chars
> if domain-count-3 = 2
> and domain-part-3 (1:domain-count-3)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> .
> try-server-domain-type.
> if domain-count-1 > 0
> and domain-part-1 (1:domain-count-1)
> is domain-chars
> if domain-count-2 > 0
> and domain-part-2 (1:domain-count-2)
> is domain-chars
> if domain-count-3 >= 2 and <= 4
> and domain-part-3 (1:domain-count-3)
> is domain-type-chars
> continue
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> else
> move -1 to work-status
> end-if
> .
> end program emailadr.
> -----
Thank you Rick. Did you get any sleep afterwards?
Yet another Richard
| |
| Rick Smith 2007-06-18, 9:56 pm |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:137cjk4fgjh1hef@corp.supernews.com...
[snip]
[snip][color=darkred]
> -----
[snip]
> if local-part (1:local-count) is local-chars
should be:
if local-count > 0
and local-part (1:local-count) is local-chars
[snip]
> unstring email-address ...
[snip]
> end-unstring
> evaluate domain-part-count
[snip]
should be:
not on overflow
perform evaluate-domain-parts
on overflow
move -1 to work-status
end-unstring
| |
| Rick Smith 2007-06-19, 7:55 am |
|
"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
news:sYwdi.183576$p47.7075@bgtnsc04-news.ops.worldnet.att.net...
[snip]
>
> Thank you Rick. Did you get any sleep afterwards?
Yes, after a mental review of the code revealed
a couple errors, I slept for a few hours.
| |
| Rick Smith 2007-06-19, 7:55 am |
|
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:137dlqqnasl8m3e@corp.supernews.com...
[snip]
> should be:
> not on overflow
> perform evaluate-domain-parts
> on overflow
> move -1 to work-status
> end-unstring
There seems to be a peculiarity in COBOL 85 that
was removed in COBOL 2002. For COBOL 85,
the 'on overflow' condition must occur before the
'not on overflow' condition. The above should
actually be:
on overflow
move -1 to work-status
not on overflow
perform evaluate-domain-parts
My apologies.
| |
| Charles Hottel 2007-06-19, 7:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dna71F35l0l3U1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:137cjk4fgjh1hef@corp.supernews.com...
> (OK, the following is serious and I promise I am not being mischievous...)
>
> If you mean me, I plead "not guilty".
>
> (I'm "guilty" of mentioning C#, certainly, but only in the context of
> alternatives to COBOL. Why should we consider alternatives to COBOL? See
> below...)
>
> I have no vested interest in this and am not on commission to anyone.
>
> What possible gain is there for me in persuading people away from COBOL?
> None, whatsoever. But then, I don't have to; they are voting with their
> feet...
>
> I see a trend. I try to understand why it is a trend, and I find a
> paradigm shift is occurring that will leave COBOL out in the cold, within
> a few years. As always, I call them like I see them.
>
> What can be done about it? Many people here (like myself) have a huge
> investment in COBOL, accrued over many years. So any alternative needs to
> consider that investment. That's how I arrived at C#. It offers great
> Interoperability and that was what first attracted me to it. I needed a
> DotNET solution and I couldn't get a COBOL one. C# offered easy entry into
> DotNET with no loss of COBOL assets, and a MUCH more productive IDE than I
> had ever had (on PC or mainframe) previously.
>
> End of story.
>
> I know COBOL will be around for some time yet and I'm glad about that. But
> I also know it won't be indefinite or even for the foreseeable future.
>
> I have had a history here of promoting unpopular viewpoints.
>
> 1. I recommended RDBs when everyone said there was nothing wrong with
> ISAM.
>
> 2. I tried very hard (and, generally, failed dismally :-)) to encourage
> people to look at OO and maybe learn Java or extend their COBOL skillsets.
>
> 3. I brought the message about components here. (24000 people read an
> article I wrote on it, the link to which was ONLY published here.)
>
> 4. Now I'm saying COBOL has a limited life and it's time to look at
> alternatives.
>
> Does any of that sound irresponsible or wrong? (It may be debatable,
> certainly, but these are viewpoints I hold.)
>
> So many times I've debated these issues here and been beat up and abused.
> But sometimes, something I say strikes a chord with someone and they go
> and do it. And at least I know I tried... :-)
>
> Outside of this forum what is the world doing?
>
> Using OO, accessing RDBs, gluing components together, implementing
> component based designs, and considering new ways of doing things. Ways
> that are unknown to COBOL people generally. Genetic algorithms, Regular
> expressions, Lambda functions, heuristic programming... Should these
> subjects be taboo because COBOL does not support them?
>
> I don't think so, and there's no way you can shut me up :-) (Thank God for
> free speech and unmoderated Usenet forums...:-))
>
> If you don't like what I say here, put me on your kill list (Usenet
> please, not in the real world :-)), simply don't read or respond to my
> mail, or make your case against it, but don't ascribe ulterior motives to
> me or accuse me of doing things I'm not.
>
> I am nothing if not up front and honest in my positions. Yes, I like C#
> (it has grown on me since I started using it), but I also like COBOL and
> Java. Yes, I think the lifetime for COBOL is limited, but I am certainly
> not alone in that. I'd like to see people here preparing for the end of it
> and, to that extent, I may suggest other alternatives, and document my
> experience in moving away from it. Some people find that helpful. Others,
> take it as a personal attack on COBOL; it isn't.
>
> Finally, I DIDN'T post the C# code until someone asked me to
>
> </end of very strong serious statement>
>
> Now, back to Regular expressions... :-)
>
>
> Well, full credit for coding it anyway, Rick.
>
> I think we both have :-) Nevertheless, I respect your posts here and have
> always done so.
>
> My background for RegExs is certainly a MicroSoft one so I have been
> exposed to their examples. I'm not as sensitive about standards as you
> are. But we won't go there...:-) suffice to say, if something works (and
> saves me time), but violates a "standard" (which may be non-existent
> outside the paper it is written on), I'll bend the standard every time. I
> don't consider this perverted, or even perverse; I consider it pragmatic.
>
> Well, I think that's a work of art :-).
>
> Good job.
>
> I s'pose it isn't fair to mention at this point that the C# solution did
> it with one line of code? :-) OK, I won't mention that...besides, it
> used a perverted MS implementation.... :-)
>
> This is a perfect example of why procedural coding cannot continue. It
> simply costs too much to write code line by line and have thousands of
> lines of it. Fortunately, in the 21st century, we don't have to (unlike
> the latter half of the 20th century where there really wasn't much
> choice...)
>
> Do you think it might be useful to have Regular Expressions in COBOL? (Or
> might it have been...?)
>
> Pete.
>
We don't need no stink'in API library in COBOL :-)
| |
| Pete Dashwood 2007-06-19, 7:55 am |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:u_Edi.5707$tb6.36@newsread3.news.pas.earthlink.net...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dna71F35l0l3U1@mid.individual.net...
>
> We don't need no stink'in API library in COBOL :-)
Thanks Charlie. I take it you're speaking on behalf of the badgers... as in
...."We don't need no stinkin' badgers..." right :-)
Pete.
| |
| Charles Hottel 2007-06-19, 9:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dpqhhF2vbvj2U1@mid.individual.net...
>
> "Charles Hottel" <chottel@earthlink.net> wrote in message
> news:u_Edi.5707$tb6.36@newsread3.news.pas.earthlink.net...
>
> Thanks Charlie. I take it you're speaking on behalf of the badgers... as
> in ..."We don't need no stinkin' badgers..." right :-)
>
> Pete.
>
>
Yep.
I once suggest here that COBOL could use and API library but most "old
hands" were not receptive. It does take time to learn an API but if it is a
good one that you will use often it is time well spent. Saves always
reinventing the wheel and reduces the chance of getting it wrong. Good
documentation such as can be produced by JavaDoc is essential.
| |
| Pete Dashwood 2007-06-20, 3:55 am |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:GQZdi.6035$tb6.5260@newsread3.news.pas.earthlink.net...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dpqhhF2vbvj2U1@mid.individual.net...
>
> Yep.
>
> I once suggest here that COBOL could use and API library but most "old
> hands" were not receptive. It does take time to learn an API but if it is
> a good one that you will use often it is time well spent. Saves always
> reinventing the wheel and reduces the chance of getting it wrong. Good
> documentation such as can be produced by JavaDoc is essential.
>
You're gonna LOVE DotNET /Mono ... :-)
Pete.
| |
| Howard Brazee 2007-06-20, 9:55 pm |
| Do you realize that there were over 400 lines in your message, all but
5 of them were quoted? I wonder how many people scrolled down even
one page, much less all the pages of old text in order to see what
wisdom you had to add to the thread.
Some of us have work to do - when we have a break, we browse
comp.lang.cobol for useful information. Our newsreaders allow us to
back track through threads when that is useful, but mostly we are
reading the new reply to a thread - if it isn't too much work.
If people want their messages to be read, please think of your
prospective audience. Consider how they are likely to be browsing
through the messages.
| |
| Pete Dashwood 2007-06-20, 9:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:hmei73p1rnsp3irbgeg9puel87fi2oncdo@
4ax.com...
> Do you realize that there were over 400 lines in your message, all but
> 5 of them were quoted? I wonder how many people scrolled down even
> one page, much less all the pages of old text in order to see what
> wisdom you had to add to the thread.
>
> Some of us have work to do - when we have a break, we browse
> comp.lang.cobol for useful information. Our newsreaders allow us to
> back track through threads when that is useful, but mostly we are
> reading the new reply to a thread - if it isn't too much work.
>
> If people want their messages to be read, please think of your
> prospective audience. Consider how they are likely to be browsing
> through the messages.
Fair comment. I am guilty of this too. The trouble is that you don't always
know what people have already read and what they haven't. And the mode of
reading you describe is only one possibility, Howard. Not everyone here
reads CLC hurriedly at work, or accesses it to gain useful information.
(I read it as a BREAK from work, and for the entertainment value more than
useful information, although when that happens, it is a bonus.:-))
Nevertheless, I'll keep the scissors in mind in future...
Pete.
| |
| Rick Smith 2007-06-20, 9:55 pm |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:GQZdi.6035$tb6.5260@newsread3.news.pas.earthlink.net...
[snip]
> I once suggest here that COBOL could use and API library but most "old
> hands" were not receptive. It does take time to learn an API but if it is
a
> good one that you will use often it is time well spent. Saves always
> reinventing the wheel and reduces the chance of getting it wrong.
This capability was added to COBOL 2002 through the
the repository, program prototypes, new data types, etc.
Such libraries need not be specific to COBOL; but the
implementor must provide the means for interfacing to
the languages in which the libraries are written.
| |
| Howard Brazee 2007-06-21, 9:55 pm |
| On Thu, 21 Jun 2007 11:30:27 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>Fair comment. I am guilty of this too. The trouble is that you don't always
>know what people have already read and what they haven't. And the mode of
>reading you describe is only one possibility, Howard. Not everyone here
>reads CLC hurriedly at work, or accesses it to gain useful information.
How do people access these messages where they cannot access a
previous message?
Reading for useful information, or reading for chuckles or reading for
anything at all - do people enjoy scrolling down 400+ lines to see
that the latest addition is? We tend to be lazy in our
entertainment as well as our work - especially if we need to return to
work in a minute, and want to get to the punch line.
>(I read it as a BREAK from work, and for the entertainment value more than
>useful information, although when that happens, it is a bonus.:-))
That too.
| |
| Pete Dashwood 2007-06-21, 9:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:rj4l7350qdqp1tfue0khiicae7239dt6v8@
4ax.com...
> On Thu, 21 Jun 2007 11:30:27 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> How do people access these messages where they cannot access a
> previous message?
>
You answered this in the paragraph below; we are lazy. We don't want to open
a previous message and interrupt the flow of what we are reading, and then
find that the previous message requires us to back up the thread also. It is
quicker to simply scroll the current message.
<snipped unreferenced previous :-) >
Pete.
| |
| William M. Klein 2007-06-24, 6:55 pm |
| Alternatively, (annoy some people) and TOP post what's "new" in your message.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:hmei73p1rnsp3irbgeg9puel87fi2oncdo@
4ax.com...
> Do you realize that there were over 400 lines in your message, all but
> 5 of them were quoted? I wonder how many people scrolled down even
> one page, much less all the pages of old text in order to see what
> wisdom you had to add to the thread.
>
> Some of us have work to do - when we have a break, we browse
> comp.lang.cobol for useful information. Our newsreaders allow us to
> back track through threads when that is useful, but mostly we are
> reading the new reply to a thread - if it isn't too much work.
>
> If people want their messages to be read, please think of your
> prospective audience. Consider how they are likely to be browsing
> through the messages.
| |
|
|
|
|
|
|
|