Continue 
Back 
PCLT9 Apr 1995
Prior to the "PPP Update" it was necessary to use a REXX login script to handle most connections. With the simple scripts listed previously, REXX is now only needed to redial from a busy signal or to handle special cases. Most of the people who initially complained that they couldn't get Warp connected mentioned that they didn't know anything about REXX and didn't use it. Running OS/2 and not knowing REXX is something like living in Key West and not knowing how to swim. This is not the place to teach an entire language, but fortunately you don't need to know much about REXX to accomplish this task.
Click here for a quick introduction to the REXX language .
IBM supplies a sample ANNEX.CMD script in the \TCPIP\BIN directory during installation of the Internet Connection. This section examines key lines from that script. The examples provided here will not provide any more function than can be accomplished with the standard login sequence scripting language.
/*----------*/
Anything in a REXX program between "/*" and "*/" is a comment. All REXX programs must begin with a comment. Its a rule.
After some standard modem initialization comes the key logic. It is reproduced below, with some comments removed:
call waitfor 'CyberGate> ' ; call flush_receive 'echo'
On the whole, this is lousy REXX and is not the example I would choose if the purpose of this exercise was to learn the language instead of connecting to the provider. However, this is what you get to start with and so we have to live with it as a starting point.
The particular communications controller that IBM chose to support starts by sending out a block of greeting junk followed by a command prompt of the form "CyberGate> ". It is fairly standard practice for the command prompt to end in "> ", but the "CyberGate" part is terribly specialized. The script responds with the command "SLIP" and a Carriage Return character (that the script has conveniently stored in the CR variable in an earlier section not reproduced here).
The script now waits for a prompt "Username:" and responds with the USERNAME variable (remember, this was extracted in the first PARSE statement shown above and was the second word in the argument list that you configured in the Login Script field of the first configuration panel.
The controller prompts for "Password:" and the script responds with the contents of the PASSWORD variable.
The controller now wants to respond with a line that includes something like:
Annex address is 130.132.57.20. Your address is 130.132.57.27.
The script wants to capture the two addresses in this string. It waits for the "Your address is" part of the reply.
call waitfor 'Your address is'
When that string has been received, then the first address is in the WAITFOR_BUFFER and the second address has not yet been processed. The first PARSE statement discards leading trash (the first period), the string "Annex address is" in the source gets matched, and the address is deposited into A ("130"), B ("132"), C ("57"), and D ("20"). The next line then recombines these numbers into a IP address string assigned to variable ANNEX_ADDRESS.
call waitfor crlf
Remeber, the previous WAITFOR trigger in the middle of a line of output being sent by the Controller. This second WAITFOR reads the rest of the line (up to Carriage Return and Line Feed). This puts the second address into the WAITFOR_BUFFER. This second PARSE statement decodes it, and uses it to construct a variable OS2_ADDRESS.
The first step to build a script is to use any terminal emulator, even the Terminal accessory in WINOS2, to connect to the communications controller and to run through the initial logon sequence. Capture this for further study. Consider the following example captured from the Cisco communications controller at Yale:
CONNECT 14400/ECLC
***************************************************************************
Welcome to the Yale University Network
-Authorized access only-
-Connections may be logged-
Type:
? for help
< command> ? for help with a particular command
logout to logout
***************************************************************************
User Access Verification
Username: gilbert
Password:
Yale-Remote-01> SLIP
Entering SLIP mode.
Async interface address is unnumbered (Ethernet0)
Your IP address is 130.132.57.30. MTU is 1006 bytes
Header compression will match your system.
This sequence has the same elements as the ANNEX script, but with some important differences. For one, the Userid and Password must be entered first, before the SLIP command can be typed. The Cisco controller uses the "invisible" approach where it advertises no IP address for itself. The convention at Yale, however, is that the Gateway router will always have the last number in its IP address set to 1. Thus although the Cisco hasn't sent any explicit information about the gateway, if this remote PC has been assigned address 130.132.57.30, then the Gateway must have the first three numbers and end in 1 (130.132.57.1). With these changes, now we can rearrange the ANNEX script as follows:
call waitfor 'name:' ; call flush_receive 'echo'
annex_address = a||'.'||b||'.'||c||'.1'
A few of these changes are stylistic. For example, after examining a number of different communications controllers, one discovers that some end the prompt "Username:" and some end it "username:". Although REXX ignores case in variable names and keywords, it honors it inside a quoted text string. So after a while one learns that the best general approach is to trigger on the end of the word and match both the capitalized and uncapitalized prompt. The same idea drops the "Pass" in "Password:". Clearly we want to dump whatever gets put in front of the "> " in the command prompt.
The "MTU" phrase appears immediately after the IP address gets printed out, so we use it as a trigger to stop the WAITFOR. Then the address gets parsed out of the buffer. In this case, the IP address presented belongs to this remote machine (it is the OS2_ADDRESS) and in this case the Gateway IP address can be deduced by taking the same first three numbers as a prefix and ending with a "1".
Obviously calling this ANNEX.CMD and leaving the ANNEX_ADDRESS variable name is a bit confusing, since this script now has nothing at all to do with an ANNEX brand controller. However, cleaning things up involves more work that is necessary, so this script makes the fewest possible changes and just gets things working.
It is now possible to fall through to the rest of the IBM ANNEX.CMD script and it will do the right thing. It is, however, informative to examine what the "right thing" really is:
call flush_receive 'echo'
The FLUSH_RECEIVE lets the user see the output from the communications controller that is still in the buffer. The two SAY statements also show up on the screen and are useful diagnostic statements in the event that the processing gets completely fouled up. The last two statements execute two OS/2 commands that configure the TCP/IP protocol. In this example, they will expand to
ifconfig sl0 130.132.57.30 130.132.57.1 netmask 255.255.255.0
route add default 130.132.57.1 1
The IFCONFIG statement tells the TCP/IP support that the SLIP connection ("SL0") is a route to send messages to a machine with IP address 130.132.57.1 and that in this connection the address assigned to my PC is 130.132.57.30. The ROUTE statement says to send all messages for all other machines to the gateway at 130.132.57.1 (and therefore to send them all on the SLIP line). IFCONFIG.EXE and ROUTE.EXE were installed with the rest of the Internet Connection programs in \TCPIP\BIN. However, as was noted previously, many DOS/Windows packages also have programs with this name. Since \WINDOWS is often configured in the OS/2 PATH before the \TCPIP\BIN directory, it was important at the start (as explained in First Clean Your Windows) to remove programs with this name from the WINDOWS directory or these statements will try to execute the DOS versions of the utilities and will therefore fail.
Note that the original ANNEX script generated a ROUTE command for a visible controller that presented its own IP address. This script changes it to support an invisible controller. Therefore the ANNEX_ADDRESS variable is set to the address of the LAN gateway and the generated ROUTE statement reflects the result.
Copyright 1995 PC Lube and Tune -- Windows on the World -- H. Gilbert