if it is each obs with all subsequent, then data step is going to need more trouble (set with point) than sql _probably_
Contrast the management of arrays (remembering the probable need for two - one nums other chars) with sql using select column name++ into :host_variable over all columns required for compare, to generate the select statement defining columns out of the sql compare. Even though sql doesn't have the equivalent of the _n_ in data steps, it is easy to generate for the sql join filter[pre] where A_n_ > B_n_ [/pre]with datastep view like[pre]data a/view=a ;
A_n_ +1;
set &input_data_set ;
run ;
data b/view=b ;
B_n_ +1 ;
set &input_data_set ;
run ; [/pre]Then code needs to be generated to create the required outcome. Perhaps it would be enough to generate something like[pre] select A_n_, B_n_, (a.name = B.name ) as d_name [/pre]where I hope "name" and its prefixes A., B. and D_ are indicative enough. The ( compare) part is repeated for each variable name in &input_data_set so proc contents out= or dictionary.columns would be used to retrieve that list of names as "data".
This is clearly creating a lot of output data, not just a lot of coding trouble. Before investing more time - are you sure this is productive? Would you like to explain how this is useful to you?
peterC
