OUTFIL's Trailer1 has counts and aggregates that can find use as a Header1 (which doesn't have the same counts for obvious reasons), but how to do it?
What I'd like to do is to take an input dataset, get counts, etc., then put a record of those counts as the first record.
My best thought at the moment is to read the input file and write just the Trailer1 record to a temporary dataset, then to Merge this sole record dataset with the original file. This would take two steps - one with a COPY and OUTFIL, and another with a MERGE: can it be done better, especially in just one step?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Jim Alton wrote:
OUTFIL's Trailer1 has counts and aggregates that can find use as a Header1 (which doesn't have the same counts for obvious reasons), but how to do it?
What I'd like to do is to take an input dataset, get counts, etc., then put a record of those counts as the first record.
My best thought at the moment is to read the input file and write just the Trailer1 record to a temporary dataset, then to Merge this sole record dataset with the original file. This would take two steps - one with a COPY and OUTFIL, and another with a MERGE: can it be done better, especially in just one step?
If you just want original file, with a header at the front, one possibility which avoids another pass of the data is just to use "concatenation" to deal with the "file" (treat it as a "virtual file" consisting of two physical datasets). If your data is "huge", this may be effective. For smaller amounts of data, you might not want (or be able to have due to standards, audit requirements, whatever) this approach due to the extra "complexity".
JOINKEYS with the same file as the two inputs will be able to do what you want, using SUM in one of the CNTL files, but requires a SORT of the data.
To use MERGE your data needs to be in sequence on a key, and that key has to be "lowest" for your header. You can use INREC and OUTREC if you need to "fake-up" a key.
If your data is not in sequence, you can use JOINKEYS to insert the header.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
Jim Alton wrote:
This would take two steps - one with a COPY and OUTFIL, and another with a MERGE: can it be done better, especially in just one step?
As Bill pointed out there is a trick to get the count of records as the first record using a single step of JOINKEYS with just a COPY operation. You don't have to perform SORT.
Thanks for your reply and the suggestion that JOINKEYS will satisfy my need (I'm not familiar with JOINKEYS so will have to learn about its functionality that will achieve this) but I don't understand your first suggestion:
Quote:
If you just want original file, with a header at the front, one possibility which avoids another pass of the data is just to use "concatenation" to deal with the "file" (treat it as a "virtual file" consisting of two physical datasets). If your data is "huge", this may be effective. For smaller amounts of data, you might not want (or be able to have due to standards, audit requirements, whatever) this approach due to the extra "complexity".
What are you concatenating and treating as a virtual file? And what is a virtual file - how is it created and manipulated?
In the first example, the header was written, then all the data copied to it.
With the second, the header was written, but then a simple concatenation in the JCL gets you the entire input, although it consists of two DSNs.
It is my invention to call it a "virtual" file, not a specific terminological meaning.
If you have 732,000,000 records, this can save a bit of processing, at the expense of making the JCL (not very much) more complicated. Some site standards and audit requirements may not allow this.
For "small" (a relative term) volumes of data someone may argue that the additional "complexity" outweighs the saving.
My experience with Auditors is that they like all the data that is part of the same file to be in the same file.
It is an option, and something to be seriously considered for large volumes. Avoids extra DASD usage and lengthening of the Critical Path as well as the 250-365 times a year processing cost just to get that header at the front.
I see what you're getting at - either you do further processing on the merged (not necessarily DFSORT MERGEd) file or you don't merge and try to continue processing with the files as a concatenation.
Regarding the worth or need of performing this process, in my installation, special (small) programs have been created to provide in a header record the counts that are found in the Trailer1 record.
Talk of virtual files threw me a bit. If you had instead de-virt-ed from the virtual you would have come up with dual.
.jpg)
