So what you're saying is that we need a 'lookup' stage for other environments/platforms, presumably including all the other stages from that "doctor's bag" of remedies and the record-oriented and multi-stream capabilities which make it all work.
Sounds good! -- R; <>< On 1/23/22 13:20, Dave Jones wrote: > 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 <[email protected]> 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 -- -- R; <><
