Real-World Scripting: Creating the New


Writing and maintaining scripts typically involves nine steps:

  1. Gather the requirements for the script.
  2. Write the pseudocode. Pseudocoding is the process of writing, in sentence form, the tasks you want the script to accomplish.
  3. Determine the scripting language based on the requirements and pseudocoding.
  4. Write the code.
  5. Test the code, ensuring it works correctly and meets the requirements.
  6. Document changes and enhancements you want to make on the next version of the script (i.e., your wish list). Also document any requests for enhancements from managers, other systems administrators, and end users of the script's output. Add the changes and enhancements as comments in the script or in a readme.txt file that you keep with the script.
  7. Determine whether the script has become obsolete in its current form. If it's obsolete, go to step 8; if it's not obsolete, return to step 6 and continue documenting changes and enhancements.
  8. Develop a decision matrix that will help you determine whether you need to rewrite the script or write a new one.
  9. Decide to rewrite or write anew, returning to step 1 to begin the process again.

In the article "Developing a Server Failure Notification System" (July and August 1999), I created a server failure notification script called ServerTester.bat and completed steps 1 through 5 in the process. Then, in the Real-World Scripting column last month, I created a requirements and enhancements matrix for the script based on managers', administrators', and end users' feedback. This matrix helped me determine that I needed to write a new script. Thus, last month, I completed steps 6 through 9 for the old script ServerTester.bat. Now I'm ready to begin at step 1 for the new script

Because I created the requirements and enhancements matrix, I've already completed the tasks of determining the requirements (step 1) and the scripting language (step 3) for Now, I need to write the pseudocode.

When most scriptwriters start out, they tend to skip pseudocoding. However, skipping this step isn't a good idea because scriptwriters are language translators. They translate a task from their native tongue (a language they're very familiar with) into a "foreign" language (a language they're typically less familiar with). Pseudocoding helps with that translation by identifying the elements needed to accomplish the tasks and by clarifying the script's flow. Table 1 shows an example of how to translate pseudocode into Perl. (For more information about pseudocoding, see my two-part article "Getting Started in NT Shell Scripting," March and April 2000.)

With the translation completed, I can write and test the script (steps 4 and 5). Listing 1 contains an excerpt from that shows the TestObjects.txt parsing subroutine. This subroutine is the result of the pseudocode-to-Perl translation in Table 1.

At this point, I'm ready to use the script in production mode and start documenting my wish list and everyone else's feedback (step 6). If you want to adapt for your system, you can find it in the Code Library on the Win32 Scripting Journal Web site ( Comments in the script will help you understand the code. Here are the steps to get the script working:

  1. Enter all the objects you want to test in the input file TestObjects.txt. Put one object per line. In the Code Library on the Win32 Scripting Journal Web site, you'll find an example of TestObjects.txt. This file includes headers that contain syntax notes and serve as logical dividers between the different object types. is set up to ignore these headers, so you can include them in your input file if you want to.
  2. Enter the pager recipients in the input file OnCallList.txt. Separate multiple weekday or weekend pager recipients with semicolons. The Code Library on the Win32 Scripting Journal Web site contains an example of OnCallList.txt.
  3. In, enter the name of the SMTP server that will handle the email messages to your paging-service vendor. In the line

    replace with your vendor's address.

  4. In, enter where you want the script to create and append the output file FailureLog.txt. In the line

    replace D:\\ScheduledScripts\\ServerTester with your file's path. The Code Library on the Win32 Scripting Journal Web site contains an example of FailureLog.txt.

  5. In, enter where you're placing TestObjects.txt and OnCallList.txt. The line you need to customize is

After you test in your environment, you can use it in production mode. Then, you can begin preparing your wish list.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.