Use of Class conditions in COBOL (was: Re: for a laught (???)_
Rick Smith
"Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
news:5dm9m3F...@mid.individual.net...
>
> "Rick Smith" <rick...@mfi.net> wrote in message
> news:137bqa9...@corp.supernews.com...
> >
> > "Richard Brady" <rrllb...@worrlldnet.att.net> wrote in message
> > news:YRedi.95547$Sa4....@bgtnsc05-news.ops.worldnet.att.net...
> >> Pete Dashwood wrote:
> >> [snip]
> >> >
> >> > I'd post the code but no-one here is interested.
> >>
> >> Not quite true, Mr. Dashwood. At least one is interested.
> >
> > You do realize that this is a COBOL newsgroup and the
> > code is written in C#?
>
> 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>
> >> > We covered regular
> >> > expressions about a year ago and it stimulated no responses.
> >>
> >> Stunned, perhaps? Unable to grasp the elegance? I perceive that a
> >> COBOL programmer would try to determine how to accomplish the results
in
> >> COBOL (at least I would) and be overwhelmed.
> >
> > Given the regular expression:
> > [A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}
> > this translates to a couple UNSTRING statements to
> > break the e-mail address into some substrings, some
> > class tests to validate the content of thsoe substrings, and
> > a few tests to catch other errors.
>
> 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.]
> > This is hardly overwhelming though it does take more than
> > one line, unless one is using COBOL on a POSIX-conforming
> > OS, in which case one should be able to call 'regcomp' with
> > the regular expression.
>
> 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 C# required!
>
> 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"
.
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.
-----
Pete Dashwood
>
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> wrote in message
> news:5dm9m3F...@mid.individual.net...
>>
>> "Rick Smith" <rick...@mfi.net> wrote in message
>> news:137bqa9...@corp.supernews.com...
>> >
>> > "Richard Brady" <rrllb...@worrlldnet.att.net> wrote in message
>> > news:YRedi.95547$Sa4....@bgtnsc05-news.ops.worldnet.att.net...
>> >> Pete Dashwood wrote:
>> >> [snip]
>> >> >
>> >> > I'd post the code but no-one here is interested.
>> >>
>> >> Not quite true, Mr. Dashwood. At least one is interested.
>> >
>> > You do realize that this is a COBOL newsgroup and the
>> > code is written in C#?
>>
>> 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>
>
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... :-)
>> >> > We covered regular
>> >> > expressions about a year ago and it stimulated no responses.
>> >>
>> >> Stunned, perhaps? Unable to grasp the elegance? I perceive that a
>> >> COBOL programmer would try to determine how to accomplish the results
> in
>> >> COBOL (at least I would) and be overwhelmed.
>> >
>> > Given the regular expression:
>> > [A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}
>> > this translates to a couple UNSTRING statements to
>> > break the e-mail address into some substrings, some
>> > class tests to validate the content of thsoe substrings, and
>> > a few tests to catch other errors.
>>
>> 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.]
Well, full credit for coding it anyway, Rick.
>
>> > This is hardly overwhelming though it does take more than
>> > one line, unless one is using COBOL on a POSIX-conforming
>> > OS, in which case one should be able to call 'regcomp' with
>> > the regular expression.
>>
>> 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 C# required!
>>
>> 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>
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.
Richard Brady
[snip]
Thank you Rick. Did you get any sleep afterwards?
Yet another Richard
Richard Brady
black-and-white televisions or typewriters: very useful in their day.
They were a necessary first step, creating a market and showing what
could be done. They were valuable stepping stones.
But they also showed us what we lack. We have developed new computing
paradigms while using COBOL, PL/I, Fortran, Algol and do on. Those
paradigms arose from the shortcomings of COBOL, PL/I, etc. even as HD tv
arose from the shortcomings of color and B&W tv.
The bad news is that COBOL was the lingua-franca of computers and now we
have the tower of Babel. C# is great, unless we work on a platform
without Micro$haft Windows. Then maybe Java is the ticket or ?
The good news is that we COBOL programmers may be needed for sometime to
come, maintaining the wrapped code and translating COBOL to languages
that support modern computing paradigms. For the latter, we may need to
think in multiple languages and paradigms to be employable. Since we
are no longer training COBOL programmers, the day will come when the
last COBOL programmer retires and the employers of the world will want
all their wrapped COBOL replaced. Just as all of our B&W tvs are gone.
Thank you Mr. Dashwood.
Yet another Richard
Rick Smith
[snip]
> > > [A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}
> > > this translates to a couple UNSTRING statements to
> > > break the e-mail address into some substrings, some
> > > class tests to validate the content of thsoe substrings, and
> > > a few tests to catch other errors.
> -----
[snip]
> if local-part (1:local-count) is local-chars
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
evaluate-domain-parts.
evaluate domain-part-count
> -----
The first handles a zero-length 'local-name'.
The second rejects a bad address for more than four
parts.
Note that the regular expression, above, will find most
valid e-mail addresses; but it may also find some strings
that are not valid addresses. The COBOL code tries
to eliminate those strings that are not valid addresses.
Rick Smith
[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
[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
We don't need no stink'in API library in COBOL :-)
Pete Dashwood
"Charles Hottel" <cho...@earthlink.net> wrote in message
news:u_Edi.5707$tb6...@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.
Charles Hottel
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
Pete.
Howard Brazee
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
"Howard Brazee" <how...@brazee.net> wrote in message
news:hmei73p1rnsp3irbg...@4ax.com...
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
[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
<dash...@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
> On Thu, 21 Jun 2007 11:30:27 +1200, "Pete Dashwood"
> <dash...@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?
>
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
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <how...@brazee.net> wrote in message
news:hmei73p1rnsp3irbg...@4ax.com...