Real-World Scripting: Determining Whether to Rewrite or Write Anew
This monthly column offers practical scripts for systems administrators. This month's column shows you how to use a requirements and enhancements matrix to determine whether you can adapt an existing script or you need to write a new one
March 20, 2000
As a scriptwriter, a challenge you'll continually face is that no script is ever 100 percent complete. Sometimes, managers or end users request additional functionality; other times, you might want to make improvements. To determine whether you can adapt an existing script or need to write a new one, you must answer several important questions:
Can you rewrite the existing script to meet the new requirements without creating a hodgepodge of code that doesn't conform to the script's original flow? Another way to ask this question is, "Will another scriptwriter be able to understand, use, and modify the revised script?"
Can you make any secondary enhancements if you rewrite the script? For example, can you improve the script's performance?
Can you use the existing scripting language to meet the new requirements and enhancements? If you need to use a new language, can you at least use the existing code as an outline for the new script?
To help answer these questions, you can create a matrix to clarify the new requirements and compare them with the original script's requirements. The matrix also documents the enhancements you want to make. The following example shows how you use the requirements and enhancements matrix.
Example
In "Developing a Server Failure Notification System" (July and August 1999), I discussed how to create a server failure notification script called ServerTester.bat. This Windows NT shell script tests servers for ping response, service status, and share availability. If a problem occurs with a server, the script immediately pages a systems administrator about the server's status.
I implemented ServerTester.bat in my company's Web server farm, which provides Web content for several departmental intranet sites and the corporate Internet site. The script effectively monitored server health. However, in one case, the Web server farm wasn't providing pages, even though the Microsoft Internet Information Server (IIS) 4.0 w3svc Web service was still running. I then realized that I needed a script to test whether the servers were providing pages. I created the requirements and enhancements matrix in Table 1, page 10, to determine whether I could revise ServerTester.bat.
As the matrix shows, the script has two new requirements and one revised requirement:
Test Web server pages (new). To test whether the servers are successfully providing Web content, the revised script needs to test for the HTTP response code of 200, which specifies a successfully served page. Any other response code is a negative response and needs to trigger a page and a logging event. The code to meet this new requirement is difficult to write in NT shell scripting. (Previous attempts to get an NT shell script to return HTTP success or failure information had failed.)
Be platform independent (new). The original script ran only on NT. Because the company's UNIX and VMS administrators want to use variations or extensions of the revised script on their systems, platform independence is now a requirement.
Page administrators upon failure (revised). Whether a failure occurs on a weekday or weekend, the original script checks an input file called OnCallList.txt to determine which of four systems administrators to page. The revised script must not only meet this paging requirement but also page one of two Web administrators if the failure occurs on a weekday. Thus, the paging code requires modification.
The matrix also shows that I can make three enhancements to ServerTester.bat:
Consolidate input files. Besides OnCallList.txt, the original script uses the input files PingList.txt, SharesList.txt, and ServicesList.txt, which list the servers, shares, and services, respectively, to test. When a server isn't in production mode, systems administrators remove the corresponding entries from PingList.txt, SharesList.txt, and ServicesList.txt. However, the administrators sometimes forget to add the entries back to all three files when the servers are back online. Thus, to make it easier for administrators, I want to consolidate PingList.txt, SharesList.txt, and ServicesList.txt into one file called TestObjects.txt. This input file will also include the Web sites to test. (OnCallList.txt will stay the same, except for the addition of the new Web administrators section.)
Improve paging reliability. To page systems administrators, the original script uses a browser to send input to the paging service. The paging service, in turn, initiates the page. Because this paging method fails occasionally, I want the script to use email instead of a browser to send input to the paging service. Most major paging services (e.g., SkyTel, MobileComm) offer paging through email addresses such as [email protected].
Improve performance. CPU utilization is high when the original script runs. When other scripts execute simultaneously with ServerTester.bat, the administration server sometimes becomes sluggish. Thus, I'm considering Perl as an alternative scripting language because of its high performance.
What It All Means
The requirements and enhancements matrix reveals that the revised script needs to meet two new requirements, one revised requirement, and three enhancements. However, to achieve one of the new requirements (Web page testing) and one of the enhancements (improved performance), the script needs to be in the Perl scripting language. Thus, I can't revise ServerTester.bat. I can use the original script only as an outline for the Perl script. Next month, I'll show you how I used ServerTester.bat as a guide for creating the Perl script, ServerTesterV2.pl.
About the Author
You May Also Like