On Fri, 2 Sep 2016 19:53:28 -0500, Paul Gilmartin <[email protected]> wrote:
>On Fri, 2 Sep 2016 18:48:41 -0500, Bill Woodger wrote: >> >>... It would not be nice ... [to] ... replicate what is already available in >>DFSORT and which would be used for the sequential datasets anyway (would >>there be benefit in piping those just for the heck of it?). >> >(I hope I haven't altered the sense by massive trimming.) > >That presumes that all useful filters already exist in DFSORT (which might be >pretty >close, but REPRO appears to be a refutation) or don't already exist elsewhere >and can't >be coded in another language more readily than as DFSORT commands. > >>Just to note, the two tasks which process the two inputs to JOINKEYS >>effectively "pipe" to the main task. >> >I didn't know about that. How does JOINKEYS interact with the exits? > >Thanks, >gil I'm not sure what you mean by referring to REPRO as a "filter". It copies dataset (data set) to data set. There are limited means of controlling what is selected for output. If a pipe can be a data set as far as IDCAMS is concerned then you could pipe. As far as I know, you need to run IDCAMS and tell it that you want to use REPRO. I don't think there's a way to invoke REPRO outside of IDCAMS. IDCAMS obviously knows a lot of specific detail about "VSAM". DFSORT is less specific with input. Being specific, IDCAMS (using REPRO) is better at copying actual VSAM data sets to sequential data sets. IDCAMS, as a "filter" (with multiple process which, take input and produces output) in the same way that I think you are referring to something like "coreutils", I don't think works. The output of IDCAMS is the report of what it did in that invocation. Although sometimes you may want to use that as input to a program, usually it is the N files that you just "copied", and they haven't gone to "stdout". OK, treat the listing output as "stderr" but let's consider this, two consecutive REPRO statements in one invocation. How will those "pipe"? To get everything potentially piping to everything else, there's existing "architecture" that you can't just wish away. I don't see how IDCAMS being a separate program with separate control cards in any way "refutes" anything in DFSORT. You need to find a claim of A for something before you can refute it with argument B. You can't make the claim yourself, then have a handy built-in refutation. JOINKEYS uses the E35 output exit in the two sub-tasks processing the input, and the E15 input exit for the main task. Within the control card datasets for the files-to-be-joined you could use an E15 exit (input) but not an E35 yourself. DFSORT has extensive documentation. If you want a quick grasp of these things (JOINKEYS, and the Exits DFSORT provides) they each have a chapter in the DFSORT Application Programming Guide. DFSORT does not try to be IDCAMS, or any DB2 utility, or anything else. It provides sorting, and before or after sorting, there are various manipulations which can be carried out with the data. The abilities that DFSORT has can greatly reduce or obviate the "pre-" or "post-processing" of a dataset, to get it ready for sorting or ready for further processing. Because it is contained within one product, and because things that it does may seem similar or equivalent to things that other things do does not mean "reinventing the wheel" it means a consolidation of multiple external processes into one external process with multiple internal processes. Yes, that is no different to awk not being sed. Yes, a language which seamlessly operates with operating system functions/utilities could be beneficial (as in the potential to be), but even then the multiple syntaxes that the functions/utilities require would be something of an impediment. Other than at the level of "DFSORT has an ADD function, therefore it has reinvented ADD for now useful reason" I don't see how your original point works (yes, hyperbolic to get a concentration on your intent). Chapter 1, Table 2, and its description, gives a very good understanding of how DFSORT operates. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
