|
View previous topic :: View next topic
|
| Author |
Message |
Taylortek
New User
Joined: 22 Mar 2008
Posts: 4
Location: Seattle
|
|
|
|
Does NODETAIL have a counterpart? I have a sort sum getting unpacked to displayable data, the outfil has headers, sections and trailers. I want to create a secondary oulfil with just the outrec data. Do I need to create a duplicate outrec layout or is there a directive to supress everything except the detail.
Thanks |
|
| Back to top |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
I doubt it....
I've done what you are doing and I just duplicated the detail info and skipped the header stuff for the second output..... |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| Quote: |
| Does NODETAIL have a counterpart? |
You mean like the hypothetical NOHT? 
No, sorry. That wouldn't really make much sense in terms of syntax. You get the detail records by default, so specifying NODETAIL makes sense. But you have to specify HEADERx and TRAILERx to get header and trailer records, so NOT specifying them is equivalent to NOHT. I guess you're looking for something that relates two OUTFIL statements like INCLUDE and SAVE do:
| Code: |
OUTFIL FNAMES=OUT1,HEADER1=(...),TRAILER1=(...),
BUILD=(...)
OUTFIL FNAMES=OUT2,NOHT
|
So NOHT would take the BUILD from the previous OUTFIL without the H/T.
But unlike SAVE which writes any record not written by all other OUTFILs, NOHT would not be that straightforward - e.g., for multiple OUTFILs with different BUILD operands, which one would the OUTFIL with NOHT use?
At any rate, there's no keyword for that currently and I doubt I'll add one in the future given that you're the first one to ever ask for it and a few seconds with an editor can give you what you need (a copy of just the BUILD operand).
Sorry.
(Probably more than you wanted to know, but I thought some people might be interested in the thought processes involved in whether we consider a new function for DFSORT.) |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Frank Yaeger wrote: |
| (Probably more than you wanted to know, but I thought some people might be interested in the thought processes involved in whether we consider a new function for DFSORT.) |
Not really, but an interesting insight into the process......Thanks.... |
|
| Back to top |
|
|
Taylortek
New User
Joined: 22 Mar 2008
Posts: 4
Location: Seattle
|
|
|
|
| Thanks for the confirmation. Since the parms are usually kept in library members i was just trying to avoid duplicating build statements. Just have to notate that any changes have to be done in 2 spots. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Taylortek wrote: |
| Thanks for the confirmation. Since the parms are usually kept in library members i was just trying to avoid duplicating build statements. Just have to notate that any changes have to be done in 2 spots. |
IIRC, both output descriptions should reside in the same member, making it easy to keep both sysouts equal. At least, that's how I've always seen it done...... |
|
| Back to top |
|
|
|
|
