Expected Output:
----+----1----+----2
GRP3 RAM
GRP3 SAM
I need to copy all records from File 1 (Based on group, Field pos - 1,4) if a matching record for that group is found in File 2 (Field pos - 10,14) to an output file having the content and layout same as File 1.
File 1 may contain duplicate records (based on the matched field pos 1-4)
File 2 contain unique records (based on the matched field pos 10-14).
seahawk789,
Since you wanted your output in the format of FILE1 (VB), reformat statement here creates variable length joined record which in this case is a Variable length record from FILE1.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Looking at the other cards, F1 looks like the first file. 1,4 is the Record Descriptor Word for the file (first half-word contains record-length) and 5 is the start position of your data, with no "length" provided defaulst to the length of the current record.
So, hopefully, your output record is a complete copy of the record from your F1 input.
You have to, explicitly, or implicitly, include the RDW for building a variable length record, although the sort will control the value of the record-length itself. Since it is nothing to do with your data, to my mind it is much clearer sqlcode's way (1,4,5) than (1), which you might be able to get away with, or (1,20,21) (or whatever, "merging" the RDW with some real data).
However, you can check in the manual as well, link at the top of the page.
If you want to make it clearer to help you rememember, maybe look at SYMNAMES.
(F1:FILE-RDW,FIRST-BYTE-OF-DATA-TO-END-OF-RECORD)
as long as the two names are define correctly in SYMNAMES.
Never done this, but I hope it is somewhere close :-)
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
On a poorly-chosen example, because it has only one data field, I was trying to highlight that it is better to seperate the RDW from any data definition.
Chapter 3. Using DFSORT Program Control Statements, INREC Control Statement wrote:
For variable-length records, the first item in the BUILD or FIELDS parameter
must specify or include the unedited 4-byte record descriptor word (RDW),
that is, you must start with 1,m with m equal to or greater than 4. If you want
to include the bytes from a specific position to the end of each input record at
the end of each reformatted output record, you can specify that starting
position (p) as the last item in the BUILD or FIELDS parameter
As a better example (well, better is the wrong word, because the one I chose does not work)
Code:
(F1:1,4,5,20,30) is better, from the point of view of ease of understanding, than
(F1:1,24,30)
To me, even better is with the SYMNAMES. The "Tricks" gives a method to generate SYMNAMES from a Cobol record layout, and SYMNAMES are far from difficult to code by hand either.
The example following the paragraph I quote above is worth looking at to see another way, to me, of making the code look better. Unfortunately I had great problems trying to get it into the Code Tags, so look it up yourselves, please.
Now, how to get the TSOPs to code this sort of stuff from the examples given to them. Perhaps withold the most vital statement until the rest is "smartened up"?
OK, so won't work. But it would make theirs, and their colleagues', and their operators' lives so much easier. 3am phone call. "Dave, can you read me the first line in the SYSIN member?", "Yes, there's lots of numbers and commas"..... "Can you change that to "20,5" and try the job again?"... "What do you mean, it failed? Read the line to me. Where's the first bracket? Yes, I mean the bendy-thing. You typed over it?....."
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
(F1:1,4,5,20,30) is better, from the point of view of ease of understanding, than
(F1:1,24,30)
Oh, now I understand the point you were trying to make. I agree that for ease of human understanding, it's better to treat the RDW as a separate field, although DFSORT doesn't really care which way you code it.
