Hi,
"It's not that I don't know what the fields will be, it's just that in each iteration there are different fields that might be added."
In what sense, is it your code which is adding variables, is or this a data transfer? If it is a transfer, then look to nail down the process, create a data import agreement, have the vendor sign it and adhere to it - otherwise your just making a rod for your own back. If they think there might be additional variables needed, then consider a parameter + result approach i.e. these would go down the page rather than across - this makes your coding a lot easier, as structure would not change, only data items. If its your code, why do you not know? Are you transposing, if so keep the data normalised and only transpose when aboslutely necessary.
Thinking about your data and arranging it so thats its easy to work with is around 20% of any programming task, and there should never be an instance where you do not know the structure or content of your data, and if for some reason it is hard, then you have sashelp.vcolumn and vtable to help.
"What I love about proc append is that you don't have to pre define the base table."
This ties in with the above, you like proc append because you don't need to know what your data is going to look like, but that will just cause you problems further down the line.
"And the reason I don't know for sure how wide each field could be is because I'm preserving the values in macro parameters so we can replicate certain runs that produce interesting results"
I have no real clue what your doing? If you need to re-run something, then take a snap shot of your data, if you have certain parameters, store them as a parameter/result dataset. Macro is not a storage facility.
If you need examples of the parameter/result, have a look at the CDISC LAB domain, you can see there is a parameter/code and results in character/numeric. The dataset never changes structure, but it can add new parameters etc.
... View more