Cobol - Regular Expressions and Standard COBOL (was Re: Use of Class conditions in COBOL)

Author

Regular Expressions and Standard COBOL (was Re: Use of Class conditions in COBOL)

Rick Smith

2007-07-04, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5dna71F35l0l3U1@mid.individual.net...
>
[snip]
> Do you think it might be useful to have Regular Expressions in COBOL?
> [...]

I think it is useful to have Regular Expressions
available to COBOL programs; but there are
reasons why such common REs should not be
made part of the COBOL language standard.

Regular Expressions "grew up" in C and used the
older C character set (ASCII) as a means for
specifying the REs. When C went through ISO
standardization, it adopted ISO 646 for its
character set. In most cases, there is no difference.
In a few cases, for some countries, some of the
standard C graphic characters are replaced with
national characters. To accommodate these
replacements, the C standard specifies certain
"trigraph" sequences (from the ISO 646-1083
Invariant Code Set) to replace the missing characters.
This is the first problem. To include REs, as commonly
used, would require expansion of the COBOL Basic
character set to include the missing characters and
the introduction of "trigraphs".

At least one character, the circumflex ("^") is not
defined for EBCDIC (according to my "Yellow
Card" (Second Edition (September 1972)) and
other sources). The circumflex apparently maps
to the logical not ("¬"). The second, perhaps not
so big, problem is the variations that occur with
different vendors' character sets.

The POSIX definition of REs is, apparently (I am
relaying on statements about "lex" which uses REs
and certain comments about how POSIX 2 affects
portability of those REs), somewhat different than
what is commonly presented. Certain common patterns
now have specific names in order to accommodate
portability across platforms and locales. These
names were adopted from ISO C. Some examples
are: [A-Z] is [:upper:], [a-z] is [:lower:], [A-Za-z] is
[:alpha:], [0-9] is [:digit:], and [A-Za-z0-9] is
[:alnum:]. The keywords "upper", "lower", etc. also
include any locale specific upper- and lower-case
letters. This is the third problem: The inclusion of
commonly used REs in standard COBOL would
probably require conformance to the POSIX
standard and, from what I've seen, there seems to
be little desire to conform to that standard; but that
might be because I see REs written by those who
use English and may not be concerned with other
languages.

The processing of REs, having developed using
delimited strings, would require the use of ANY
LENGTH items in COBOL (200x with PREFIXED
or DELIMITED phases). While I have not looked
at ANY LENGTH, at length, there are some
complaints that it is defective (or, at least has
problems). This the fourth problem, potentially.
Whatever problems exist with ANY LENGTH must
be resolved before REs could be added to COBOL.

I have only scratched the surface; but, like the scratch-
'n-sniff ads in magazines, I don't care for the odor!
If I want to write C instead of COBOL, I will write
C instead of COBOL!

I think a better way might be to input a RE to a code
generator, which would create a COBOL program
to process the RE.

Pete Dashwood

2007-07-05, 3:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:138nprdpf6ucu82@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5dna71F35l0l3U1@mid.individual.net...
> [snip]
>
> I think it is useful to have Regular Expressions
> available to COBOL programs; but there are
> reasons why such common REs should not be
> made part of the COBOL language standard.
>
> Regular Expressions "grew up" in C and used the
> older C character set (ASCII) as a means for
> specifying the REs. When C went through ISO
> standardization, it adopted ISO 646 for its
> character set. In most cases, there is no difference.
> In a few cases, for some countries, some of the
> standard C graphic characters are replaced with
> national characters. To accommodate these
> replacements, the C standard specifies certain
> "trigraph" sequences (from the ISO 646-1083
> Invariant Code Set) to replace the missing characters.
> This is the first problem. To include REs, as commonly
> used, would require expansion of the COBOL Basic
> character set to include the missing characters and
> the introduction of "trigraphs".
>
> At least one character, the circumflex ("^") is not
> defined for EBCDIC (according to my "Yellow
> Card" (Second Edition (September 1972)) and
> other sources). The circumflex apparently maps
> to the logical not ("¬"). The second, perhaps not
> so big, problem is the variations that occur with
> different vendors' character sets.
>
> The POSIX definition of REs is, apparently (I am
> relaying on statements about "lex" which uses REs
> and certain comments about how POSIX 2 affects
> portability of those REs), somewhat different than
> what is commonly presented. Certain common patterns
> now have specific names in order to accommodate
> portability across platforms and locales. These
> names were adopted from ISO C. Some examples
> are: [A-Z] is [:upper:], [a-z] is [:lower:], [A-Za-z] is
> [:alpha:], [0-9] is [:digit:], and [A-Za-z0-9] is
> [:alnum:]. The keywords "upper", "lower", etc. also
> include any locale specific upper- and lower-case
> letters. This is the third problem: The inclusion of
> commonly used REs in standard COBOL would
> probably require conformance to the POSIX
> standard and, from what I've seen, there seems to
> be little desire to conform to that standard; but that
> might be because I see REs written by those who
> use English and may not be concerned with other
> languages.
>
> The processing of REs, having developed using
> delimited strings, would require the use of ANY
> LENGTH items in COBOL (200x with PREFIXED
> or DELIMITED phases). While I have not looked
> at ANY LENGTH, at length, there are some
> complaints that it is defective (or, at least has
> problems). This the fourth problem, potentially.
> Whatever problems exist with ANY LENGTH must
> be resolved before REs could be added to COBOL.
>
> I have only scratched the surface; but, like the scratch-
> 'n-sniff ads in magazines, I don't care for the odor!
> If I want to write C instead of COBOL, I will write
> C instead of COBOL!
>
> I think a better way might be to input a RE to a code
> generator, which would create a COBOL program
> to process the RE.
>

I disagree :-). (But I really don't care, so don't expect a passionate
debate about this... :-))

I'm using REs in an environment where they work properly so I don't have any
of the problems you mentioned. In fact I can process Unicode strings with
REs if I want. AND I can do it from COBOL.

(Of course, I use MicroSoft, but, strangely as some might expect, I have not
broken out in warts all over my body, been invited to midnight orgies in
worship of Bill Gates, or been required to sacrifice any children so my code
will work. It just does...)

To input REs to a preprocessor that then "creates a COBOL program to process
the RE" is certainly a POSSIBLE solution, but very unwieldy, and, in most
cases where you would want to use a Regular Expression, not worth the
effort.

Given that there are numerous RE components available, and some of these are
in formats that can be called from COBOL, I see it as being the same problem
which some people perceive COBOL to have with processing XML. (I've been
processing XML from COBOL for years now, using the standard components that
come with my Operating System (because they are free). If I want the code to
run on a different Operating System it would be a matter of moments to plug
in a third party component (assuming there isn't one in the new environment)
and away we go... Processing XML has never been a problem for COBOL or
anything else; the functionality to do it has been encapsulated long ago and
is freely available.

(However, a pointless exercise is now being embarked on to add that to the
language as well. It's almost as if "Not invented by us...therefore
worthless" is the motto of the people responsible for what facilities COBOL
offers.)

So instead, huge amounts of effort, time, and (to a lesser extent) money,
are expended to re-invent the wheel, solve problems that were already solved
in ancient time, come up with a better mousetrap, when there aren't any
mice...

I see REs as being exactly in this category.

But then, rather than scratching and sniffing problems, I tend to first
decide whether there is an existing solution that doesn't require me to
break the seal.

I see two such solutions here:

1. Call a component that does it.

2. Let your vendor provide a runtime component that does it (maybe
HE can call an existing one for you...)

COBOL verbs are really an interface to tell the compiler writer which
components need to be in the runtime.

Yet the assumption is made in certain quarters that Native Code or
intermediate code will be generated from every verb coded by the programmer.

Vendors (usually...and I am talking about the "good" ones :-)) don't
generate all the machine code every time you write READ; they access a
runtime component. The interface is consistent and common. They do the same
when you use SEARCH, or UNSTRING, or CLASS tests like ALPHANUMERIC...

Vendors could simply add RE and XML components to their runtimes. (It could
be implementor defined, just as so many other things are...) (Then it would
be a simple matter to decide whether you will CALL a component yourself or
whether you will use the one provided...)

Simple constructs could be added to the language to define an interface to
RE and XML components, included by the vendor in the runtime. It is no more
difficult than defining access to data or driving a screen section. (It IS
more difficult if you expect the wheel to be reinvented every time someone
codes it...)

"All ya gotta do" is...:-)

01 match-string pic x(whatever) usage is REGULAR-EXPRESSION. *> Allows the
compiler writer to know that some

*> possibly invalid (for COBOL) characters
may be

*> found in this location, and also to syntax
check

*> the RE in accordance with what he has
implemented.
01 data-to-be-parsed pic x(whatever). *> if this area gets expanded by the
RE process, it will be truncated in
*> accordance
with the standard COBOL rules for ALPHANUMERIC
*> MOVE
truncation. (Programmers pad the size if they think it is likely
*> to expand. NO
requirement for ANY-LENGTH at all.)
01 RE-result pic x value space.
88 RE-matched value '1'.
88 RE-unmatched value '0'.

....

SPEC:

"A string must contain one, and only one "@" symbol. There can be any number
of alphanumeric characters preceding the "@", but there MUST be at least
one. Other characters can be ignored. (There can be dots, for example).
Succeeding the "@" symbol there must be at least one alphanumeric symbol
preceding one or more dots. A dot cannot be the final symbol in the string
and must always be "surrounded" by at least one alphanumeric character on
either side of it."

(Assuming my compiler vendor is "MicroSoft friendly"... (both Fujitsu and
MicroFocus are MS partners))

*> check email address
move "(\\w+)@(\\w+)\\.(\\w+)" to match-string *> the rules for
what would be acceptable here

*> would be in the vendor's COBOL manual.

*> I have used the MS shorthand for [A-Za-z0-9]
move email-address to data-to-be-parsed
move zero to myTally
inspect email-address
tallying myTally
for ALL "@"
if myTally = 1
REGEX
MATCH data-to-be-parsed
USING match-string
RETURNING RE-result
ON OVERFLOW perform internal-error *> the result overflowed
the data-to-be-parsed buffer.

