Hi: Thanks! Now I understand your use of @ -- with PUT statements. What you did NOT tell us was your destination of choice -- whether you have HTML turned on, SASReport turned on, RTF or PDF, etc (you can find out by looking under Tools-->Options-->Results General). I do not see any explicit ODS statements in your code, so I think that you are probably either using HTML or SASReport destination. But it's a moot point. With SAS and ODS, your simple PUT @10, PUT @55, etc will not produce any type of output that you will like. The fact is that most things in ODS are written in a proportional spaced font, whereas, the PUT statement was designed for a world where printers did NOT have proportional spaced fonts. Also, are you interested in only writing to the SAS log? I do not see any FILE statements in your code. I would have expected to see either FILE 'c:\temp\myflatfile.txt'; or FILE PRINT; in the code. So I'm sort of wondering where you are getting your results. (This is related to the destination that you've chosen for your output.) As an example, consider the following "line" of text. Each "line" contains 25 letters. Exactly 25 letters. Arial font: iiiiiiiiiiiiiiiiiiiiiiiii wwwwwwwwwwwwwwwwwwwwwwwww and you can see that @10 in the string of the letter 'i' does not "line up" with @10 in the string of the letter 'w'. Courier New font: iiiiiiiiiiiiiiiiiiiiiiiii wwwwwwwwwwwwwwwwwwwwwwwww so, even though the 'i' and the 'w' both line up in position 10 in the Courier New font, placing text in absolute column positions is still hard with ODS because many of the conventions that folks used to use in these old type of DATA _NULL_ programs just don't work anymore. The default in ODS is for leading spaces to be suppressed in text, as an example of just one thing. The use of PUT _PAGE_ is another thing that doesn't work. Next, your logic, while it makes sense, is unnecessary, (you could use BY group processing to detect the first seq_no or degree in a group). But even BY group processing, while probably easier to code, would still be inside a sub-optimal DATA _NULL_ program. And, besides, either the PROC PRINT example or the PROC REPORT example, will build you a table and suppress duplicate observations far easier than doing your own coding. Why is the DATA _NULL_ approach being used? You have created data from some kind of query (guessing from the name) -- why not use the List Data task or the List Report task or the code that's been provided to get you a report? If you use the EGDEFAULT style, then your report table will look like it has interior table lines. But, as I show in my code and screenshot, if you change to the JOURNAL style, your report will not have interior lines, and it will look like you have leading spaces in the DEGREE column. Did you try either the PROC PRINT or the PROC REPORT code? If you really, really want to use DATA _NULL_, then you'll probably have to work with Tech Support to figure out how to write a style template that will use a monospace font, such as Courier New for your output, and you will have to set the ASIS style attribute to ON for selected style elements. And, you still have to figure out whether any of those techniques will work with your chosen destination, whatever it is. To open a track with Tech Support, fill out the form at this link: http://support.sas.com/ctx/supportform/createForm cynthia
... View more