On 3/26/2014 6:24 AM, Tony Thigpen wrote:
Just to be clear, I really do understand, and respect, your feelings.
It's a tool you would like to continue using because you are familiar
with it.
My opinion is just that, my opinion. And, in my shops I can enforce my
opinion. :-)
I was not criticizing the port, just tying to explain why it might not
be of interest to many mainframe programmers. And why nobody bothered to
download it. By saying why I was not interested in it.
Now, as to COBOL, we normally deal with non-text based numbers.
Everything in the file is stored packed or binary, not as text. Once it
is passed the "input program", the only need is to convert it back to
text for reports. And we have simple PIC clauses to hand that conversion.
As to the "input program", these have traditionally worked with input
fields that do not have all the dashes, commas, and such. We started
with keypunches (where the special characters were removed by the
keypunch operator). We then moved to BMS screens (for CICS) where CICS
had a built-in de-edit function. (Of course many shops wrote their own.)
But, even then, we normally expected the return value to be just digits.
Even as we move from CICS to Web, it's still under CICS with the
existing tools already in place.
We have been working this way for 30+ years. Regular expressions is
relatively young.
Do we need regular expressions in COBOL? I don't think so. Can you, and
others, continue to try to evangelize about regular expressions? Yes you
can. Maybe, some day, I will change my mind. I just doubt it. :-)
Maybe you should start a thread: Why COBOL needs Regular Expressions.
Tony Thigpen
I actually started experimenting with this a couple of
years ago. Since COBOL is LE based and you can call C
functions directly from COBOL, I did some work with the
C functions 'regcomp' and 'regexec' - calling them from
COBOL programs.
The goal was to match strings based on patterns, of course.
Since modern COBOL has so many new capabilities I was
thinking of doing dynamic dataset allocation based on
patterns in DDnames, analyzing text coming in as replies
to a dialog (maybe in a COBOL CGI), etc.
But I never had the time to get it working to my satisfaction.
And, of course, no one was asking for it.
If anyone is interested in getting my eight COBOL programs
that are experiments (nothing works quite right, I don't
think, but they provide a starting point), if you promise
not to make fun of my rudimentary code, I'd be happy to
ship them to you. Good to find a home for them.
Kind regards,
-Steve Comstock
-----Original Message -----
From: [email protected]
Sent: 03/26/2014 07:54 AM
I share your sentiment about vi which I consider to be a bug, not a
feature. I agree that there could have been a better way to do
pattern matching. The reality is that there are alternatives for vi,
ranging from ISPF all the way to Notepad++ and many options in
between, but in the same reality, if you need to do serious pattern
matching, and I need to do it all the time, there is no viable
alternative. The regex methodology is the one that took an hold on
the world and became the Lingua Franca, the de-facto language of the
trade.
I came to the world of pattern matching when this was already a fact
of life with I real chance to change it.
Now, the reality is also that the only major programming languages
that do not have access to regex functionality are COBOL and PL/1.
All other major languages have this capability. And it is that
deficiency that I intended to resolve . I am encouraged by those who
expressed more positive feelings and will continue to push it.
ZA
