Hi Rob.
No, its the START records and the matched LUs which are getting combined. The
rejects actually feed into another filter stage.
The START records can't actually be relied upon to appear before the LU names
but there are millions of records here coming off tape so I can't buffer them
and, in truth, finding just the ones that occur after is "good enough" for
this application.
So I end up with a pipe like the following, which gets:
PIPSCA047E Label y is already declared.
PIPSCA192I ... Scan at position 289; previous data "24 start000 A |y:".
'pipe (end ?)',
' < ' fn 'other' ofm,
'|start: nlocate 41.5 ,START, ',
'|nstart: faninany ',
'| elastic ',
'|l2: lookup 18.8 detail', /* details in; matches on luname, write
detail records */
'|y: faninany',
'| >' fn ' startlu ' ofm,
'?start:',
'|0000: nlocate 33.4 ,0000, ',
'|nstart:',
'?0000:',
'| >' fn 'start000' ofm,
'|y: fanout',
'|l2:', /* masters in; unref details out */
'| >' fn 'nstartlu' ofm,
i
------ Original Message ------
Received: 04:34 PM COT, 07/13/2009
From: Rob van der Heij <[email protected]>
To: [email protected]
Subject: Re: Pipeline fanin problem
> On Mon, Jul 13, 2009 at 11:01 PM, Ian S.
> Worthington<[email protected]> wrote:
>
> > What I don't appear to be able to get right is the trivial bit: Files
STARTLU
> > and START000 need to be fanned together into a single file, but all my
> > attempts to do so seem to end in label redefinition hell. Anyone care
to
> > restore my sanity?
>
> I think you're trying to write the same file "startlu" from 2
> different streams, so that's probably not what you want. And merging
> the matched records and unmatched records in a single stream does not
> make sense because the lookup would not serve a purpose... but in
> general you could do something like this:
>
> ..
> | k: nlocate .. /* divert key records */
> | i: faninany
> | buffer
> | x: lookup .. detail
> | y: faninany
> | > output file a
> \ k: /* prolly key records */
> | z: nlocate ..
> | i: /* but not these */
> \ z: /* really keys */
> | x:
> | insert , not found , after
> | y:
>
> Depending on the order of the records (if the key is before each of
> the details that match it), you might also enjoy feeding the keys in
> the tertiary input and avoid the need for the buffer stage.
>
> Another interesting approach could be to use 'autoadd' (which will
> reject the first one with that key, and match subsequent ones) and
> then inspect those rejects for being proper masters. Does that make
> sense ?
>
> Rob
>