*> (Impossible in the case of MATCH)
END-REGEX
if RE-unmatched
move 2 to MyTally
end-if
end-if
if myTally NOT = 1
... process as invalid email address
end-if
*> address appears to be valid...

Nah, too easy...(still, a lot less effort than writing a couple of hundred
lines of COBOL)

Pete.

Rick Smith

2007-07-05, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5f3anoF38l4hvU1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:138nprdpf6ucu82@corp.supernews.com...
>
> I disagree :-). (But I really don't care, so don't expect a passionate
> debate about this... :-))
>
> I'm using REs in an environment where they work properly so I don't have
any
> of the problems you mentioned. In fact I can process Unicode strings with
> REs if I want. AND I can do it from COBOL.
>
> (Of course, I use MicroSoft, but, strangely as some might expect, I have
not
> broken out in warts all over my body, been invited to midnight orgies in
> worship of Bill Gates, or been required to sacrifice any children so my
code
> will work. It just does...)
>
> To input REs to a preprocessor that then "creates a COBOL program to
process
> the RE" is certainly a POSSIBLE solution, but very unwieldy, and, in most
> cases where you would want to use a Regular Expression, not worth the
> effort.
>
> Given that there are numerous RE components available, and some of these
are
> in formats that can be called from COBOL, I see it as being the same
problem
> which some people perceive COBOL to have with processing XML. (I've been
> processing XML from COBOL for years now, using the standard components
that
> come with my Operating System (because they are free). If I want the code
to
> run on a different Operating System it would be a matter of moments to
plug
> in a third party component (assuming there isn't one in the new
environment)
> and away we go... Processing XML has never been a problem for COBOL or
> anything else; the functionality to do it has been encapsulated long ago
and
> is freely available.
>
> (However, a pointless exercise is now being embarked on to add that to the
> language as well. It's almost as if "Not invented by us...therefore
> worthless" is the motto of the people responsible for what facilities
COBOL
> offers.)
>
> So instead, huge amounts of effort, time, and (to a lesser extent) money,
> are expended to re-invent the wheel, solve problems that were already
solved
> in ancient time, come up with a better mousetrap, when there aren't any
> mice...
>
> I see REs as being exactly in this category.
>
> But then, rather than scratching and sniffing problems, I tend to first
> decide whether there is an existing solution that doesn't require me to
> break the seal.
>
> I see two such solutions here:
>
> 1. Call a component that does it.
>
> 2. Let your vendor provide a runtime component that does it (maybe
> HE can call an existing one for you...)
>
> COBOL verbs are really an interface to tell the compiler writer which
> components need to be in the runtime.
>
> Yet the assumption is made in certain quarters that Native Code or
> intermediate code will be generated from every verb coded by the
programmer.
>
> Vendors (usually...and I am talking about the "good" ones :-)) don't
> generate all the machine code every time you write READ; they access a
> runtime component. The interface is consistent and common. They do the
same
> when you use SEARCH, or UNSTRING, or CLASS tests like ALPHANUMERIC...
>
> Vendors could simply add RE and XML components to their runtimes. (It
could
> be implementor defined, just as so many other things are...) (Then it
would
> be a simple matter to decide whether you will CALL a component yourself or
> whether you will use the one provided...)
>
> Simple constructs could be added to the language to define an interface to
> RE and XML components, included by the vendor in the runtime. It is no
more
> difficult than defining access to data or driving a screen section. (It IS
> more difficult if you expect the wheel to be reinvented every time someone
> codes it...)
>
> "All ya gotta do" is...:-)
>
> 01 match-string pic x(whatever) usage is REGULAR-EXPRESSION. *> Allows the
> compiler writer to know that some
>
> *> possibly invalid (for COBOL) characters
> may be
>
> *> found in this location, and also to
syntax
> check
>
> *> the RE in accordance with what he has
> implemented.
> 01 data-to-be-parsed pic x(whatever). *> if this area gets expanded by the
> RE process, it will be truncated in
> *> accordance
> with the standard COBOL rules for ALPHANUMERIC
> *> MOVE
> truncation. (Programmers pad the size if they think it is likely
> *> to expand.
NO
> requirement for ANY-LENGTH at all.)
> 01 RE-result pic x value space.
> 88 RE-matched value '1'.
> 88 RE-unmatched value '0'.
>
> ...
>
> SPEC:
>
> "A string must contain one, and only one "@" symbol. There can be any
number
> of alphanumeric characters preceding the "@", but there MUST be at least
> one. Other characters can be ignored. (There can be dots, for example).
> Succeeding the "@" symbol there must be at least one alphanumeric symbol
> preceding one or more dots. A dot cannot be the final symbol in the string
> and must always be "surrounded" by at least one alphanumeric character on
> either side of it."
>
> (Assuming my compiler vendor is "MicroSoft friendly"... (both Fujitsu and
> MicroFocus are MS partners))
>
>
> *> check email address
> move "(\\w+)@(\\w+)\\.(\\w+)" to match-string *> the rules for
> what would be acceptable here
>
> *> would be in the vendor's COBOL manual.
>
> *> I have used the MS shorthand for [A-Za-z0-9]
> move email-address to data-to-be-parsed
> move zero to myTally
> inspect email-address
> tallying myTally
> for ALL "@"
> if myTally = 1
> REGEX
> MATCH data-to-be-parsed
> USING match-string
> RETURNING RE-result
> ON OVERFLOW perform internal-error *> the result overflowed
> the data-to-be-parsed buffer.
>
> *> (Impossible in the case of MATCH)
> END-REGEX
> if RE-unmatched
> move 2 to MyTally
> end-if
> end-if
> if myTally NOT = 1
> ... process as invalid email address
> end-if
> *> address appears to be valid...
>
> Nah, too easy...(still, a lot less effort than writing a couple of hundred
> lines of COBOL)

First, let's deal with the regular expression: "(\\w+)@(\\w+)\\.(\\w+)".
This is actually quite "lame" for validating e-mail addresses.
I did some digging at < www.microsoft.com > to get a better
understanding of Microsoft's "perversion" of regular expressions
and found the following:

< http://msdn2.microsoft.com/en-us/library/aa332116(VS.71).aspx >
-----
..NET Framework Class Library
Regex.IsMatch Method (String, String)
Indicates whether the regular expression finds a match in the
input string using the regular expression specified in the
pattern parameter.

[C#]
public static bool IsMatch(
string input,
string pattern
);

Parameters

input
The string to search for a match.

pattern
The regular expression pattern to match.

Return Value
true if the regular expression finds a match; otherwise, false.
-----

And
< http://msdn2.microsoft.com/en-us/library/1400241x.aspx >
-----
\w
Matches any word character including underscore. Equivalent
to '[A-Za-z0-9_]'.
-----

The IsMatch method will find whether the pattern exists
anywhere in the string. "(\\w+)@(\\w+)\\.(\\w+)" means letters,
numbers, or underscores; followed by "@"; followed by more
letters, numbers, or underscores; followed by a dot (".");
followed by even more letters, numbers, or underscores will
match without regard to the position of the pattern in the string.

This means that IsMatch will return true (valid e-mail address)
when these strings are tested with the given regular expression.:

"The quick brown fox@henhouse.net jumped over" and
"Apples 5lbs@1.29 per pound - On sale"

Clearly these complete strings are not valid e-mail addresses;
only the matched portion may be.

Microsoft provides an example, which I have modified.

< http://msdn2.microsoft.com/en-us/library/aa720056(VS.71).aspx >
-----
..NET Framework Developer's Guide
Example: Confirming Valid E-Mail Format
The following code example uses the static Regex.IsMatch
method to verify that a string is in valid e-mail format. The
IsValidEmail method returns true if the string contains a valid
e-mail address and false if it does not, but takes no other action.
You can use IsValidEmail to filter out e-mail addresses
containing invalid characters before your application stores the
addresses in a database or displays them in an ASP.NET page.

....

[C#]bool IsValidEmail(string strIn)
{
// Return true if strIn is in valid e-mail format.
return Regex.IsMatch(strIn,

@"^([\w-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([\w-]+\.)+))([a-zA
-Z]{2,4}|[0-9]{1,3})(\]?)$");
}
-----

With the IP address and extra parentheses removed:
@"^([\w-\.]+)@(([\w-]+\.)+)([a-zA-Z]{2,4}$"

For our purposes, the initial "@" is ignored.

The "^" means beginning of line, therefore nothing may precede
the pattern.

The "([\w-\.]+)" means letters, numbers, underscores, hyphens,
and dots, in any order; but at least one character must be present.

The "@" must be present.

The "(([\w-]+\.)+)" is a "nested" pattern with at least one letter,
number, underscore, or hyphen followed by a dot ".". This
pattern must occur at least once.

The "([a-zA-Z]{2,4}" means at least two; but not more than
four letters.

The "$" means end of line.

As may been seen, there is room for one and only one e-mail
address to be validated. The use of the caret ("^") and dollar
sign ("$") means that other characters can not precede nor
follow the e-mail address.

When I wrote "The processing of REs, having developed using
delimited strings, would require the use of ANY LENGTH
items in COBOL (200x with PREFIXED or DELIMITED
phases)"; I had the end of line character ("$") in mind. The
position of the end of line may need to vary depending on the
length of text to be searched for a match and for the regular
expression, itself. I suppose for a COBOL fixed-length field
the definition might be changed to include trailing spaces that
are not part of the text or expression; but I think that's messy
and I am not sure what effect it might have on the regular
expression.

While I can not, at this point, image what implementors might
do to incorporate regular expressions into COBOL, I did
find the following at the University of Limerick.

< http://www1.csisdmz.ul.ie/curstuden...tions/mcoughlan >
-----
ID: MC06
Title: Regular Expressions for COBOL

COBOL does not have any way of evaluating regular expressions.
In certain situations, such as validating user input, regular
expressions would greatly simplify coding. To rectify this omission
this project will create a set of external sub-programs for COBOL
that can be used to evaluate regular expressions.
-----

