Steve
Nobody will make fun of you... I am now an expert in that stuff and I still 
make mistakes because, let's say it as it is, dealing with C could be, mmm.... 
tricky.

Please send me your code since, as I've stated earlier, I am contemplating on 
creating a bearable user interface for that in parallel to my work on PCRE.

Thank you 
 
Ze'ev Atlas 




________________________________
 From: Steve Comstock <[email protected]>
To: [email protected] 
Sent: Wednesday, March 26, 2014 9:03 AM
Subject: Re: Another Article On Lagging Mainframe Skills
 

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
>>

Reply via email to