Chris Wenham is the Editor-In-Chief of OS/2 e-Zine! -- a promotion from Senior Editor which means he now takes all the blame.
Blast Back! Send a private message directly to Chris Wenham with your thoughts:
Go to a Printer Friendly version of this page
Summary: Part II in our series that teaches Rexx to absolute newbies. In this installment: learn how to make Rexx remember stuff, make decisions, and accept information from the user.
In part I of our series I covered what Rexx is good for, what its advantages are, and introduced you to your first few lines of code; a "hello world" program. As you could see, such a basic program wasn't too hard to figure out. You had a comment block at the top that not only named and described the program for your own reference, but also told OS/2 that it was dealing with a Rexx script as opposed to just another batch file. And then you had an instruction that told Rexx to SAY something. I could compare all this to falling off a log, but in reality it's somewhere between shooting fish in a barrel and finding a delicatessen in New York City. I mean it's not hard.
Before going too much further I think I should introduce the concept of variables - the means every programming language uses to store information. Or more precisely: information that can change. It's like a pigeon hole or a crack in the wall that you can stuff things into and retrieve later. Rexx will create these "pigeon holes" on the fly and as you need them. Here's an example of how to create a variable -- filling it with information at the same time -- and then using it a moment later:
/* Display how much our monthly salary is */
If you were to save this as "salary.cmd" and then run it from the command prompt, it'd produce output that looks a bit like this:
You can see that in order to fill a variable with some stuff, we just had to say that it equals ("=") something. The variable's name was 'Salary', and it was created in your computer's memory the instant you made it equal something. Now wherever you use the word 'Salary' elsewhere in the program, Rexx will substitute it for whatever is stored there, in this case, how much your salary actually is. Notice that Rexx did not substitute the word "salary" that was between the quotes of the SAY command, this is because it was considered to be part of the string, and not the same as the variable. It didn't have anything to do with using a lower-case 's', since Rexx is case insensitive when it comes to variable names. If you want an example of how to use a variable in the middle of a SAY command, look at this:
/* Display how much our monthly salary is */
The output would look like this when you run the program:
See that we closed the quotation before using the variable, then opened the quotes again when we had more to say. Try taking out the two quotes in the middle to see how Rexx treats the name "Salary" then.
Okay, so what's the point of using a variable? It's got a lot to do with making a program flexible, able to cope with changes while it's still running. If your salary was to change then you'd have to open up your editor and change the source of the Rexx program again.
To illustrate how a variable's contents can change while the program is still running, we'll introduce you to our next Rexx command: Parse Pull. Parse Pull is like the functional opposite of Say -- instead of displaying a string of words to the user, it asks for them, and it stores what the user gives it in a variable. Here's an example of where we set the initial contents of a variable and then change it later within the program itself:
/* Assume user's name is Bruce, then allow him or her to correct it */
Now I know I threw you a curveball there by using a command I hadn't yet introduced ("if... then....") but I think it's obvious that it makes simple decisions by comparing one value to another. I'll go over it in more detail in a moment. But first let me show you what the output of the above program would be when run:
There you can see that the contents of the variable 'UserName' was changed from "Bruce" to "Michael" (or whatever else the user typed). If you're wondering why it took two words ("Parse" and "Pull"), it's because "Parse" is the command used to break up a string of words and put them into separate variables. But it needs to know where that string is coming from, and by specifying "Pull" we're telling it to get what it wants from the user's keyboard. I'll be discussing the "Parse" command in more detail in the future, since it's one of the more powerful and useful commands in Rexx. Chances are you'll be using it a lot in your scripts and macros.
But to finish off, I'll go over the "If... Then..." instruction to be sure you're comfortable with it. It usually comes in at least 4 parts: The beginning (if), the condition (NewName \= ""), the middle (then) and the conclusion (UserName = NewName). What the instruction did in our program was to make sure the user hadn't just pressed Enter before it goes ahead and overwrites the contents of 'UserName'. In detail:
In the end, the function of the If-Then command in our program is simple. If the user typed a new name, then fill the variable 'UserName' with it. If he/she didn't type a name, then just leave 'UserName' as it is.
To summarize, you've learned not only how to create a variable and fill it with something, but also how to make simple decisions and ask the user for information within your programs. Something to keep in mind when you write your own scripts is that a variable's name must not contain any spaces or punctuation (there are some exceptions, but we'll deal with them later) and should always start with a letter instead of a number. That's why our variables were named "UserName" instead of "User Name" -- Rexx would have thought 'User' and 'Name' were separate entities.
In the next article we'll cover basic arithmetic and how to glue strings of words together.
|Copyright © 1998 - Falcon Networking||ISSN 1203-5696||October 16, 1998|