Some of the changes made for COBOL 2002 were intended to
accommodate such sub-programs; but the ability to incorporate
programs written in other languages may be limited; that is, if the
result of the project is source programs written in standard
COBOL, then regular expressions may be more easily added.

Pete Dashwood

2007-07-06, 3:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:138r0t5o311iu77@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5f3anoF38l4hvU1@mid.individual.net...
> any
> not
> code
> process
> are
> problem
> that
> to
> plug
> environment)
> and
> COBOL
> solved
> programmer.
> same
> could
> would
> more
> syntax
> NO
> number
>
> First, let's deal with the regular expression: "(\\w+)@(\\w+)\\.(\\w+)".
> This is actually quite "lame" for validating e-mail addresses.
> I did some digging at < www.microsoft.com > to get a better
> understanding of Microsoft's "perversion" of regular expressions
> and found the following:
>
> < http://msdn2.microsoft.com/en-us/library/aa332116(VS.71).aspx >
> -----
> .NET Framework Class Library
> Regex.IsMatch Method (String, String)
> Indicates whether the regular expression finds a match in the
> input string using the regular expression specified in the
> pattern parameter.
>
> [C#]
> public static bool IsMatch(
> string input,
> string pattern
> );
>
> Parameters
>
> input
> The string to search for a match.
>
> pattern
> The regular expression pattern to match.
>
> Return Value
> true if the regular expression finds a match; otherwise, false.
> -----
>
> And
> < http://msdn2.microsoft.com/en-us/library/1400241x.aspx >
> -----
> \w
> Matches any word character including underscore. Equivalent
> to '[A-Za-z0-9_]'.
> -----
>
> The IsMatch method will find whether the pattern exists
> anywhere in the string. "(\\w+)@(\\w+)\\.(\\w+)" means letters,
> numbers, or underscores; followed by "@"; followed by more
> letters, numbers, or underscores; followed by a dot (".");
> followed by even more letters, numbers, or underscores will
> match without regard to the position of the pattern in the string.
>
> This means that IsMatch will return true (valid e-mail address)
> when these strings are tested with the given regular expression.:
>
> "The quick brown fox@henhouse.net jumped over" and
> "Apples 5lbs@1.29 per pound - On sale"
>
> Clearly these complete strings are not valid e-mail addresses;
> only the matched portion may be.
>
> Microsoft provides an example, which I have modified.
>
> < http://msdn2.microsoft.com/en-us/library/aa720056(VS.71).aspx >
> -----
> .NET Framework Developer's Guide
> Example: Confirming Valid E-Mail Format
> The following code example uses the static Regex.IsMatch
> method to verify that a string is in valid e-mail format. The
> IsValidEmail method returns true if the string contains a valid
> e-mail address and false if it does not, but takes no other action.
> You can use IsValidEmail to filter out e-mail addresses
> containing invalid characters before your application stores the
> addresses in a database or displays them in an ASP.NET page.
>
> ...
>
> [C#]bool IsValidEmail(string strIn)
> {
> // Return true if strIn is in valid e-mail format.
> return Regex.IsMatch(strIn,
>
> @"^([\w-\.]+)@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)|(([\w-]+\.)+))([a-zA
> -Z]{2,4}|[0-9]{1,3})(\]?)$");
> }
> -----
>
> With the IP address and extra parentheses removed:
> @"^([\w-\.]+)@(([\w-]+\.)+)([a-zA-Z]{2,4}$"
>
> For our purposes, the initial "@" is ignored.
>
> The "^" means beginning of line, therefore nothing may precede
> the pattern.
>
> The "([\w-\.]+)" means letters, numbers, underscores, hyphens,
> and dots, in any order; but at least one character must be present.
>
> The "@" must be present.
>
> The "(([\w-]+\.)+)" is a "nested" pattern with at least one letter,
> number, underscore, or hyphen followed by a dot ".". This
> pattern must occur at least once.
>
> The "([a-zA-Z]{2,4}" means at least two; but not more than
> four letters.
>
> The "$" means end of line.
>
> As may been seen, there is room for one and only one e-mail
> address to be validated. The use of the caret ("^") and dollar
> sign ("$") means that other characters can not precede nor
> follow the e-mail address.
>
> When I wrote "The processing of REs, having developed using
> delimited strings, would require the use of ANY LENGTH
> items in COBOL (200x with PREFIXED or DELIMITED
> phases)"; I had the end of line character ("$") in mind. The
> position of the end of line may need to vary depending on the
> length of text to be searched for a match and for the regular
> expression, itself. I suppose for a COBOL fixed-length field
> the definition might be changed to include trailing spaces that
> are not part of the text or expression; but I think that's messy
> and I am not sure what effect it might have on the regular
> expression.

Well, thank you for the improved RE string. However that wasn't the point of
the post. (And I have been using the "lame" string for some time now without
problem. It is sufficient to my purposes. Having said that, a "tighter" one,
as you have described above, could be useful for cases where the email
actually "really matters", but, in those cases I would ping the URL
anyway...)

I think the point here is that COBOL could implement things through syntax
and let implementors (vendors) decide how they want to do it (usinmg
existing components, or not). Instead, it seems that everything has to be
spelled out to last detail with people who are not even writing the compiler
deciding how it must work.

As is often the case with procedural programming, the focus is on HOW when
it should be on WHAT.

>
> While I can not, at this point, image what implementors might
> do to incorporate regular expressions into COBOL, I did
> find the following at the University of Limerick.
>
> < http://www1.csisdmz.ul.ie/curstuden...tions/mcoughlan >
> -----
> ID: MC06
> Title: Regular Expressions for COBOL
>
> COBOL does not have any way of evaluating regular expressions.
> In certain situations, such as validating user input, regular
> expressions would greatly simplify coding. To rectify this omission
> this project will create a set of external sub-programs for COBOL
> that can be used to evaluate regular expressions.
> -----

