Martin wote: >I'm not familiar with FANOUT but if it writes a record to, say, two destinations, it's got to copy one of them.
Actually not. I know it sounds like magic, but there is still only one copy. I'll give you my best rendition of what I think is happening. Don't worry if you don't get the whole picture. I had to work with Pipes for many years before I understood this. Pipes manages the storage for records. When a new record is created (or modified) Pipes allocates the space for it. That pointer is what a stage gets when it asks for an input record. When an input record is no longer needed by a stage, Pipes is informed. This is referred to as "consuming" the record. In fact, the record is not "consumed", as in grinding with teeth and digesting, rather it is how a stage tells Pipes that it's done with the record. Changes are made to new storage at a new record address. Changing a record means getting new storage and building a new record, with the changes. The input record is not changed, and it can be inspected by other streams via FANOUT or any multiwrite stage. When the storage area of a record is no longer used by any stage, i.e., no stage has a pointer to it, that storage can be reclaimed by Pipes. I don't know the exact mechanism, but that's it at a high level. No matter how many streams and stages use a record, there is only one copy. DUP, for example, could just write the record over and over using the same pointer. (I don't know that for a fact, but John Hartmann is a lot smarter than I.) The majority of Pipes building stages do not modify their input records. (With REXX user written stages, there always is a new copy on output, even if no changes were made to the data.) OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. IBM has been looking for an HLL for program products; REXX is that language. On Thu, Sep 23, 2021 at 9:44 AM Paul Gilmartin < 0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 23 Sep 2021 09:30:43 +0100, Martin Packer wrote: > > >I'm not familiar with FANOUT but if it writes a record to, say, two > >destinations, it's got to copy one of them. > > > It could be deferred; Copy-on-Write, optimizing for what Hobart earlier > calledd the "typical case" of stages that don't modify the data. > But incurring the complexity of a responsibility count. > > > >From: "Hobart Spitz" > >Date: 23/09/2021 04:18 > > > >> I'm guessing the atypical case is a stage such as FANOUT which > >> necessarily copies the data. > > > >Not sure what you mean by atypical. > > > I apologize; I trimmed your earlier mention of "typical case". > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
