On Mon, Dec 22, 2008 at 10:52 PM, Glenn Knickerbocker <[email protected]> wrote: > On Mon, 22 Dec 2008 14:06:26 -0800, Donald Russell wrote: >>I don't quite understand what PAD/NOPAD does... the doc says with >>NOPAD the keys must be the same length to be considered equal. > > You've chosen a combination where PAD will never do anything: column > ranges defined in words, and PAD BLANK. Since a word can never end in a > blank, padding with blanks will never change what does or doesn't match. > > Suppose you had words with an unpredictable number of dots stuck on the > end. Then |LOOKUP PAD . W1| would match up, say, "word." with "word.." > or "word" with no dot.
OK. That makes sense. :-) And illustrates that I "oversimplified" my contrived example. The key in my primary record is actually a specific column range 46-* and the key for the master record I coded as 1-*. The portion of the primary record I'm trying to select on is an MVS file name, while the master records are leading dataset qualifiers. The desired effect being... give me a list of dataset names beginning with HLQ1.Q2. or HLQ3.Q4.Q5 etc It appears LOOKUP can't do that... and that's OK... I can do it with PICK for such a short list of master records in my case. I think Rob suggested, or pointed out the possibility of using, a cascade of LOOKUP stages, each one dealing with same-length keys. That sounds like like an interesting user-stage to write... ABBREVLOOKUP which would read all the records from secondary input, see if they differ in length and build the necessary cascade... > I don't know whether the guts of LOOKUP would make this easy or > impossible, but it sure would be nice to be able to say PAD ANYOF and > specify a list of characters that match the end of the other key (and > maybe a shorthand ANY for ANYOF 00-FF). Even nicer if we could also > PAD LEFT to handle BC's domain-name problem without having to reverse > the records. If I'm understanding this idea.... wouldn't that be what I suggested about giving LOOKUP the ability to use the length of the shorter of two keys and perform the match on the shorter length only. And of course adjusting that length accordingly for each detail record comparison i.e. something like: LOOKUP <key1> <key2> DETAIL ABBREV Where ABBREV means... if <key2> is shorter than <key 1>, then only match on the shorter length. I suppose your option might provide more flexibility, allowing something more "grep-like".... which... perfect introduction to... I was reading about (E|F|G)REP stages... so those sound promising, but won't help me in the short term. I also came across WILDCARD and PATTERN... our version of PIPE doesn't have them. Are those built-in in a newer PIPE version, or just additional stages we could get? Our pipe version is: FPLINX086I CMS/TSO Pipelines, 5741-A05/5655-A17 1.0110 (Version.Release/Mod) - Generated 11 Oct 2005 at 12:04:21