University of Limerick has been a strong supporter of COBOL for many years.
Unfortunately, their solutions are not always the best. Again, as long as
the focus is on source code (let's generate a sub-program...) instead of
functionality (we need some functionality; does it exist? How could we
incorporate it or use it?), the solution is going to be a less than optimum
one.

Universities can afford to spend time re-inventing wheels; commerce cannot.
>
> Some of the changes made for COBOL 2002 were intended to
> accommodate such sub-programs; but the ability to incorporate
> programs written in other languages may be limited; that is, if the
> result of the project is source programs written in standard
> COBOL, then regular expressions may be more easily added.
>

And if an RE engine is included in the run time nothing has to be added at
all.

Pete.

Charles Hottel

2007-07-06, 3:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:138r0t5o311iu77@corp.supernews.com...
>
<snip>

> When I wrote "The processing of REs, having developed using
> delimited strings, would require the use of ANY LENGTH
> items in COBOL (200x with PREFIXED or DELIMITED
> phases)"; I had the end of line character ("$") in mind. The
> position of the end of line may need to vary depending on the
> length of text to be searched for a match and for the regular
> expression, itself. I suppose for a COBOL fixed-length field
> the definition might be changed to include trailing spaces that
> are not part of the text or expression; but I think that's messy
> and I am not sure what effect it might have on the regular
> expression.
>
First of all I am ignorant about any POSIX definition for regular
expressions. I am not expert with Java regular expressions but I do know a
little about them. Java has in its platform APIs a package of classes that
process regular expressions on Java strings. Java strings are not delimited
strings. There is no null character or any other character marking the end
of a Java string. So I guess I am not seeing why you have to have delimited
strings in order to have regular expression processing. Admittedly my mind
is elsewhere these days and I am having a lot of trouble concentrating so
maybe I am just miissing something or have not properly understood your
point.

Rick Smith

2007-07-06, 7:55 am

"Charles Hottel" <chottel@earthlink.net> wrote in message
news:3hjji.4471$Od7.1437@newsread1.news.pas.earthlink.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:138r0t5o311iu77@corp.supernews.com...
> <snip>
>
> First of all I am ignorant about any POSIX definition for regular
> expressions. I am not expert with Java regular expressions but I do know
a
> little about them. Java has in its platform APIs a package of classes
that
> process regular expressions on Java strings. Java strings are not
delimited
> strings. There is no null character or any other character marking the
end
> of a Java string. So I guess I am not seeing why you have to have
delimited
> strings in order to have regular expression processing. Admittedly my
mind
> is elsewhere these days and I am having a lot of trouble concentrating so
> maybe I am just miissing something or have not properly understood your
> point.

My reference to "delimited strings" was historical; that is,
the common REs of today were developed using
variable-length, null-terminated (delimited) strings. Any use
of variable-length strings, today, continues that tradition.

COBOL data-items are not defined as variable-length,
except for the ANY LENGTH qualified items I mentioned.
Currently, COBOL data-items may be made variable-length,
programmatically, by using an OCCURS DEPENDING ON
phrase or by insertion of a delimiter; but the occurrence count
or delimiter used are separate data-items.

Karl Kiesel

2007-07-06, 7:55 am

"Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
news:138s45hk1fspnef@corp.supernews.com...
> My reference to "delimited strings" was historical; that is,
> the common REs of today were developed using
> variable-length, null-terminated (delimited) strings. Any use
> of variable-length strings, today, continues that tradition.
>
> COBOL data-items are not defined as variable-length,
> except for the ANY LENGTH qualified items I mentioned.
> Currently, COBOL data-items may be made variable-length,
> programmatically, by using an OCCURS DEPENDING ON
> phrase or by insertion of a delimiter; but the occurrence count
> or delimiter used are separate data-items.
>
Using OO-language elements, ANY LENGTH items are already available in COBOL
STD2002! For a rough sketch, how regualar expressions could be made
available to a COBOL program without invoving any standardization
committees, see below.
Note 1: these are only the easy parts - the demanding parts are all 'to be
supplied'
Note 2: this definition still allows the methods to have their task done by
existing services/libraries/etc of the operating system or to proviede their
own implementation - and by using inheritance, even more or less capable or
specially tuned expression processing can be provided at the same time.
[color=darkred]
PROCEDURE DIVISION.

+++ METHOD-ID. create-expression-validator.
DATA DIVISION.
LINKAGE SECTION.
01 rxf-expression PIC X ANY LENGTH.
01 rxf-new-object OBJECT REFERENCE ACTIVE-CLASS.
PROCEDURE DIVISION USING rxf-expression
RETURNING rxf-new-object.
END METHOD create-expression-validator.
END INTERFACE reg-ex-factory.
[color=darkred]
PROCEDURE DIVISION.

+++ METHOD-ID. validate-expression.
DATA DIVISION.
LINKAGE SECTION.
01 rxo-string PIC X ANY LENGTH.
01 rxo-result PIC 1.
PROCEDURE DIVISION USING rxo-string
RETURNING rxo-result.
END METHOD validate-expression.
END INTERFACE reg-ex-object.
[color=darkred]
INHERITS base.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
REPOSITORY.
CLASS base
INTERFACE reg-ex-factory
INTERFACE reg-ex-object.
FFF FACTORY. IMPLEMENTS reg-ex-factory.
DATA DIVISION.
*> to be supplied!
PROCEDURE DIVISION.

+++ METHOD-ID. create-expression-validator.
DATA DIVISION.
LINKAGE SECTION.
01 rxf-expression PIC X ANY LENGTH.
01 rxf-new-object OBJECT REFERENCE ACTIVE-CLASS.
PROCEDURE DIVISION USING rxf-expression
RETURNING rxf-new-object.
1.
INVOKE SUPER "new" RETURNING rxf-new-object
INVOKE rxf-new-object "remember-expression"
USING rxf-expression.
2.
EXIT METHOD.
END METHOD create-expression-validator.
END FACTORY.

OOO OBJECT.
DATA DIVISION.
*> to be supplied, e.g. the regular expression remembered
*> probably in a form to make later validation easy
PROCEDURE DIVISION.

+++ METHOD-ID. validate-expression.
DATA DIVISION.
LINKAGE SECTION.
01 rxo-string PIC X ANY LENGTH.
01 rxo-result PIC 1.
PROCEDURE DIVISION USING rxo-string
RETURNING rxo-result.
*> to be supplied!
END METHOD validate-expression.

+++ METHOD-ID. remember-expression.
DATA DIVISION.
LINKAGE SECTION.
01 rxo-expression PIC X ANY LENGTH.
PROCEDURE DIVISION USING rxo-expression.
*> to be supplied!
END METHOD remember-expression.

*> may be more 'internal' methods

END OBJECT.
END CLASS regular-expression.

Karl Kiesel
Fujitsu Siemens Computers, München

Rick Smith

2007-07-06, 7:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5f5sdcF3an649U1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:138r0t5o311iu77@corp.supernews.com...
COBOL?[color=darkred]

[snip]
[color=darkred]
> Well, thank you for the improved RE string. However that wasn't the point
of
> the post. (And I have been using the "lame" string for some time now
without
> problem. It is sufficient to my purposes. Having said that, a "tighter"
one,
> as you have described above, could be useful for cases where the email
> actually "really matters", but, in those cases I would ping the URL
> anyway...)

Mr Dashwood, it was never about you or your use of the RE.
The RE was presented as something found on the web and as
a solution to a problem. I called it "lame", explained why, then
offered a different solution (also found on the web), explained
it, and showed why it is more effective for the purpose. My
comments were intended for others who might have been
tempted to use that RE without understanding its limitations.
It was an alternative and, in that sense, no different than your
presenting C# as an alternative to COBOL; though I wish
you wouldn't! <G>

> I think the point here is that COBOL could implement things through syntax
> and let implementors (vendors) decide how they want to do it (usinmg
> existing components, or not). Instead, it seems that everything has to be
> spelled out to last detail with people who are not even writing the
compiler
> deciding how it must work.

Mr Dashwood, you seem not to grasp that the COBOL
standard (indeed, any programming language standard)
is a "specification" document. Everything necessary for
portability of source code and resulting behavior of the
compiled code must "be spelled out to last detail", where
"last detail" is understood to be "everything necessary ...".

This means for specifying a regular expression and the
metacharacters that make up a regular expression must
be identified and the effect of those metacharacters on
the processing of the regular expression must be defined
to the last detail. And that was my point at the start of this
thread.

Consider the less common type of regular expression
that is used in the PICTURE clause. (It is a regular
expression; "we just don't call it that"!) If implementors
were free to define the metacharacters that make up
the "picture", some might have chosen C-type format
strings, instead. Such source code would not be portable.

> As is often the case with procedural programming, the focus is on HOW when
> it should be on WHAT.

I have no idea what point you are trying to make.

Procedure-names, function-names, and method-names
identify what. Procedures, functions, and methods
focus on how; or, so it seems to me.

Object-Oriented design and functional design are
reducible to procedural design. Object-Oriented
programs and functional programs are reducible to
procedural programs (albeit with some name-mangling)
before compiling.

Object-Oriented programming, functional programming, and
procedural programming, all, focus on how; that is, how to
partition a programming problem.

I see conceptual and practicable differences among these;
but see no fundemental difference.

>
>
>
> University of Limerick has been a strong supporter of COBOL for many
years.
> Unfortunately, their solutions are not always the best. Again, as long as
> the focus is on source code (let's generate a sub-program...) instead of
> functionality (we need some functionality; does it exist? How could we
> incorporate it or use it?), the solution is going to be a less than
optimum
> one.
>
> Universities can afford to spend time re-inventing wheels; commerce
cannot.

It seems to me that commerce spends at lot of time
re-inventing wheels (for commercial advantage); how else
could the existence of C# be explained? <g>

Rick Smith

2007-07-06, 6:55 pm

X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Complaints-To: abuse@supernews.com
Lines: 50
Bytes: 3294
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:165757

"Karl Kiesel" <Karl.Kiesel@fujitsu-siemens.com> wrote in message
news:f6lapc$gha$1@nntp.fujitsu-siemens.com...
> "Rick Smith" <ricksmith@mfi.net> schrieb im Newsbeitrag
> news:138s45hk1fspnef@corp.supernews.com...
> Using OO-language elements, ANY LENGTH items are already available in
COBOL
> STD2002! For a rough sketch, how regualar expressions could be made
> available to a COBOL program without invoving any standardization
> committees, see below.

Well, you made me take a closer look at ANY LENGTH
in both the current and draft standards! My statements, above,
are correct; though I don't understand why, in 2002, ANY
LENGTH can not be used in the linkage section of a program,
other than a contained program.

I wrote that, currently, a data-item may be made variable-length
by insertion of a delimiter. Under 2002, the source element
referencing an ANY LENGTH item must know what
delimiter (or other means) was used. Under the draft standard,
the delimiter is explicit by the DELIMITED phrase or defaults
to X"00" for pic X, or X"0000" for pic N. With this change,
the LENGTH function may be used to find the length of an
ANY LENGTH item. The 2002 standard leaves it to the
user to calculate the length. [The LENGTH function also now
works with ANY LENGTH PREFIXED items.] Thus,
under the draft standard ANY LENGTH items become true
variable-length items.

So, regular expressions could be implemented in COBOL 85.
They are less messy in COBOL 2002. And, as far as I can
tell, the draft standard removes the last wrinkles to developing
a class or functions for the processing of regular expressions,
as they are commonly understood.

Rick Smith

2007-07-06, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:138sievlpd5cu04@corp.supernews.com...
[snip]
> Under the draft standard,
> the delimiter is explicit by the DELIMITED phrase or defaults
> to X"00" for pic X, or X"0000" for pic N.

That should be NX"0000" for pic N.

My apologies.

Pete Dashwood

2007-07-06, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:138sduqriahhhbb@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5f5sdcF3an649U1@mid.individual.net...
> COBOL?
>
> [snip]
>
> of
> without
> one,
>
> Mr Dashwood, it was never about you or your use of the RE.
> The RE was presented as something found on the web and as
> a solution to a problem.

Well, Mr. Smith as it was I who started the whole conversation about RE
here, as it was I who posted (in response to a request from someone else) an
example which I use, and contrasted it with what would be required in COBOL
to achieve the same end, I believe I have every right to post the response
I did above.

I called it "lame", explained why, then
> offered a different solution (also found on the web), explained
> it, and showed why it is more effective for the purpose.

Yes, and you did a good job of that. However, it was not what this thread
was about.

You went to levels of detail which were quite unnecessary, as you always do,
in pursuit of something which really isn't worth the effort. Nobody cares
whether a particular (more complex) RE is better for validating email
strings in 1 out of a couple of thousand cases; as I pointed out, if it was
REALLY important, the address would be validated by pinging anyway.

The point of the conversation is whether or not this facility could or
should be part of COBOL. You came up with a whole bunch of problems (without
doing detailed investigation) that would preclude it. I suggested some
alternatives that would make it fairly easy.

>My
> comments were intended for others who might have been
> tempted to use that RE without understanding its limitations

Ha! Given that people using COBOL are unlikely to try and use RE anyway, and
given that I posted a full explanation of what it did when I first posted
it, that would seem somewhat superfluous.

> It was an alternative and, in that sense, no different than your
> presenting C# as an alternative to COBOL; though I wish
> you wouldn't! <G>

Alternatives should be discussed.

I don't see C# as an alternative to COBOL, I see it as a more useful
replacement. Too bad if that offends you; your pedantry has the same effect
on me.

>
>
> compiler
>
> Mr Dashwood, you seem not to grasp that the COBOL
> standard (indeed, any programming language standard)
> is a "specification" document. Everything necessary for
> portability of source code and resulting behavior of the
> compiled code must "be spelled out to last detail", where
> "last detail" is understood to be "everything necessary ...".

Mr. Smith, you seem incapable of grasping that a specification can be
functional as well as technical. It isn't hard to see why COBOL is in the
state it is and releases of standards took so long. Functionality can be
spelled out to the last detail, but that doesn't mean existing wheels must
be re-invented.

Reading your post just makes me thankful we have vendors who are pragmatic
enough to simply get on and do it... There'd be no COBOL if it was left to
COBOL committees.

>
> This means for specifying a regular expression and the
> metacharacters that make up a regular expression must
> be identified and the effect of those metacharacters on
> the processing of the regular expression must be defined
> to the last detail. And that was my point at the start of this
> thread.
>

Nope. It is NOT necessary to go to that level of detail. There are existing
standards for RE. These could be referenced and vendors could make their own
choice within an existing standard. The same applies to XML. It is YOU
personally, who wants to look at every single metacharacter because that is
your nature. Most people don't. Neither do they need to.

> Consider the less common type of regular expression
> that is used in the PICTURE clause. (It is a regular
> expression; "we just don't call it that"!) If implementors
> were free to define the metacharacters that make up
> the "picture", some might have chosen C-type format
> strings, instead. Such source code would not be portable.

PICTURE Clauses were developed at a time when there was no alternative.
Implementors would not have chosen C type format strings because C was not
invented. PICTURE was developed to remove the necessity to code SIZE, CLASS
and USAGE, as we had to do in the early implemations of COBOL. In fact, to
this day you can define data fields in COBOL without using PICTURE.

My point is that PICTURE was NOT a re-invention of the wheel; it was a
useful addition to the language which saved people time.

As for portability, COBOL isn't portable anyway. The best you can do is hope
to keep it less of a hassle to convert by using a strict subset of
constructs. It doesn't have the portability of Java or of C#.
>
>
> I have no idea what point you are trying to make.

No, I know. It's

...
>
> Procedure-names, function-names, and method-names
> identify what. Procedures, functions, and methods
> focus on how; or, so it seems to me.
>
> Object-Oriented design and functional design are
> reducible to procedural design. Object-Oriented
> programs and functional programs are reducible to
> procedural programs (albeit with some name-mangling)
> before compiling.

Oh sure, and all computers execute one instruction at a time so procedural
has to be the way to go...

>
> Object-Oriented programming, functional programming, and
> procedural programming, all, focus on how; that is, how to
> partition a programming problem.

Sure. If all you can see is a programming problem...
>
> I see conceptual and practicable differences among these;
> but see no fundemental difference.
>

Perhaps you need more practice at looking?

> years.
> optimum
> cannot.
>
> It seems to me that commerce spends at lot of time
> re-inventing wheels (for commercial advantage); how else
> could the existence of C# be explained? <g>

I don't get emotional about programming languages. C# exists because it gets
the job done.

If it stopped doing that, I'd move to something else. As to commerce
re-inventing existing wheels, perhaps you'd like to run that argument past
all the people who moved from COBOL to SAP, Siebel, Peoplesoft and Oracle in
the last few years... ?

Dashwood.

Howard Brazee

2007-07-06, 6:55 pm

On Sat, 7 Jul 2007 04:41:37 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>I don't see C# as an alternative to COBOL, I see it as a more useful
>replacement. Too bad if that offends you; your pedantry has the same effect
>on me.

....

>I don't get emotional about programming languages. C# exists because it gets
>the job done.

I'm curious. Certainly C# has its strengths, and there are jobs it
does quite well. But as someone who doesn't believe that one tool
is the best for all jobs, I don't see that C#'s strengths and uses are
a good match for CoBOL's.

But that doesn't mean you aren't right. I tend to think CoBOL is
being replaced by something even more different than C# is - and
that's a combination of intelligent databases, report programs, and
interfaces instead of any one language.

I don't see companies replacing their CoBOL green bar report program
with a C# XML report program.

Rick Smith

2007-07-06, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5f79m1F3a58vtU1@mid.individual.net...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:138sduqriahhhbb@corp.supernews.com...
point[color=darkred]
>
> Well, Mr. Smith as it was I who started the whole conversation about RE
> here, as it was I who posted (in response to a request from someone else)
an
> example which I use, and contrasted it with what would be required in
COBOL
> to achieve the same end, I believe I have every right to post the
response
> I did above.

You have a right to respond in any way you like. But, I
believe my reaction would have been the same, or at least
similar, regardless of who posted it. In fact, if you check
the prior posts, you will find I posted an RE for checking
e-mail addresses about 20 minutes before your posting of
one. We both responded to the same post by Mr Brady.

Now, try to imagine *my* reaction! A much shorter RE
said to accomplish about the same thing. Preposterous!

>
> I called it "lame", explained why, then
>
> Yes, and you did a good job of that. However, it was not what this thread
> was about.

When you reposted that RE, in this thread, I felt a need
address the issue and without regard for the immediate
topic of discussion.

>
> You went to levels of detail which were quite unnecessary, as you always
do,
> in pursuit of something which really isn't worth the effort. Nobody cares
> whether a particular (more complex) RE is better for validating email
> strings in 1 out of a couple of thousand cases; as I pointed out, if it
was
> REALLY important, the address would be validated by pinging anyway.

Mr Dashwood, you may have found the level of detail
to be unnecessary, others may have not. My suspecting
that some others, in this group, have no knowledge of REs,
I felt others mught appreciate a full explanation of what they
were seeing. Once agian, it was never about you!

> The point of the conversation is whether or not this facility could or
> should be part of COBOL. You came up with a whole bunch of problems
(without
> doing detailed investigation) that would preclude it. I suggested some
> alternatives that would make it fairly easy.

I did not miss that.

>
> Ha! Given that people using COBOL are unlikely to try and use RE anyway,
and
> given that I posted a full explanation of what it did when I first posted
> it, that would seem somewhat superfluous.

Mr Dashwood, people using COBOL are unlikely to use
what they do not know about. You had complained there
was no interest in discussing REs a year ago. Now they
have been discussed. Those who are interested will
investigate further. Ultimately, what they may do depends
upon their needs.

>
> Alternatives should be discussed.
>
> I don't see C# as an alternative to COBOL, I see it as a more useful
> replacement. Too bad if that offends you; your pedantry has the same
effect
> on me.

"(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...)"

Perhaps you do not recall having written that!

be[color=darkred]
>
> Mr. Smith, you seem incapable of grasping that a specification can be
> functional as well as technical. It isn't hard to see why COBOL is in the
> state it is and releases of standards took so long. Functionality can be
> spelled out to the last detail, but that doesn't mean existing wheels must
> be re-invented.

H'm! Functional or portable, choose one. In the COBOL
standard, there is functionality that is implementor-defined;
but this functionality has little or no effect on portability of
source code. For example, the specifications of COMP
and PACKED-DECIMAL are functional.

> Reading your post just makes me thankful we have vendors who are pragmatic
> enough to simply get on and do it... There'd be no COBOL if it was left to
> COBOL committees.

Eventhough, some vendors participate on those committees?

>
> Nope. It is NOT necessary to go to that level of detail. There are
existing
> standards for RE. These could be referenced and vendors could make their
own
> choice within an existing standard. The same applies to XML. It is YOU
> personally, who wants to look at every single metacharacter because that
is
> your nature. Most people don't. Neither do they need to.

Perhaps, most people do not take the viewpoint required
to understand the process for amending the COBOL standard.
I look at such things because I know that J4 will look at such
things and it is in my nature to try to anticipate problems.

>
>
>
> PICTURE Clauses were developed at a time when there was no alternative.
> Implementors would not have chosen C type format strings because C was not
> invented. PICTURE was developed to remove the necessity to code SIZE,
CLASS
> and USAGE, as we had to do in the early implemations of COBOL. In fact, to
> this day you can define data fields in COBOL without using PICTURE.

No, implementors could not choose C-type format strings
because such strings would not conform to the standard;
but, if you like, substitute FORTRAN-type formats; same
result.

> My point is that PICTURE was NOT a re-invention of the wheel; it was a
> useful addition to the language which saved people time.
>
> As for portability, COBOL isn't portable anyway. The best you can do is
hope
> to keep it less of a hassle to convert by using a strict subset of
> constructs. It doesn't have the portability of Java or of C#.

Implementors claiming conformance to the standard are
required to provide a means for identifying which constructs
do not conform. Most of what affects portability is confined
to the environment division.

Portability of Java and C# is irrelevant in a COBOL
newgroup. <g>

>
> No, I know. It's

...

Well, you could have rephrased and tried again.

>
> Oh sure, and all computers execute one instruction at a time so procedural
> has to be the way to go...

Well, no! The Power PC, as I understand it, can execute
multiple integer and floating-point operations, each, at the same
time.

>
> Sure. If all you can see is a programming problem...

Programming methods to partition programming problems.
Seem to follow naturally!

>
> Perhaps you need more practice at looking?

Or, you might try to understand that I don't see what you
see and then try to understand why. For example, a great
deal of what has been put forth as Object-Oriented
programming, I see as implementation of procedural
or functional design; that is, decide what procedures or
functions to perform and put them into methods. I see this
happening; but I'm reasonably sure those doing the
programming don't understand they are doing it. Mind
you, I no longer s

out cases where this happens; but
I've seen enough to recognize the pattern.

What I have rarely seen is implementation of an
Object-Oriented design, which, it seems to me, is the
point of Object-Orientation.

as[color=darkred]
of[color=darkred]
>
> I don't get emotional about programming languages. C# exists because it
gets
> the job done.

Of course you get emotional about progamming languages!
You convey that emotion by raving about C# and by damning
COBOL. You did the same with Java. You do it with SQL
versus COBOL ISAM.

Love and hate are emotions; their opposite is apathy. If you
didn't care, you wouldn't express opinions about programming
languages!

> If it stopped doing that, I'd move to something else. As to commerce
> re-inventing existing wheels, perhaps you'd like to run that argument past
> all the people who moved from COBOL to SAP, Siebel, Peoplesoft and Oracle
in
> the last few years... ?

Do you mean from COBOL to group of re-invented wheels
trying to gain a commercial advantage over each other?

2007-07-06, 6:55 pm

In article <138tbv0h4hkd243@corp.supernews.com>,
Rick Smith <ricksmith@mfi.net> wrote:

[snip]

>Love and hate are emotions; their opposite is apathy.

Oh, I *cannot* resist...

.... love and hate are conditions that you can work up some feeling
about... as for apathy, who cares?

DD

Pete Dashwood

2007-07-07, 3:55 am

"Howard Brazee" <howard@brazee.net> wrote in message
news:23vs83hk665ks484ctf7vdcsspi79erhaq@
4ax.com...
> On Sat, 7 Jul 2007 04:41:37 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> ...
>
>
> I'm curious. Certainly C# has its strengths, and there are jobs it
> does quite well. But as someone who doesn't believe that one tool
> is the best for all jobs, I don't see that C#'s strengths and uses are
> a good match for CoBOL's.
>
> But that doesn't mean you aren't right. I tend to think CoBOL is
> being replaced by something even more different than C# is - and
> that's a combination of intelligent databases, report programs, and
> interfaces instead of any one language.

Yes, you are quite right. It isn't about any particular language.
Nevertheless, and I stress it is simply a personal opinion, for the jobs
that I WOULD have used COBOL in the past, I now find C# serves me better.

>
> I don't see companies replacing their CoBOL green bar report program
> with a C# XML report program.

That's the nub of it. Until people start to realise that paper reports are
really not as valuable as they have been any more, there will continue to be
managers who demand them. These days it is about INFORMATION. It needs to be
timely (up to the millisecond), easily digestible (graphic and summarised,
with drill down capabilities) and it should only be committed to paper as a
last resort.

This is a major shift for many managers. I think that's why I get tired of
debating languages here. It is a paradigm shift. It isn't just about
languages, it is about whole new ways of looking at things, and in
particular, software and system development.

It is really crazy for me to sit here and debate the use of Object
technology with people who can only see it in terms of a programming
solution, and think it is just procedural code re-invented. It isn't. RAD,
component (object) based system design is so far removed from the Waterfall
and procedural code that the programming part of it pales into
insignificance.

Anyway, I realise I have let some of this get to me and I really shouldn't.

I'll be a less frequent visitor here in the future and many people will be
pleased to hear that.

Pete.

Pete Dashwood

2007-07-07, 3:55 am

"LX-i" <lxi0007@netscape.net> wrote in message
news:T_idnRKFgOeYcRPbnZ2dnUVZ_umlnZ2d@co
mcast.com...
> Howard Brazee wrote:
>
> At my last assignment, our formerly-on-the-mainframe source code control
> system was moved to the web, with parts in C#. (In fact, that big thing I
> posted back in February was part of it.)
>
>
> (As you like to say) For various values of "language". :)
>
> I'd venture to say that most all systems use more than one language - the
> aircraft maintenance system that I worked on at my last base used COBOL,
> Java, JavaScript, HTML, XML, XSLT, SQL, and a proprietary network database
> language called DML.
>
> What you've described above falls nicely within the Model View Controller
> methodology. The "model" is the persistent data store, the "view" is the
> way information is presented to the user, and the "controller" is the
> bridge between the two.
>
> Then, is XML a language in the same way as COBOL, Java, or C#? I've seen
> XML used for lots of things - configuration parameters, a structured way
> of passing data internally between modules, formatting data for exchange
> with other systems, even as the output displayed to the user (formatted
> with XSLT).
>
> I'm not saying you're wrong about this - just adding to it. I see the
> common factor coming down to XML. No matter how you get to it (COBOL, C#,
> Java, QuickBASIC), and no matter what you do with it (look at it with
> human eyes, load it into a database, or use it to tell other software what
> to do), XML is the glue that holds it all together.
>

