General Words of Advice for User Inheriting Programs

[malmario]

Hi All,

I have a number of programs that I inherited from previous analysts in my organization.  The ones that are giving me the most trouble are programs created back in 2010 that are automated through task scheduler.  One program in particular uses DDE to output the data into a formatted template in excel.

The problem I've run into is that the program typically errors.  Errors include saying the log is in use, the I/O is incorrect, or that the template file is already open (the last is the most seen problem).

I'm happy to post specific code if needed, but I wanted to also use this example as a question.  Does anyone have advice on how to handle programs that has code seeming out of date?  I have maybe 10 of these that are my responsibility.  Given the time-constraints in my department, I struggle to learn how these programs were designed to run and how I can update them.

Words of encouragement are appreciated.

Thanks.

[Cynthia_sas]

Hi:
Well, there's always the redesign and rewrite approach. Sometimes a fresh pair of eyes and a new look at the problem/process: What are the inputs? What are the desired outputs? Ignore the current methodology and design and see if you can get from input to output YOUR way -- possibly without using DDE. 2010 wasn't quite a decade ago, but it's worth taking another, fresher look at the inputs and outputs -- DDE to an Excel template was one of the ways that I remember recommending before ODS EXCEL or ODS TAGSETS.EXCELXP. So the chances are good that you might come up with a better, less error-prone alternative if you took a fresh approach.

My .02,
Cynthia

(a long time ago when I was doing application design and analysis, the "constant application lifecycle approach" said you should redesign from scratch and rewrite every 5 years -- or every ?? years -- depending on how fast the needs of the end user changed or how fast the data changed.)

[malmario]

Appreciate the words of wisdom. Looking back at my comment, I can tell it came from a long day of staring at no progress.
I like the redesign and rewrite as opposed to the hammer-and-nail that my teams been going through this week. I'll take a fresh approach tomorrow!

[ballardw]

With that long of a period I would examine any file dependency issues.

DDE is only one. I may be of importance to know that the communication methods DDE was designed to use are interfered with by other programs these days. My specific example is Cisco Jabber. I had a process that used DDE because I couldn't get management to spring for the SAS/Access Interface to PC Files. Which quit working when Jabber was installed. And in this specific case halting the active window of Jabber was not sufficient but using Task Manager to kill the process allowed DDE to work.

Another specific to DDE is you have a moving target in the file format definitions. Code that worked with Office 2007 (or what ever) quits with later versions of Office as each release is likely to require a different file type parameter.

I am lucky in that I do not have to "place" values into an Excel "template" (which has many different meanings to different users) but I might examine use of either ODS Excel or ODS Tagsets.Excelxp to see if equivalent documents can be created from scratch getting completely away from the basically no longer supported and definitely not improved DDE from Microsoft. Or possible discuss with management if the entire process needs revision (neat new features as an opportunity to get away from "template").

Output is another thing to look at closely. Graphic procedures likely should be moved to SG graphics or examined for the many newer options if SG graphics were used. ODS options have increased in either general definitions or style overrides inside report procedures and possibly Proc Document may be helpful for assembling complex reports.

Newish procedures like Proc ODSTEXT and Proc ODSLIST may provide alternatives to either ODS Text output or File Print.

You might also want to mine the "What's New" sections of the releases of SAS 9.2 and later to see if there are bits that look helpful for your