Sir Rob has seen through my subterfuge to get the PIPSYSF and the grep
stages into the conversation; well played, Sir! :-) And he is of course
correct that a grep approach is not appropriate for solving this
problem. I much prefer his LOOKUP ideas.

While I have had positive results in my (very limited) use of the grep
stages in PIPSYSF, if the Master Plumber says that they are not ready
for prime time, that is good enough for me. I will withdraw my RFE to
include PIPSYSF into the main Pipelines distribution, then, as well.
Now, of course, I will have to cast about to find somebody else to annoy
here.....:-)

Take care, all.
DJ


---
BEST REGARDS

   DAVE JONES
    Managing Director for zSystems Support, zLinux, and Cloud
    ++1 281.578.7544 (Cell)
    Web: www.itconline.com
    18502 Purdy Ct. Houston, TX  77084  USA

On 01.23.2022 1:52 AM, Rob van der Heij wrote:
Diverting the thread ...

On Fri, 21 Jan 2022 at 16:14, Dave Jones <djo...@itconline.com> wrote:

Hi, Peter.
When I see a task like your's "need to check this message for either
of
the strings below", I think about using grep. Several versions of grep
(egrep, fgrep, and ggrep) are supported by CMS Pipelines in the
PIPSYSF
package. If you would like to give it a try, grab it from here:
http://vm.marist.edu/~pipeline/pipsysf.html
The package also comes complete with some nice documentation.

Of course, I expect to see Sir Rob pointing out that the lookup stage
can be used as well in this thread soon. ;-)
Good luck.
DJ


Dave, I understand and appreciate your persistence to have the good
parts
of PIPSYSF in the main pipeline, but I don't think grep c.s. are the
way
here.

I think the habit of grepping messages has its roots in a world without
well-defined message identifiers where you try to match some of the
phrases
and retrieve the actual values in the process. In our case, most
messages
have a message identifier and let you dismiss or divert them. That's a
very
simple word lookup. It also means you don't miss any new important
messages
because they look like something mundane.

Both LOOKUP and GREP have an initial cost, either to sort the
references or
to compile a string matching algorithm. That's normally a waste if you
only
need to parse a single message. If you use PROP, then you'd have
routing
table entries for the most popular ones, and invoke some generic
catch-all
routine for the ones you didn't expect (if you don't want to simply
pass
them to the logical operator).

Now I wouldn't be surprised if PROP uses a very simple approach to test
a
message against the routing table (and we used to put the most frequent
ones at the top for that reason) but I likely would write a pipe-based
one
instead using LOOKUP and DEAL to pass messages through a pipeline
refinery.

PS I think if we want GREP and friends in CMS Pipelines, we also want
to
have something to extract the parsed phrases. Simply knowing that it
matched your search pattern is probably not enough to do something
useful
with it.

Rob

Reply via email to