I agree with your point on the importance of XML, Daniel. Especially as the
web starts to bite and web services become more important.

But, as Howard pointed out, it isn't any ONE factor (language, methodology,
or even management approach) that will shape the future.

It is a complete rethink. A paradigm shift that started with people
realising the benefits of Object technology and moving on from there.

Pete.

Pete Dashwood

2007-07-07, 3:55 am

This is my last response on this.

See below.

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:138tbv0h4hkd243@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5f79m1F3a58vtU1@mid.individual.net...
> point
> an
> COBOL
> response
>
> You have a right to respond in any way you like. But, I
> believe my reaction would have been the same, or at least
> similar, regardless of who posted it. In fact, if you check
> the prior posts, you will find I posted an RE for checking
> e-mail addresses about 20 minutes before your posting of
> one. We both responded to the same post by Mr Brady.

Except that Mr Brady was responding to a post from me.

>
> Now, try to imagine *my* reaction! A much shorter RE
> said to accomplish about the same thing. Preposterous!
>

Nope. That's what it does. You never considered the spec which accompanied
it, instead you decided a whole lot more stuff was required. In reality, the
only effective way to check an email address is to mail to it (and even
that is not foolproof). You were so excited by a chance to expound on REs
that you lost sight of what the actual requirement was.

>
> When you reposted that RE, in this thread, I felt a need
> address the issue and without regard for the immediate
> topic of discussion.
>
> do,
> was
>
> Mr Dashwood, you may have found the level of detail
> to be unnecessary, others may have not. My suspecting
> that some others, in this group, have no knowledge of REs,
> I felt others mught appreciate a full explanation of what they
> were seeing. Once agian, it was never about you!

