Remember that your tagset templates cannot live in a library on your local machine -- they must be in a template store on the server machine (such as the application server that services SASMain, the application server context on my configuration, which is the server for Logical Stored Process Server requests).
This is the SP that I tested (after I made sure that tagsets.tableeditor was in a library location on my server). The path shown in my LIBNAME statement is on the server where the SAS stored process will execute. (I suppose you could always run the tagset code in-stream to a WORK location, but that seems to defeat the purpose of a template store):[pre]
** 1) run a batch job on server machine with code to write tagsets.tableeditor;
** to a location on the server;
When I ran this simple SP that used the tagsets.tableeditor template, these were my results:
EG -- did get alternating colored rows (verify result type is HTML)
Word -- did get alternating colored rows (verify result type is HTML)
Excel -- did get alternating colored rows (verify result type is HTML)
PPT -- got error message that results are in a format that cannot be displayed by the SAS Add-in for Microsoft Office.
Web Report Studio -- did not get ANY output
Info Delivery Portal -- did get alternating colored rows (default result type is HTML)
Tech Support can help you figure out what your server configuration is and the correct libname statement for your stored process. They can also help you with the code needed to create a tagset template store on that machine.
I have found the reaso why my SSP could not find the tagset in custom folder. This was because the unix user who runs the SSP did not have READ permisions to the file templat.sas7bitm created by PROC TEMPLATE.