I’m always amazed and somewhat peeved about how much error checking one has to have in their SAS language program. Even for the simplest things. So today’s mantra is test, Test, and TEST!
I was writing some code the other day to copy a WPS data set from my PC to a server share. The basic code is really quite simple, only three lines using PROC COPY. But what if the user has misidentified the source libname or the destination libname? Do you just let it blow up and hope the user looks at the logs? And then you have the data sets to be copied if you are using the SELECT statement. Do you check if the data set already exist and if so, just overwrite the file?
Although it was trivial, albeit time consuming to write the code to check for these conditions, it is well worth it. I purposely decided not to automatically overwrite an existing data set on the server. And that is good for two reasons. First, I want the user to be forced to make the decision to overwrite the data set by use of a PROC DATASETS or PROC DELETE before the copy takes place. That makes it their responsibility to delete the data set.
Secondly, I found out that writing the data set with the same name can sometimes create problems under Windows when the server folder is shared. I have had some experiences where Windows locks the file on the server and the copy never takes place. The copy procedure just hangs with a .lck extension on the file. So something is going on where it’s just not reliable.
One interesting thing to note, I don’t seem to have the problem with a lock on Linux. The copy takes place without issue every single time.
About the author: Phil Rack is President of MineQuest Business Analytics, LLC located in Grand Rapids, Michigan. Phil has been a SAS language developer for more than 25 years. MineQuest provides WPS and SAS consulting and contract programming services and is a authorized reseller of WPS in North America.