You keep saying that.. I never considered it was about me, and never have
considered that in any posts here, apart from off-topic ones regarding
personal beliefs or opinions. I don't actually need the approval of CLC (or
you) in order to feel good about myself. What I described was subjective
experience using REs. You were so outraged that I would use a MS
implementation ("perversion" was the condescending word you used; why don't
you ask the millions of people who use MS REs every day whether they think
it is a "perversion"?) that you jumped into a conversation that was nothing
to do with you, and decided the innocent masses must be protected, by boring
them to death. No-one actually asked you; but you felt it was important...
then you try to say it isn't about me :-). At least I respond when I'm
asked, I don't assume people are waiting to hang on my every word. It's a
public forum; anyone can post anywhere, but you could have started another
thread for your soapbox.

I found your post hostile, condescending, and not of much real value. So
that's one man's opinion. Unfortunately it prompted me to respond in kind
and that is just as stupid. I won't be doing it any more.

>
> (without
>
> I did not miss that.
>
> and
>
> Mr Dashwood, people using COBOL are unlikely to use
> what they do not know about. You had complained there
> was no interest in discussing REs a year ago.

It was not a complaint, it was an observation. I actually couldn't care less
whether people use REs or they don't. I'm not driven to expound on it and
responded only when someone asked me to.

Now they
> have been discussed. Those who are interested will
> investigate further. Ultimately, what they may do depends
> upon their needs.

Gosh, d'you think...?
>
> effect
>
> "(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...)"
>
> Perhaps you do not recall having written that!

I certainly do recall writing that, and, like everything I write, it was
true at the time. However, since then, I have moved on and my opinion is now
as stated above. Some of us don't live in a fixed condition and reserve the
right to change our minds in the light of new experience. I started out
seeing C# as a possible alternative to COBOL. And it was not the only one I
considered. Tried it, liked it, got more facile with it, now I'm happy with
it. End of story.

The fact that you would search archives to try and make me look
inconsistent, speaks volumes to me. I suppose that kind of attack "isn't
about me" either?

It was that single comment from you that made me decide to respond to this
thread.

>
> be
>
> H'm! Functional or portable, choose one.

The two are only mutually exclusive in your mind.

>In the COBOL
> standard, there is functionality that is implementor-defined;
> but this functionality has little or no effect on portability of
> source code. For example, the specifications of COMP
> and PACKED-DECIMAL are functional.
>
>
> Eventhough, some vendors participate on those committees?

I'm glad you mentioned that (I wouldn't have... it would be a cheap shot.)
Care to comment on exactly how many vendors have withdrawn their support in
....ooh, say, the last 5 years? No? Yes, probably best not to...
>
> existing
> own
> is
>
> Perhaps, most people do not take the viewpoint required
> to understand the process for amending the COBOL standard.
> I look at such things because I know that J4 will look at such
> things and it is in my nature to try to anticipate problems.
>

I guess that's how you developed your scratch 'n sniff methodology...

> CLASS
>
> No, implementors could not choose C-type format strings
> because such strings would not conform to the standard;
> but, if you like, substitute FORTRAN-type formats; same
> result.

Thankfully, at the time PICTURE was introduced, COBOL was in much better
hands than it is today. They actually produced a standard that was simple
and easily implemented. Vendors had no need to resort to non-standard
strings because the standard was simple, clear, and straightforward. It
wasn't written in legalese by pedants who would agonise over the
interpretation of every word. (Neutral readers might like to try reading the
2002 standard and draw their own conclusions.)

>
> hope
>
> Implementors claiming conformance to the standard are
> required to provide a means for identifying which constructs
> do not conform. Most of what affects portability is confined
> to the environment division.

