Hi:
Ah, well, prematurely closing the destination would tend to cause the output to cease flowing to the closed destination!
In some earlier versions of SAS, if you named the file with .XML as the file extension, a browser or XML editor (like XMLSpy) opened the TAGSETS.EXCELXP file instead of having Excel launch. So, when I post TAGSETS.EXCELXP code to the forum, since I don't have any idea who is running those older/earlier versions of SAS, I tend to use '.XLS' as the file extension to avoid a followup question of "Why does the browser open my TAGSETS.EXCELXP file?". Excel is perfectly happy, usually, to open files with the .XML extension from the FILE --> Open menu inside Excel. Besides, merely NAMING the file with a .XLS extension does not make the file a "true, binary" Excel file. You could open my output file with Notepad (or VI on UNIX) and you would see XML markup tags inside the file, no matter what file extension you give the file.
The ONLY way to create "true, binary" Excel files is to use PROC EXPORT or the SAS Excel LIBNAME Engine (or the SAS/Access ODBC or OLE-DB products). ODS -- no matter which "flavor" of ODS you use -- only creates ASCII text files and Excel happens to be able to open and render those ASCII text files, no matter what file extension you give the files. You can prove this to yourself by using ODS HTML, ODS CSV or ODS TAGSETS.EXCELXP to create result files and name the files with the .XLS file extension, but then BEFORE you just double-click on the file that you've created, try opening the result file from any of those ODS "flavors" with a text editor, you will see the underlying "markup" language info in the file -- not binary Excel formatting.
However, you also asked something that needs a BUNCH of clarification. You asked:
"These reports need to be run as a stored process later on. Will the extension make any difference? "
Here are some facts about stored processes (long post warning):
1) generally with a stored process, you are creating results that come directly back to a client application (such as Word, Excel, EG, or a browser or Web Report Studio) -- there is technically no filename or file extension for the output results from a stored process -- so the issue/question of file extension for stored process output is mostly a non-issue.
2) If you use SAS Enterprise Guide to convert an EG task or project or a stored process -- EG inserts (or will insert) the appropriate %STPBEGIN/%STPEND; macro invocations -- there is no easy way to specify a FILE= option with these stored process macros that is universally accepted by all the client applications, and in fact, I can't think of any client applications that would even know what to do with a FILE= option that had a filename and a file extension.
3) The best way to use FILE= with a stored process is to use the reserved file reference (FILEREF) of _WEBOUT -- which is essentially a "pipeline" from a client application to a server (stored process server usually) -- and again, _WEBOUT does NOT have a filename or file extension.
4) You can tell a browser what "helper" application can be used to open a _WEBOUT stream (such as Adobe Acrobat for PDF _WEBOUT or Excel for TAGSETS.EXCELXP _WEBOUT) by using the STPSRV_HEADER function to change the HTTP content-type header that is sent for any non-HTML _WEBOUT stream of output.
5) BI Platform client applications all have their own "preferences" when it comes to receiving stored process results. For example -- Web Report Studio and Microsoft PowerPoint will ONLY accept SASReport XML results from a stored process. So if you use TAGSETS.EXCELXP for your stored process, you would have to tell WRS or PPT folks that they cannot use your SP. And, of course, Microsoft Word only "accepts" SASReport XML, RTF and HTML results from a stored process, so it wouldn't "accept" TAGSETS.EXCELXP output, either. Microsoft Excel (using the SAS Add-in for Microsoft Office) will ONLY accept SASReport XML, HTML and CSV results from a stored process. Yes, you're right, TAGSETS.EXCELXP is NOT in that list.
6) The only client apps which can submit a stored process and receive results from a stored process that uses TAGSETS.EXCELXP are 'web-based' client apps that receive "streaming" output -- such that you can change the content-type header, as mentioned in #4. Those client apps would be: the Information Delivery Portal or the Stored Process Web Application (SPWA).
7) If you note how things work in EG, you can't automatically "turn on " TAGSETS.EXCELXP for output without doing something with code or extra options. That's because EG is very friendly with the SASReport XML flavor of XML -- SASReport XML is an XML description of a multi-section report -- such as that used by Web Report Studio. And EG can also create SASReport XML -- so that you might be able to deploy reports from EG for opening with WRS (or other client apps) using a common format.
8) TAGSETS.EXCELXP is a destination that produces Microsoft-specific XML (Spreadsheet Markup Language XML -- also known as Excel XML 2003). TAGSETS.EXCELXP follows the rules of Microsoft for Spreadsheet ML 2003. TAGSETS.EXCELXP is a different "flavor" of XML than SASReport XML. The SAS BI Platform uses SASReport XML very happily. TAGSETS.EXCELXP -can- be used in the context of the BI Platform client applications, but if you want to use TAGSETS.EXCELXP for your stored processes, you are creating a stored process that can only be used/invoked by a limited number of client applications.
If you search in the Stored Process Forum, you will find several examples of code for creating a stored process that uses TAGSETS.EXCELXP. Some of them use %STPBEGIN/%STPEND and some of them use _WEBOUT.
Sorry to post such a long explanation. I wanted to clarify things now in order to set the correct expecations for what you can and can't do with a stored process and TAGSETS.EXCELXP.
cynthia