If you know upfront the maximum field counts and sizes, you could write an E15 exit to move the little variable-length fields into fixed positions in a temporary record, sort those with known offsets, and use an E35 to put sorted temporary records back into the original format.
> Date: Mon, 25 Apr 2011 05:00:12 -0500 > From: [email protected] > Subject: Anyone good with DFSORT? Does DFSORT have the ability to multiply > offsets that are not known until that time? > To: [email protected] > > Hi, > > I have a difficult request from a programmer and I'm not sure about the > answer. > > They have a flat file which has fields that can occur multiple times within > a record, and there are multiple of those fields in the same record. They > want to be able to use DFSORT to overlay (some of) those fields with > specific data, but the offsets change based on how many occurrences of the > recurring fields there are in each record. > > We have no problem if we code the offsets manually, but there are files that > have 15 (or more) of these fields and the number of manually coded "WHEN > IFHTEN=" and "overlay=" cards gets into the several thousands when you have > 10 to 20 occurrences of each field. > > Is there a way to do this with the sort parm logic? I know that the parms > for DFSORT are pretty sophisticated, but the manual isn't written like I > would hope it should be to make it easy to find something like this out. > > for instance if there is a file that is set up as follows: > > > > 2abcdef1ab3abc > > field1o (occurrences of field 1) starts in column1 and is a '2' so there are > two of them in the field (each is 3 bytes long) so "abc,def" > > field2o (occurrences of field 2) starts in column 8 in this particular > record and is a '1' so there is only one occurrence of the field2's and it > happens to be 2 bytes long so it's "ab' > > field30 (occurrences of field 3) starts in column 11 in this sample and is a > '3' so there are 3 of them, each is 1 byte long so it's "a,b,c" > > the problem is that if there is only 1 field1 (instead of 2 in this sample), > then field 2 (because field 1 is 3 bytes long), only occurs one time but > field 2 now starts in column 5 instead of 8, and field3o starts in column 8 > instead of 11 and field3 itself starts in column 9. > > i.e. > 1abc1ab3abc > > there will always be at least 1 occurrence of each field, so the minimum is > '1' in each "occurrence" field > > I know that we can multiply with the sort logic, but after we multiply the > first occurrence field times the length of field1 (2x3=6), plus the offset > past the first occurrence field 6+1=7, "7" is the last byte of field 1, so > the total length+offset+1=8 which puts me on the next field (filed3o, > occurrences of field 3) that I have to do something with. > > My problem is that I don't know that actual offset until execution time via > the math, but I don't know of a way to hold that interim number so that I > can use it in the next calculation (the one for field2o) and then the next > one after that for field3o. > > Is there a way to do that, if so, what would an example look like? > > thanks for any help you can give, this one is driving me nuts, > > Brian > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