Ever done any porting of COBOL across platforms? I have. It is a non-trivial
exercise. The people who invented COBOL had vision and a dream of a language
that would run on ANY mainframe (That's all there was at the time). Over the
years that vision has become so corrupted (sometimes necessarily, in the
pursuit of competitive advantage...) that it is no longer true. If there had
been a strong and effective standards body (with the same vision and
aspiration as CODASYL) who actually cared about the language and who had
some credibility, this could have been rectified. Instead, we eventually
arrived at the situation we have today... small wonder it isn't
transportable.

>
> Portability of Java and C# is irrelevant in a COBOL
> newgroup. <g>

So is an exposition on Regular Expressions. Not part of the language.

>
>
> Well, you could have rephrased and tried again.

Yes. Would it make any difference? I said at the start I didn't intend to
debate this, and to do so with someone who is demonstrably hostile is simply
a waste of time. It's a rainy Saturday here so I'm prepared to make this
post, but it will certainly be my last one in this thread, and you won't be
surprised if I don't respond to your posts for some time in the future.

>
>
> Well, no! The Power PC, as I understand it, can execute
> multiple integer and floating-point operations, each, at the same
> time.
>

Golly! Is there no end to the elucidation...
>
> Programming methods to partition programming problems.
> Seem to follow naturally!
>
>
> Or, you might try to understand that I don't see what you
> see and then try to understand why.

Now, it's funny you should say that, Mr. Smith. I recognise that you
certainly don't see what I see and I'm fine with that.

Most of the people who know me consider me to be an understanding and
sympathetic sort of person, I try to be there for friends and my shoulder
has often been dampened by the tears of the distressed, but I seem to be
short of understanding when it comes to people who call the solutions I use
"lame" and anything that doesn't conform to their particular viewpoint, a
"perversion".

Even rising above that, and I it doesn't really matter, I simply cannot
understand the world you inhabit. It seems to me to be a world of dusty
tomes and Acadaemia, where whatever is written down is true. You quote
chapters and verse as if they were Holy Writ and require no further scrutiny
or proving; it is enough that they are in the book. Your attention to detail
would be commendable if it weren't so obsessive.

Your reduction below of Object use, into purely procedural programming terms
is simply staggering. It shows a narrowness of vision that I simply cannot
comprehend.

So, yes, you're right, I don't understand. However, I have tried.

For example, a great
> deal of what has been put forth as Object-Oriented
> programming, I see as implementation of procedural
> or functional design; that is, decide what procedures or
> functions to perform and put them into methods. I see this
> happening; but I'm reasonably sure those doing the
> programming don't understand they are doing it. Mind
> you, I no longer s

out cases where this happens; but
> I've seen enough to recognize the pattern.

Ah, so people who are doing it everyday are not blessed with your superior
wisdom and don't realise they are NOT REALLY dealing with objects; instead
they are conforming to a conceptual pattern that is really based in
procedural code. OK... I think I have to go now... (looks at watch)...
>
> What I have rarely seen is implementation of an
> Object-Oriented design, which, it seems to me, is the
> point of Object-Orientation.
>

Well, of course. The whole thing's a misnomer if it doesn't comply to what
you have read somewhere. The fact that the wole world is running with it
shouldn't let us get away with calling it something it isn't (according to
Mr. Smith).

> as
> of
> gets
>
> Of course you get emotional about progamming languages!
> You convey that emotion by raving about C# and by damning
> COBOL.
Er... it isn't actually me that's raving just now... could you lower your
voice a bit? I have never damned COBOL. I have waxed enthusiastic about C#.
No apology for it.

You did the same with Java. You do it with SQL
> versus COBOL ISAM.

And, of course, there is absolutely no possibility I could be right?
Remember, it isn't about me... try GOOGLing on "Java programming"
(170,000,000 hits), or "SQL" (169,000,000 hits), then do the same with
"COBOL programming" (2,220,000 hits) and "ISAM" (1,380,000 hits)..."

Well, tickle me with a teacake, looks like Dashwood isn't the only person
who holds such an opinion...the world is going to Hell in a handcart...
can't they see that COBOL and ISAM are the only true solution...?

OK. So a contrary viewpoint (to that held by R. Smith...not necessarily
contrary to that held by millions of other people), expressed honestly,
without malice, and stated to be opinion, is now a rave? I call 'em like I
see 'em. Always have, always will. I don't need to rave to do that, and I
also realise that my opinions on these things are not Life and Death. It is
only computer programming.

>
> Love and hate are emotions; their opposite is apathy. If you
> didn't care, you wouldn't express opinions about programming
> languages!

I care about a lot of things that I neither love nor hate.

I guess I have apathy as well, because I really don't care about whether you
listen to me or not.

>
> in
>
> Do you mean from COBOL to group of re-invented wheels
> trying to gain a commercial advantage over each other?
>

Whatever...

Dashwood... out.

2007-07-07, 7:55 am

In article <5f904cF3bffdfU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>This is my last response on this.
>
>See below.
>
>"Rick Smith" <ricksmith@mfi.net> wrote in message
>news:138tbv0h4hkd243@corp.supernews.com...

[snip]

>
>You keep saying that.. I never considered it was about me, and never have
>considered that in any posts here, apart from off-topic ones regarding
>personal beliefs or opinions. I don't actually need the approval of CLC (or
>you) in order to feel good about myself. What I described was subjective
>experience using REs. You were so outraged that I would use a MS
>implementation ("perversion" was the condescending word you used; why don't
>you ask the millions of people who use MS REs every day whether they think
>it is a "perversion"?) that you jumped into a conversation that was nothing
>to do with you, and decided the innocent masses must be protected, by boring
>them to death. No-one actually asked you; but you felt it was important...
>then you try to say it isn't about me :-).

Mr Dashwood, what you comment here on - editorialising aside - is Mr
Smith's having posted to a thread in which he had not (to a point)
previously participated and in which he had not been addressed directly.

That sounds... that sounds an *awful* lot like what happens with a fair
amount of frequency in many unmoderated UseNet fora, doesn't it?

[snip]

>
>I certainly do recall writing that, and, like everything I write, it was
>true at the time. However, since then, I have moved on and my opinion is now
>as stated above.

