Joined: 28 Jan 2012 Posts: 316 Location: Room: TREE(3). Hilbert's Hotel
It is a simple JOINKEYS with JOIN UNPAIRED,F1 and a REFORMAT statement (entire F1 and the new value from cross-ref file and ?), and couple of IFTHEN statements to BUILD the desired output.
To reorder file in original order after processing - Use SEQNUM before the JOINKEYS in file 1, do the join, sort on the sequence numbers.
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
After seven years you don't know the difference between JCL and Sort? Moving to DFSort.
Also, you should know by now that you present data etc within code tags.
changed the card as below and its working now.. the only issue now is it does not presevres the original files(F1) order... Is there any way we can preserve the order.
If your input 'keys' are already in the order you need, you can add SORTED on your JOINKEYS statement, which tells *SORT to not sort the data in 'FILE' mentioned.
OR
A lengthy-inefficient approach, but will get the job done: pad a sequence number to the dataset whose records you donot want SORTED, using INREC coupled with a JOINKEYS CONTROL statement. Now, replace your OPTION COPY with a SORT FIELDS on the sequence number you added earlier; drop these sequence numbers in your BUILD statements.
Joined: 28 Jan 2012 Posts: 316 Location: Room: TREE(3). Hilbert's Hotel
Abid Hasan wrote:
A lengthy-inefficient approach, but will get the job done: pad a sequence number to the dataset whose records you donot want SORTED, using INREC coupled with a JOINKEYS CONTROL statement. Now, replace your OPTION COPY with a SORT FIELDS on the sequence number you added earlier; drop these sequence numbers in your BUILD statements.
Why this is a lengthy-inefficient approach, if datasets are not already sorted?
Imho, second approach is lengthy and inefficient When compared to the first approach.
Note that the output will be sorted again on the sequence numbers - which can be avoided altogether if addition of SORTED,NOSEQCK 'IS' getting the job done.
Any new instruction added, which causes the data to be parsed more than once is bad. If SORTED is not added, data will be sorted by JOINKEYS come-what-may - unless we tell it not to; the sequence will not change because of SEQNUM - BUT data will be sorted. It will be sorted again just before the OUTFIL processing - which is at least 2 passes of data, now if user has a mill. and above records - Bad.
Susanta, please check you joinkeys, looks that's you have a flip flop plus it should be 8 byte per your original post, please read some dfsort documentation at the top of this page there is a link which will answer your question on how to preserve the sort order of file1 in output. However Abid has told you the Hint so follow that.
SYNCSORT, should be following DFSORT's most of the function so that info should help from documentation.
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
Susanta,
If your Syncsort/MFX version allows (>=1.4.2 IIRC), you can make use of the "?" operator in the REFORMAT statement to know if the reformatted record is a matched record or an 'F1 only'/'F2 only' record, and get rid of the '$' FILLing logic. "?" will return any of these 3 possible values - 1,2 or B indicating if it is an 'F1 only' record, 'F2 only' record or a matched record respectively.
Thnaks All for the suggestions, i corrected the F2only to F1ONLY.
Also i have used SEQnum to solve ordering issue.kept 10 byte for seqnum.
Now the issue is .. i need the final o/p to be similar to file F1 in structure , i mean LRECL as 90 . But it fails when i put lrecl as 90 in the F1ONLY dd card.
i had to put lrecl as 90 + 55 . in this way i have to add one more step to discard extra bytes from the final o/p file. can it be solved without using any further jcl step.
.. i need the final o/p to be similar to file F1 in structure , i mean LRECL as 90 . But it fails when i put lrecl as 90 in the F1ONLY dd card. ...
Why specify the DCB/LRECL at all, let *SORT decide it for you. The BUILD statement here is the one deciding the output dataset's LRECL, so till the time the LRECL calculated in BUILD corresponds to what is specified in the DCB information, you're good, else an error; revisit the BUILD statement, correct it to fit your requirement, if 90 bytes is needed, and your actual output data is only - say 50 bytes, simply add a '90:X' in your build, which says add a space at 90th byte, this will force the output dataset's LRECL to be of 90 bytes; this is just one of the many ways of forcing a LRECL via a *SORT card.
To start with, your BUILD statements are inconsistent in terms of length. First points to 90, second - 10+14+64 = 88.
Look at the SYSOUTs generated by *SORT, they clearly point out the various stages of *SORT alongwith the phase wherein the length was calculated, you should be able to see how a 145 came up there.
if not then, please share the JCL and the SYSOUT here.
Hello NicC, the problem will keep coming unless the length is handled explicitly as tested by Pandora/Mr. Woodgar in the earlier tagged post; at least for SYNCSORT.
Aside, Susanta, for a VB dataset, you add 4 to the already specified start-of-data positions; for example, from: FIELDS=(11,14,CH,A) , 11 changes to 15; from FIELDS=(2,14,CH,A), 2 changes to 6; and so on. Play around with it a bit, and you should be able to work it out. There are hundreds of examples for this available on the forum as well as the good ol' web (if the manual is not around).
Do confirm if the information from the link shared and stated by Mr. Raj a few posts earlier was helpful in to resolving the issue, because your last sort-card doesn't show any changes.