Juxtapose - if you have a group of records that aren't easy to tell they're associated, make it so they are.
Okay, makes sense. This particular approach with the PICKs in the "c100" sub-pipe allows only records that lack certain content, rather than the overarching goal of removing entire groups of records based on content in one or more records. But this adjusted version does remove entire groups of records based on content, though I’m not sure if it’s as clean as can be. What do you think? "PIPE (end ? name querypath listerr)", " CP QUERY PATH 0-FFFF", "| nfind _______________________Legend", /* No Legend line. */ "| c100: fanout ", "| pick w1 == /Device/ ", "| specs w2 1.4 /;/ n ", /* Make temp header: "0291;" */ "| j800: juxtapose ", /* "0291;Device 0291, Status QUIESCED; CHPIDs to..."*/ "| join keylen 4 ", /* Join same rdevs. */ "| c200: nlocate /Status ONLINE/ ", /* Filter out working rdevs.*/ "| f300: faninany ", "| not chop after str /;/ ", /* Get rid of the temp header.*/ "| split after str /;/ ", /* Back to multi-line output.*/ "| strip trailing str /;/", "| console ", "? c100: ", "| j800: ", "? c200: ", "| locate /-/ ", /* Keep any ONLINE rdev who have offline CHPIDs.*/ "| f300: " --Shawn S. -----Original Message----- From: CMSTSO Pipelines Discussion List [mailto:CMS-PIPELINES@VM.MARIST.EDU] On Behalf Of Hobart Spitz Sent: Thursday, March 23, 2017 2:11 PM To: CMS-PIPELINES@VM.MARIST.EDU Subject: Re: [CMS-PIPELINES] Pipethink and filtering. CP QUERY PATHS 0-FFFF Correction: /*---------------------------------------------------------- ----------------- c100: j800: +--+ +----+ +-+ +-----+ +-+ +----+ +---+ +----+ +---+ |cp|-->|drop|-->|p|-->|specs|-------------------->|J|-->|pick|-->|...| -->|sort|-->|...| +--+ +----+ |i| +-----+ |u| +----+ +---+ +----+ +---+ |c| |x| |k| +----+ +----+ +-----+ |t| | |-->|pick|-->|pick|-->|specs|-->|a| +-+ +----+ +----+ +-----+ +-+ ------------------------------------------------------------ ---------------*/ "pipe (end ? name querypath listerr)", "? cp query path ", "| drop last 1 ", /* No Legend line. */ "| c100: pick w1 == /Device/ ", "| specs w2-4 1.25 ", "| j800: juxtapose ", "| pick w3 \== /ONLINE/ ", "| .... ", /* Do some processing here. */ "| sort f1 ", /* Back to original order. */ "| .... ", /* More processing */ "? c100: ", "| pick w1 \== /Online/ ", "| pick w2 \== /Available/ ", "| specs recno 1.8 right 1-* nf", "| j800: ", On Thu, Mar 23, 2017 at 3:04 PM, Hobart Spitz <orexx...@gmail.com<mailto:orexx...@gmail.com>> wrote: > At first blush, I think this is a job for JUXTAPOSE. > > Assuming you're working with something like this: > > Device 0192, Status ONLINE > CHPIDs to Device 0192 (PIM) : 11 12 1A 22 30 40 > Physically Available (PAM) : + + + + + + > Online (LPM) : - - + + + - > Offline by Authorized User : + - - - - - > Offline by Control Unit : - + - - - + > Legend + Yes - No > > > I would try: > > /*---------------------------------------------------------- > ----------------- > c100: j800: > +--+ +----+ +-+ +-----+ +-+ +----+ +---+ +----+ > +---+ > |cp|-->|drop|-->|p|-->|specs|---------->|J|-->|pick|-->|...|-->|sort| > -->|...| > +--+ +----+ |i| +-----+ |u| +----+ +---+ +----+ > +---+ > |c| |x| > |k| +----+ +----+ |t| > | |-->|pick|-->|pick|-->|a| > +-+ +----+ +----+ +-+ > ------------------------------------------------------------ > ---------------*/ > > "pipe (end ? name querypath listerr)", > "? cp query path ", > "| drop last 1 ", /* No Legend line. */ > "| c100: pick w1 == /Device/ ", > "| specs w2-4 1.25 recno 26.8 right x05 n ", > "| j800: juxtapose ", > "| pick w3 \== /ONLINE/ ", > "| .... ", /* Do some processing here. */ > "| sort f1 ", /* Back to original order. */ > "| .... ", /* More processing */ > > "? c100: ", > "| pick w1 \== /Online/ ", > "| pick w2 \== /Available/ ", > "| j800: ", > > RECNO ensures that all records return to their positions within the group. > > The output from JUXT will look something like this: > > 0291, Status ONLINE 1*tab*CHPIDs to Device 0291 > 0291, Status ONLINE 2*tab*Offline by Authorized User > 0291, Status ONLINE 3*tab*Offline by Control Unit > > > > > On Thu, Mar 23, 2017 at 1:33 PM, Stanislawski, Shawn (National VM > Capability) <shaw...@hpe.com<mailto:shaw...@hpe.com>> wrote: > >> Been working on developing my Pipethink, but this scenario has me >> stumbling. >> >> Taking "CP QUERY PATHS 0-FFFF" and filtering so that only those with >> potential problems (those who are NOT: "status ONLINE" AND "show a '+' >> for every CHPID") get output to console. >> The more I poke at this, the more complex it gets. >> >> "CP QUERY PATHS" , according to the HELP file: >> - Each output has from 5 up to and including 12 records/lines total. >> - Each of the potential lines is a known template, and the first four >> are always present and always the first four. >> - The only record I don't really care about is the "Legend", which is >> always the last record in each output. >> - In the first record of each output, the "Status xxxx" could have 1 >> of 8 conditions for "xxxx". >> - Records/lines 3-11 (inclusive) could contain either a "+" or "-" >> for each CHPID (up to 8 total). >> >> If I'm just starting out by 'PIPE CP QUERY PATHS 0-FFFF', then I get >> a QUERY PATHS output for each device successively. >> >> The first problem is: >> How can I keep these successive outputs in order, but still work with >> each output as a group when the number of records in the individual >> outputs is variable? >> >> My first thought is to use JOIN so I can then filter the groups of >> records based on criteria. But I only know with certainty the first >> and last records of each output group, the number of records is >> variable in each group, and there doesn't seem to be any easy way to >> otherwise distinguish one group from the next. >> If the JOIN stage could accept a from-label and a to-label that would >> solve the issue, so a user-made stage could be one solution. But I >> feel like there's got to be a better solution using just the built-in >> stages... >> >> I've found an imperfect solution by reducing the outputs to just >> their first 4 lines using an ALL stage and then a "JOIN 3". >> I know BETWEEN/INSIDE would be better, but no idea how I'd JOIN in >> that case... I'm really trying to avoid a "JOIN *". >> >> Any thoughts? >> >> --Shawn S. >> > > > > -- > OREXXMan > -- OREXXMan