'At the time'? Mr Dashwood, *I* was not familiar with your having made
that statement... and I found that the datestamp on it (as shown in
<http://groups.google.com/group/comp...6b?dmode=source> )
is Mon, 18 Jun 2007 23:56:15 +1200.

Your posting to which I am responding now is... oh, that whacky
International Date Line... let's call it 7 July 2007, a hair over two
w

s.

>Some of us don't live in a fixed condition and reserve the
>right to change our minds in the light of new experience.

Others might consider that a position on a professional matter which was
stated in public nineteen days ago and not in any wise modified in the
intervening time to be still held or considered at least... moderately
valid.

>I started out
>seeing C# as a possible alternative to COBOL. And it was not the only one I
>considered. Tried it, liked it, got more facile with it, now I'm happy with
>it. End of story.

For the moment, perhaps... until another nineteen days passes, when a
mention of what's said today might generate a response of 'That was then,
this is now... Calendar Reform, all is different, I've moved on, why can't
you?'

>
>The fact that you would search archives to try and make me look
>inconsistent, speaks volumes to me. I suppose that kind of attack "isn't
>about me" either?

It may be about the foundations of discussion, Mr Dashwood, and how you,
as a participant, expect your statements to be seen and considered. Since
you are the best source for statements of your intent and you made - in
what some might call a rather short time - two contradictory statements of
intent a question to you about how these contradictions might be
reconciled seems to be completely and utterly in order.

That an archive was searched - if such a thing happened - also seems to be
completely and utterly in order. Mr Smith reads you saying 'A' on 6 July
(or thereabouts) and mutters 'Wait a minute... didn't he just say 'B'
scarecly a fortnight back?' To turn to the archives allows for
verification outside of the notorious porosity of memory that some here
have demonstrated.

>
>It was that single comment from you that made me decide to respond to this
>thread.

It seems to have allowed you to demonstrate a great deal, Mr Dashwood...
it may be left up to the Gentle Readers to determine 'a great deal of
what?'.

DD

Alistair

2007-07-07, 6:55 pm

On 7 Jul, 00:08, docdw...@panix.com () wrote:
> In article <138tbv0h4hkd...@corp.supernews.com>,
>
> Rick Smith <ricksm...@mfi.net> wrote:
>
> [snip]
>
>
> Oh, I *cannot* resist...
>
> ... love and hate are conditions that you can work up some feeling
> about... as for apathy, who cares?
>
> DD

I can not resist either...

Apathetic people may care but are not inclined to do anything about
it.

And as for the toing-and-throing in the thread; I am reminded that
there is no zealot like a convert. This may explain PD's enthusiasm
for OO, Java, C# and RDBMS observed elsewher in the thread..

Alistair

2007-07-07, 6:55 pm

On 7 Jul, 02:27, LX-i <lxi0...@netscape.net> wrote:
> Howard Brazee wrote:
>
>

My boozy chum once expressed a requirement for a program to convert a
output report into XHTML so that it could be viewed using any browser.
I'm tempted to write it in, guess what?, COBOL.

Pete Dashwood

2007-07-07, 6:55 pm

<docdwarf@panix.com> wrote in message news:f6o1hi$siv$1@reader2.panix.com...
> In article <5f904cF3bffdfU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>
> Mr Dashwood, what you comment here on - editorialising aside - is Mr
> Smith's having posted to a thread in which he had not (to a point)
> previously participated and in which he had not been addressed directly.

Yes, I was wondering how long before you commented. (It is the
predictability of this forum that makes it so...predictable.)

OK, let's address the pronouncements of the poison Dwarf... :-)
>
> That sounds... that sounds an *awful* lot like what happens with a fair
> amount of frequency in many unmoderated UseNet fora, doesn't it?
>

Yes. And I said as much but you conveniently snipped it.

"It's a
public forum; anyone can post anywhere, but you could have started another
thread for your soapbox."

Sounds fair to me.

> [snip]
>
>
> 'At the time'? Mr Dashwood, *I* was not familiar with your having made
> that statement... and I found that the datestamp on it (as shown in
> <http://groups.google.com/group/comp...6b?dmode=source> )
> is Mon, 18 Jun 2007 23:56:15 +1200.
>
> Your posting to which I am responding now is... oh, that whacky
> International Date Line... let's call it 7 July 2007, a hair over two
> w

s.
>

Well, I'm glad things are so slack in Midgetville that you have nothing
better to do than get involved in something that is nothing to do with you.
I should be flattered tby the fact that a change in my position on something
(albeit, a minimal and normal one), has sent you scurrying to your keyboard
to try and make an issue out of it.

Slack news day?

>
> Others might consider that a position on a professional matter which was
> stated in public nineteen days ago and not in any wise modified in the
> intervening time to be still held or considered at least... moderately
> valid.
Fortunately there is no evidence that "others" do think that. "Others"
really don't give a shit. They quite rightly realise that my personal
opinion about a programming language (or anything else, for that matter) can
be subject to change. At least when I do change my mind, I explain why.

Furthermore, you missed the fact that enlightenment or epiphany can happen
at any time. What I personally think about a given programming language was
not under discussion. Except that it irks Mr. Smith so he made it an issue.

The new position is a logical progression from the old one and was explained
as such in my post. This time you left the quote in (thank you)...

>

So, what part of "growth" do you have a problem with?
[color=darkred]
>
> For the moment, perhaps... until another nineteen days passes, when a
> mention of what's said today might generate a response of 'That was then,
> this is now... Calendar Reform, all is different, I've moved on, why can't
> you?'

Exactly. And why wait nineteen days? It could happen tomorrow...
>
>
> It may be about the foundations of discussion, Mr Dashwood, and how you,
> as a participant, expect your statements to be seen and considered. Since
> you are the best source for statements of your intent and you made - in
> what some might call a rather short time - two contradictory statements of
> intent a question to you about how these contradictions might be
> reconciled seems to be completely and utterly in order.

Fair comment, if it were true. The statements made were NOT contradictory.
One was an extension of the other, and explanation was given to that effect.

And don't start getting Holy about the "foundations of discussion"... It's a
Usenet Forum. I discuss things here as fairly as anyone else does.

>
> That an archive was searched - if such a thing happened - also seems to be
> completely and utterly in order. Mr Smith reads you saying 'A' on 6 July
> (or thereabouts) and mutters 'Wait a minute... didn't he just say 'B'
> scarecly a fortnight back?' To turn to the archives allows for
> verification outside of the notorious porosity of memory that some here
> have demonstrated.
>

Had it been done in that spirit my reaction to it would certainly have been
different. It was done with hostile intent and that changes everything.

>
> It seems to have allowed you to demonstrate a great deal, Mr Dashwood...
> it may be left up to the Gentle Readers to determine 'a great deal of
> what?'.

Yes, I'm sure they're staying up nights.

Now let's get to you...

What exactly is your stake here? Just wanted to point out that it's
perfectly OK to search stuff?

Never was an issue. Of course it is.

However the reaction encountered when doing so, may vary with the search
motivation.

Still, it's good to know you are on the case...:-)

Pete.

Pete Dashwood

2007-07-07, 6:55 pm

X-Trace: individual.net upDVLT+nCeDNPaWP2crdAQgt/3Nu8BpAB96fsFt3AWmScaWSJE
Cancel-Lock: sha1:YQzLlz+cg0hv8mJPS4dp8WcSCvg=
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-RFC2646: Format=Flowed; Original
Bytes: 2374
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:165779

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1183818066.878643.299190@n2g2000hse.googlegroups.com...
> On 7 Jul, 00:08, docdw...@panix.com () wrote:
>
> I can not resist either...
>
> Apathetic people may care but are not inclined to do anything about
> it.
>
>
> And as for the toing-and-throing in the thread; I am reminded that
> there is no zealot like a convert. This may explain PD's enthusiasm
> for OO, Java, C# and RDBMS observed elsewher in the thread..
>
Yes, or it could be that I'm just enthusiastic by nature. Funny, I've never
thought of it as being a bad thing...or needed to apologize for it.

And I am neither convert (I still use COBOL, but recognise its limitations
and where it is going) nor zealot. Please don't apologise for me, if that is
what you were doing.

Pete.

I'm starting to think that my work here is done. It isn't fun any more and
ly think my work here is done.

Rick Smith

2007-07-07, 6:55 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5f904cF3bffdfU1@mid.individual.net...
> This is my last response on this.
>
> See below.
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:138tbv0h4hkd243@corp.supernews.com...

[snip]
[color=darkred]

[snip]
[color=darkred]
> I found your post hostile, condescending, and not of much real value. So
> that's one man's opinion. Unfortunately it prompted me to respond in kind
> and that is just as stupid. I won't be doing it any more.

Hositility was never my intent. What I intended was to
keep from insinuating that your use of the RE and its
associated code was unprofessional.

[snip]

> Your reduction below of Object use, into purely procedural programming
terms
> is simply staggering. It shows a narrowness of vision that I simply
cannot
> comprehend.
>
> So, yes, you're right, I don't understand. However, I have tried.
>
> For example, a great
>
> Ah, so people who are doing it everyday are not blessed with your superior
> wisdom and don't realise they are NOT REALLY dealing with objects; instead
> they are conforming to a conceptual pattern that is really based in
> procedural code. OK... I think I have to go now... (looks at watch)...

I wrote "Object-Oriented programming" not "dealing with
objects" nor "Object use". Perhaps you are not understanding
because you translate my words to fit your conceptions; instead
of understanding me.

Perhaps some examples will clarify my point.

This was the original.
-----
public static bool IsValidEmailAddress(string sEmail)
{
if (sEmail == null)
{
return false;
}

int nFirstAT = sEmail.IndexOf('@');
int nLastAT = sEmail.LastIndexOf('@');

if ((nFirstAT > 0) && (nLastAT == nFirstAT) &&
(nFirstAT < (sEmail.Length - 1)))
{
// address is ok regarding the single @ sign
return (Regex.IsMatch(sEmail, @"(\w+)@(\w+)\.(\w+)"));
}
else // I don't believe this is necessary but I left it in, in
deference to the original programmer. Pete.
{
return false; // this could be unconditional; if there is a
match the expression will return TRUE anyway...
}
}
-----
This following is sufficient to accomplish the same end
(actually, it does a bit more).
-----
public static bool IsValidEmailAddress(string sEmail)
{
// Return true if SEmail is in valid e-mail format.
return
Regex.IsMatch(sEmail,@"^([\w-\.]+)@(([\w-]+\.)+)([a-zA-Z]{2,4}$");
}
-----
Both of the above are procedural.
The following is OO.
-----
public static bool IsValidEmailAddress(string sEmail)
{
// Return true if SEmail is in valid e-mail format.
Regex r = new Regex(@"^([\w-\.]+)@(([\w-]+\.)+)([a-zA-Z]{2,4}$");
return r.IsMatch(sEmail);
}
-----

The first was apparently the result of not understanding regular
expressions and how IsMatch works. In particular, the use of
the caret and dollar sign surrending the regular expression
prevents more than one e-mail address (additional occurrences
of "@"), which is the apparent purpose for the extraneous code.
In other words, though simple, it lacks professionalism.

The first and second are procedural use of objects. In these
cases, apparently, a temporary object is created, used, then
discarded. This is no different than the COBOL sequence:

call "IsMatch" using bool, sEmail, email-re
cancel "IsMatch"

The third creates an object initializing it with the regular
expression. It then uses the object and could do so repeatedly
because the regular expression is held in the object and not
passed through the interface. Holding data in the object is part
of Object-Oriented programming.

These examples are small and the differences are subtle; but
these are the patterns I see.

2007-07-07, 9:56 pm

In article <5fa056F3avi0vU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f6o1hi$siv$1@reader2.panix.com...
>
>Yes, I was wondering how long before you commented. (It is the
>predictability of this forum that makes it so...predictable.)

If this has been said before I commented, Mr Dashwood, then it might have
been called predicting; as it comes afterwards it... might now.

>
>OK, let's address the pronouncements of the poison Dwarf... :-)

Perhaps it might be more advantageous to see if something might better be
found to occupy your time, Mr Dashwood... after all, you're a busy man,
remember?

DD

Pete Dashwood

2007-07-07, 9:56 pm

"Richard Brady" <rrllbrrady@worrlldnet.att.net> wrote in message
news:iiSji.154348$Sa4.52581@bgtnsc05-news.ops.worldnet.att.net...
> Messrs. Dashwood, Smith et al;
>
> Pete Dashwood wrote:
>
> [snip]
>
> I am ashamed that I caused such a row.
>
Don't be. This is Usenet. We have fights here all the time... :-)

It rarely gets personal, but it did on this occasion.

No one died...:-)

You are not responsible.

Pete.

Pete Dashwood

2007-07-07, 9:56 pm

<docdwarf@panix.com> wrote in message news:f6pchs$lia$1@reader2.panix.com...
> In article <5fa056F3avi0vU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> If this has been said before I commented, Mr Dashwood, then it might have
> been called predicting; as it comes afterwards it... might now.
>

:-)

>
> Perhaps it might be more advantageous to see if something might better be
> found to occupy your time, Mr Dashwood... after all, you're a busy man,
> remember?
>
All too well aware of that old chum. Normally, I'd post here as a welcome
break from some very intense and stressful stuff that is occupying me at the
moment.

As it isn't fun any more, I'll look at finding another outlet. (Cheers all
round...:-))

Pete.

Pete Dashwood

2007-07-07, 9:56 pm

"LX-i" <lxi0007@netscape.net> wrote in message
news:fP2dnRd8gMxahQ3bnZ2dnUVZ_s2vnZ2d@co
mcast.com...
> Richard Brady wrote:
>
> Don't sweat it. You should have been here when the debates over periods /
> full stops were raging... :) There are also some personality conflicts,
> as with any group of folks. IMO, I think the term "lame" may have been
> what set it off...
>
That was certainly a contributing factor.

Nevertheless, I could have behaved better... just ran out of patience.

Thanks for your post, Daniel.

Blessed, indeed, are the Peacemakers... :-)

Pete.

2007-07-08, 7:55 am

In article <5fatorF3b7tnjU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:f6pchs$lia$1@reader2.panix.com...

[snip]
[color=darkred]
>
>:-)

Glad you enjoyed... and my apologies for the typographic error, the last
word I posted should have been 'not' instead of 'now'.

>
>All too well aware of that old chum. Normally, I'd post here as a welcome
>break from some very intense and stressful stuff that is occupying me at the
>moment.

That there is stress *somewhere* in your existence, Mr Dashwood, might be
apparent, at least by some interpretations of the responses you've shown
here of late.

>
>As it isn't fun any more, I'll look at finding another outlet. (Cheers all
>round...:-))

'Fun' is in the mind of the beholder... and it is difficult to escape the
village in the pack that one carries on one's back. To search the
archives - if such a thing is polite - yields
<http://groups.google.com/group/comp...d3?dmode=source>

--begin quoted text:

Here's a story for you...

Are you sitting comfortably? Good. Then I'll begin....

A traveller approaches the Gates of a great city.

He sees an old man, dressed in rags, sitting in the dust, warming his
ancient bones in the hot sun.

The traveller addresses the old man...

"What are the people in this City like?"

"What were the people in the City you came from like?"

The traveller shudders at the memory.

"They were awful. Mean, money-grubbing, unkind, impolite, unfriendly,
unhelpful, a real bunch of nasty no-hopers. That's why I left..."

The old man nods gently and says:

"I'm afraid they're just the s