Hi @SmithCJGVSU  In this particular case, an alternative to BY group processing could be the use of macro language. Maybe something like this: 1 - definition of distinct macrovariables by group:   proc sql; /*Big N overall*/ select trt01pn, count(distinct usubjid) into :trtn1-:trtn99,:bign1-:bign99 from adsl group by trt01pn; /*Big N sexn=0*/ select trt01pn, count(distinct usubjid) into :trtn_0_1-:trtn_0_99,:bign_0_1-:bign_0_99 from adsl where sexn=0 group by trt01pn; /*Big N sexn=1*/ select trt01pn, count(distinct usubjid) into :trtn_1_1-:trtn_1_99,:bign_1_1-:bign_1_99 from adsl where sexn=1 group by trt01pn; quit; 2 - Define a macro program with sex as a parameter (nb: you should also define the title accordingly, with values of sex as it is less efficient than BY group processing to do that automatically)     %macro report(sex=); proc report data=final missing split='|' ; columns varord varlbl statord statlbl col:; define varord /order order=internal noprint; define varlbl /order order=internal noprint; define statord /order order=internal noprint; define statlbl /display '' style(column)={cellwidth=2.21in} id; define col1 /display style(column)={cellwidth=1in} "Placebo|(N=&&&bign_&sex._1)"; define col2 /display style(column)={cellwidth=1in} "Active 1|(N=&&&bign_&sex._2)"; define col3 /display style(column)={cellwidth=1in} "Active 2|(N=&&&bign_&sex._3)"; run; %mend; 3 - Macro call (one per group like below, or use of CALL EXECUTE)   %report (sex=0) %report (sex=1) ... View more

@SmithCJGVSU - Why do you think a new SAS server session will somehow know where your SAS programs are stored if you haven't identified any of these programs to SAS first? A brand-new SAS session will only know the location of where it was started from and nothing about what programs you want it to run.   I find it useful to set up a macro variable containing the folder location of the required SAS application in a program controlling that application. ... View more

Have you seen this post: https://communities.sas.com/t5/Graphics-Programming/Unicode-Characters-in-SGPLOT-Label-9-4M2-LIN-X64/td-p/593966 ... View more

I'm going to go out on a limb and suggest that decimal alignment only works with numeric values. Since a character value could look like: "12. abc. 3.4" which of the three decimals would be aligned?   Also for National Language Support issues a "decimal alignment" should be able to use the comma when that is the decimal separator.   From some documentation on ODS language statements:   ODS DECIMAL_ALIGN Statement Controls the justification of numeric columns when no justification is specified. ... View more

@Cynthia_sas  What’s the best way to align percents/parenthesis if your data is character in the form, nn (pp.p%) or nn (pp)?   I started a new thread here, https://communities.sas.com/t5/ODS-and-Base-Reporting/ODS-TAGSETS-RTF-RTF-How-does-Decimal-Alignment-work-style-column/m-p/545321.   I can’t seem to get just=d working how I’d like it to.  Particularly for proportional font like times new roman. ... View more

Hi: Once you start digging, you discover that most procedures use the same elements. There is more "in-depth" like containers to hold things, like a BylineContainer or SysTitleandFooterContainer but usually, if you zero in on what it is you want to change specifically, you'll find it is probably one of the ones I showed in my FREQ and MEANS examples -- TABLE, HEADER, DATA, ROWHEADER, SYSTEMTITLE, PROC TITLE and BYLINE. The thing is that a table is a table is a table. A header is a header is a header. A note is a note is a note. A datacell .. well you get the idea. Tabular output can only have so many piece parts. No matter what procedure you use, except for PROC COMPARE, almost all other procedures use HEADER, ROWHEADER and DATA style elements. Doesn't matter the procedure, doesn't matter the destination. So dumping style elements to the log based on a particular destination isn't attractive to me. If you want to change the header cells for ODS RTF, you change them with the same code and the same attributes as you do for ODS HTML. The only place where style templates can get a bit wonky for a particular destination has to do with borders or interior table lines in a template. Typically, when I need to change borders for one destination or another, that's when I might need a special style that is tailored to a particular destination (giving the stink eye to Excel on this one). Good luck in your template endeavors. And I'm glad you've benefited from the book and papers. Cynthia ... View more

Hi:   I guess it comes down, for me, to this question: -- do you need some feature in TAGSETS.RTF that is NOT available in the original RTF   Answering that question is going to require some testing. On the other hand, if 90% of what you want is OK with ODS RTF, and you only need TAGSETS.RTF for the remaining 10%, then is it really worth switching everything to TAGSETS.RTF just to only deal with 1 destination. The beautiful thing about having 2 ODS destinations that created RTF output is the ability to create your output the way you want. For example, if you KNOW that you are going to have multi-page tables and you absolutely want the "Continued" at the bottom of every page,  where the table spills over to the next page, then that's an argument for TAGSETS.RTF. If your tables are "page-sized" or will fit on one page, then Continued is out of the picture, why not use regular ODS RTF?   Do you want the output to have "fixed page breaks" and wrapping, as set by SAS (ODS TAGSETS.RTF has vertical measurement so SAS page breaks are respected)? Or, do you want to allow the page breaks to depend on the Word margins (ODS RTF does not have vertical measurement).   If you want to have a table and a graph from the SG procedures side-by-side on one page, that is actually an argument for using ODS LAYOUT with ODS PDF (not ODS RTF).     Sorry, I don't have a one size fits all recommendation. I've been doing this too long to recommend hitching your output wagon to one destination and only one destination.   Cynthia   ... View more