PROC TEMPLATE — How to undo the edits? Part 2

[PaigeMiller]

Way back in the Pleistocene era, I asked the question about changing formatting via PROC TEMPLATE and then later undo-ing the changes. @ChrisHemedinger provided a useful response regarding using ODS PATH.

However, it now seems as if I have made the change permanent, unknowingly. If I launch a new SAS session and issue the command 

ods path show;

I see that the path is 

1. SASUSER.TEMPLAT(UPDATE)
2. SASHELP.TMPLMST(READ)

which agrees with what the default ODS PATH is according to https://documentation.sas.com/doc/en/pgmmvacdc/9.4/odsug/p03q7l9284sg38n1d9186k3i7u3c.htm

But if I run a simple PROC FREQ, I see that my changes using PROC TEMPLATE are still in effect (highlighted in yellow), remember this is a brand new SAS session. Output:

Not what I want. How do I un-do this change and make it permanent? I add that if I start the brand new SAS session with ODS PATH RESET; it doesn't seem to fix the problem.

[Cynthia_sas]

Hi:

  Assuming you did NOT write into SASHELP.TMPLMST, then before you run your code, you should ONLY need to do this:

ods path sashelp.tmplmst(read);

Do NOT put SASUSER.TEMPLAT into this path. What you're doing is removing the SASUSER item store from being searched when you use PROC FREQ. Assuming you only changed the template in SASUSER, then you should get the production PROC FREQ template with this statement in your code because you are telling ODS to ONLY search in SASHELP.

  Let's keep our fingers crossed that you did NOT change SASHELP.TMPLMST, and when you use the ODS PATH statement, your PROC FREQ will be the default template. So then, when you want to use your changed template, you'd have to issue a new ODS PATH: 

ods path sasuser.templat(update) sashelp.tmplmst(read);

Which should then cause the changed FREQ template to be found first. What you're doing with the ODS PATH statement is changing what is available to be searched for  by ODS based on the templates used by the different procedures.

  Now in the worst of cases, when you change the path to just SASHELP.TMPLMST and you do (unfortunately) still see the changed rejport, then you are sort of in Tech Support land. You should never, never, never, never, never, never, never, never, ever change SASHELP.TMPLMST to any access other than (READ). Depending on your platform, Tech Support may be able to just send you a copy of the item store for your version and maintenance level of SAS. In the ugly old days, if you accidentally wrote over a template in SASHELP.TMPLMST, you had to reinstall SAS to get the production templates back (guess how I know this). I don't think it's that way anymore, but I'm sending all good thoughts your way, that you only changed SASUSER.TEMPLAT.

Cynthia

[PaigeMiller]

@Cynthia_sas 

I have done a text search of every SAS program I have written on this job to find places where I used ods path and I see no such place where I changed the access mode on SASHELP.TMPLMST to update or write. So that's good. Could I have accidentally made such a change and then modified the code back to read access mode before saving the code? I guess we will never know.

I do see examples in my code where I changed either WORK.TEMPLAT or PUB.TEMPLAT (where PUB is a valid LIBNAME) to update or write access mode, I assume that is not the potential cause of any of this.

However, I can confirm that this seems to eliminate the problem.

Assuming you did NOT write into SASHELP.TMPLMST, then before you run your code, you should ONLY need to do this:

ods path sashelp.tmplmst(read);

Brief testing indicates that I need to do this each time I launch SAS, so I will put this into my AUTOEXEC, and be much more careful whenever I change templates. (Unless there is something else that will work so I don't have to put this into my autoexec...)

[Cynthia_sas]

Hi:
By default, when the system starts up, SASUSER.TEMPLAT and SASHELP.TMPLMST are set up by default. Theoretically, if you list SASHELP.TMPLMST first in the ODS PATH statement, that is the item store that is searched first. And if the production PROC FREQ template is found there, then that should stop the search there, even if SASUSER.TEMPLAT is in the list. My tendency is to NOT dump changed templates in SASUSER because every time you install SAS your SASUSER gets re-created, thus losing everything you saved there. Typically, I store templates in WORK while I'm testing and then send them to a permanent library that is not SASUSER (something like your PUB library). Putting the ODS PATH in your AUTOEXEC is a good way of dealing with the need to bump SASUSER.TEMPLAT out of the search path. You could try:
ods path sashelp.tmplmst(read) sasuser.templat(update);

  This approach works well for changed style templates that have different names than the production style templates. But the issue with the SASUSER that is the other reason I don't use it is that you don't want to give EVERYONE who will be using the changed template the code so they can each store the template in their SASUSER. Far better to put your production templates in your permanent library that's accessible to everyone and then the  the SAS production ones will be in  SASHELP and then for most people who will be sharing your templates, I'd recommend something like THIS in everybody's autoexec:

ods path sashelp.tmplmst(read) myprod.templat(read);

In other words, make the access level read for everyone except the programmers who will be allowed to change it.

Cynthia