To all, I have RTFM and also studied the Smart DFSORT tricks and DFSORT User Guide for PTFs UK90007/UK90006, but with no success in one particular area. I have requirements to dynamically create an output file of varying length based on values specified in the data itself, but I have that part down by taking an initial pass and creating dynamic BUILD statements for each type of record.
The problem I am having is attempting to perform an OVERLAY in varying positions of the record for static and varying lengths. For instance, multiple long records within a fixed dataset may have a sequence of consecutive 1's, '11111111', but they may appear anywhere from position 1 until the end of the record. So I would like to perform an overlay of the 1's with spaces whenever there are 8 consecutive 1's, but not perform it if there are only 6 consecutive 1's. I have investigated using ALTSEQ with TRAN and it doesn't appear to allow for multiple consecutive characters for the translation. Basically, I could change all 1's to spaces, but that isn't what I want. I also tried using the PARSE function with STARTAT to position me at the beginning of C'11111111' in conjunction with an OVERLAY in hopes that it would overlay at that position in the record. I know, wishful thinking because SORT normally doesn't function like that. Here is how I coded that ICETOOL using the SS (Substring Search) in an attempt to change positioning as well (hard coded the 600 for testing): SELECT FROM(IN) TO(OUT1) ON(2,5,CH) ON(12,8,CH) ALLDUPS USING(CTL1) //CTL1CNTL DD * OUTFILE FNAMES=OUT1, IFTHEN=(WHEN=(1,600,SS,EQ,C'11111111'), PARSE=(%00=(STARTAT=C'11111111',FIXLEN=8)), OVERLAY=(C' ')), INCLUDE=(2,1,CH,EQ,C'$',AND,3,4,FS,EQ,NUM,AND,8,4,FS,EQ,NUM), TRAILER1=(C'T',20:X,COUNT=(M11,LENGTH=12)) I also tried using the CHANGE parameter, but also had issues getting the change to occur in the particular column where the search string was found. I am hoping I am missing something obvious in the SORT parameters that will make life easier for me. Let me note that the data coming in does not have any consistencies at all other than the first 20 positions are control statements and anything after that is the data to be massaged and sent to output based on the first 20 control statements (input/output record lengths, a selection indicator per record, and also a key that must match for all selected records). All of my studying of this lends me to believe I am going to need an E35 exit to traverse through the records and update them in the manner above by incrementing the position across. I really don't want to go there if I don't have to. If anyone wonders why I am using DFSORT instead of COBOL, the answer is that I am trying to eliminate a COBOL performing this will a simple callable SORT. If it isn't worth it or even possible, then so be it... at least I can say I gave it a shot. :) Thank you in advance for any assistance you can provide. Thanks, Hank BTW, DFSORT V1R5 from the SORT Displays ---------------------------------------------------------------------- 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
