This month's exercises concentrate on user written functions.

1. Write a simple procedure, SAY_THIS, that will display a text string passed as the argument. Label your output and enclose it in quotes. This will allow you to see any extra spaces.

   Sample output:

   Say This: "Hi"
   

   Try multiple word strings.

2. Expand on exercise 1 by passing multiple strings separated by commas.

   Sample output:

   Say This (1): "First String"
   Say This (2): "Second String"
   

   Be sure to explore what happens if one or more of your strings contains a comma or imbedded single or double quotes.

3. Change or rewrite Exercise 1 and 2 to accept strings from the command line. Try the following strings:

   One
   One Two
   One Two Three
   One "Two Three"
   One "/Two Three"
   One "//Two Three"
   

4. In Exercise 3 above you probably accepted the command line as a single string, not a list of words. Expand exercise 3 such that you can assign or display each keyword or phrase on the command line separately.

5. A very common program feature is to accept one or more keywords on the command line. A common syntax is:

   MyProgram -a:First -b -c:"Long File.txt" inFile.txt

   Write a program that will accept such a command line and parse the parameters and their values. Consider that some parameters may not be used for every execution, extra (perhaps invalid or duplicate) parameters may be passed, or that a syntax error, such as forgetting a dash, a colon, or a quote in the file name.

6. Revisit some of the Lesson 1 and Lesson 2 exercises adding code to allow them to be called from the command line. Good candidates are Lesson 1 exercises 8-15 and Lesson 2 exercises 8-10. Testing these functions is much faster when calling them from the command line than struggling through successive run-edit-run trials. Lesson 2 exercise 5 is a good candidate for conversion to a function that you might want to add to your bag of tricks.

7. A friendly program provides good error diagnostics, then ends or continues gracefully. Write a function that will accept a numbered error, then look up the appropriate message in a file. Each line in the file should contain an error message. Devise a scheme to deal with terminal or non terminal situations. In terminal situations the function should display the message and exit to the operating system. In non-terminal situations the function will return to the calling program. This function is another candidate for your bag of tricks and is an excellent basis for building a multi-language program.

As always, there is no single "correct" way to approach these problems and a cute program that almost works is never as valuable as one that does work.

The command line parser and the error message display will be valuable routines in your tool kit. Be sure to keep them in a library. REXX does not offer an easy way to manage libraries of REXX source code. If you write many large programs that reuse the same functions, investigate PPWzard.

Don't be embarrassed by your mistakes; bring them to class. We can always learn from mistakes, success may be accidental.

---

About these pages Content updated: 07-09-2005 10:15am

Page building by:

Content updated 07-09-2005 10:15am