Have a File, when the field (131-150) shown below in the example (record #4 in the example) has the value spaces, the previous record in the file needs to be changed. In the previous record, at column 881 or 882 or 880, if the string has the value as 'MORE'it needs to be replaced by 'LAST'. This needs to be done via JCL, can this be done via JCL?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Can you show some clearer sample data and expected output. It doesn't need to be your actual data, but it must reflect the relationship of your actual data.
when posting data and code use the code tags
they force the use of a fixed pitch font and preserve the spaces,
making things more understandable for people who spend their time helping
a) If a record has spaces from 4-13th column, and the 21st or 22nd column of the previous record has the value >>>'MORE'<<<
b) The previous record's string >>>'MORE'<<< needs to be changed to >>>'LAST'<<<. This is only specific to the previous record for the record which has columns 4 to 13 as spaces.
output would look like below.
Guess this topic needs to be transferred to syncsort. As I cannot use dfsort and icetool in my office. Can we do that ? . I am not sure how to transfer the topic from one page to another.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
OK, that's much clearer.
You can use JOINKEYS with the same DSN for both input files. By specifying, in the JNFnCNTL files, offset sequence numbers for the records, it means you can get to look at the "current" and "previous" records at the same time. Here's a discussion.
You can only just get this to work, as your LRECL is two bytes short of the maximum for a VB in DFSORT. You will have to make a "flag" out of your key.
You will need a variable-length REFORMAT record. Something like:
Code:
REFORMAT FIELDS=(F1:1,4,F2:1,1,F1:5)
That would prepend your flag to the data from your variable-length record.
You test the flag (which would be 5.1 on the REFORMAT record) and make any required adjustment. Then use BUILD=(1,4,6) to output your record.
In your case, you'd need the "next" record to have a lower sequence number than the "current" record.
Your LRECL is very inefficient for DASD. Is your data on tape, or only a small volume?
Actually my record format and length is VB , 32754. I showed that example just for a better understanding. understood the JOIN KEYS part for comparison. Still I am not sure of how to change the string of the previous record. >>>"MORE"<<< to >>>"LAST"<<<<
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I think I covered the huge VB part in the previous post.
In the Main Task of the JOINKEYS, use INREC with two IFTHEN=(WHEN=(logicalexpression) to test for your MORE in two different places and use OVERLAY to put the LESS in their place.
This represents your data:
Code:
A
B
C
D
The JOINKEYS will give you this (assuming you get the sequence numbers correctly offset):
Code:
- A
A B
B C
C D
D -
You JOIN with UNPAIRED,F1
The second column above is a representation of the "flag" you have to create in JNF2CNTL. A flag for record A, which will be ignored. A flag for record B, which will be available at the same time as record A. Do your test on the data for record A and the flag and do the OVERLAY if necessary.
You need to arrange the final BUILD to drop the flag. Simplest could be to use OUTREC BUILD=(1,4,6)
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Wow. That's sorting all the data, twice, and making it fixed-length 1009 bytes long. What happened to your 32000+ LRECL? Your FINDREP goes for longer than would be necessary from what you have said. What's the INCLUDE for? You never mentioned dropping any records. What do you need the ID for?
If your data is small enough so that you don't mind the two SORTs, at least extend the records "at the front" so you can keep them variable (and avoid rubbish appearing, and avoid S0C4s, perhaps).
a) the output file can only have max of 9500 records at the time, therefore used 10,000 although the output file can hold 32000 records.
b) dropping was a new requirement added today, unfortunately.
c) findrep just to make sure I have extra comfort, for finding the MORE tag just in case.
sure I will extend the records.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
The LRECL is the maximum bytes per record (including the mandatory four bytes for the RDW if the records are variable-length). It is nothing to do with the number of records on a file.
You have an LRECL of 32000+, which represents the maximum record-length, which, if correct, implies that you are/will truncate records. If it is not correct, make the LRECL correct, as it is wreaking havoc with you space allocation if the dataset is on DASD.
As long as you can't get any "false hits", the FINDREP is OK. But if a surname happened to follow your original up-to-three, then MORETON in the surname would become LASTTON.
That'll get you RDW, 10-digit sequence number (so allowing for up to 9,999,999,999 records) and then from byte five to the end of the current record.
After the SORT, you do longer need the sequence number field, so you can re-use that for your SEQ from the GROUP. With SEQ=1, remember that having more than 10 records in a group can be problematic. Specifically 12, or 22, or 32. You get to see why?
To return the record to its original form (with changes if necessary) will be BUILD=(1,4,15). Also remember to further offset your fields by the length of the extension.
