| |
This topic discusses the use of modems with the Novell® Internet Access Server 4.1 routing software. It contains the following sections:
This topic describes the utility used to create or modify modem description files for the Novell Internet Access Server 4.1 routing software.
This topic describes using dial-up synchronous modem connections for limited public-switched telephone support.
This topic describes modem description files, modem-specific files that enable modem support in the Novell Internet Access Server 4.1 routing software. This section describes the information provided by these files. It also explains file syntax and provides sample files.
This topic describes how Novell's modem control is implemented in the NetWare® server environment.
The Novell Internet Access Server 4.1 routing software provides a Windows-based utility that enables you to create a customized modem description file. To create, edit, or install a modem description file, start the WMDMMGR utility the same way you would start any Windows 3.1, Windows 95, or Windows NT utility. This utility can be run only at a Windows workstation and cannot be run from the DOS prompt.
WMDMMGR is located in the SYS:\SYSTEM\UTILS directory on your server. Three sample modem description files, with an .MDC extension, are provided in the SYS:\SYSTEM directory of your router. These files contain modem scripts that are certified by the Novell LabsTM group (NIASCERT.MDC), as well as scripts for commonly used modems (NIASMDM1.MDC and NIASMDM2.MDC). You can modify these modem scripts to meet your requirements, although this is not recommended for scripts in the NIASCERT.MDC file.
To create a new modem description file, select New from the File menu. To modify an existing login script, select Open from the File menu. After editing the modem description file as described in the online help, save your changes by selecting Save or Save As from the File menu. To edit existing files, copy the files to the SYS:\SYSTEM directory. If you have any problems editing or using existing modem description files, refer to Using the WMDMMGR Utility in the Modems and DTR-Controlled Devices documentation.
The remaining sections in this topic provide the background information you need to understand the operation of modem description files.
This topic describes the pseudopermanent connection feature supported by the router using dial-up synchronous modems. The dial-up synchronous connection is established automatically by the modems when the routers at both ends are turned on. The connection is terminated when either of the two routers is turned off or otherwise stopped.
The pseudopermanent link is a dial-up link established over the Public Switched Telephone Network (PSTN) using a pair of synchronous modems. By its very nature, this connection is asymmetrical because one modem originates the call and the other modem answers the call. Therefore, the calling end needs to be programmed to automatically dial the stored telephone number of the remote modem, and the remote modem needs to be programmed to automatically answer the incoming call.
When the routers are turned off, the Data Terminal Ready (DTR) signal is set low, thereby prohibiting any connection between the modems. When the router at the calling end is turned on, it turns on the DTR, triggering the modem to automatically dial and establish a connection. When the calling modem detects the DTR off-to-on transition, it goes off-hook, dials the remote modem, and waits for the connection to occur. If, after a certain programmed period (in units of number of rings), the connection fails to materialize, the modem goes on-hook and terminates the connection. If the connection does occur (that is, the remote end answers), the modem turns on the carrier, exchanges a training sequence, and reaches a ready state. These events are indicated by the modem turning on the Data Set Ready (DSR), Data Carrier Detect (DCD), and Clear-to-Send (CTS) signals, in that order.
The answering modem waits for an incoming call and answers it, if the local router has set the DTR signal high. Here again, the modem turns on DSR, DCD, and CTS signals to indicate call connection, carrier detect, and ready state.
Call disconnection can occur because of telephone line failure, because one of the routers was turned off or was taken down, or because of a power failure. Each modem detects the call disconnection by the absence of the carrier. Following this detection, the modem disconnects the call and turns off the DSR, DCD, and CTS signals.
The modem signals DSR, DCD, and CTS are tracked by the router, and the router, in turn, turns off the DTR when any of these signals are off. The router keeps the DTR low for a few seconds to allow the modem to complete the actions needed for terminating the call, and raises the DTR to trigger redialing. When the modem detects the DTR off-to-on transition, it goes through the procedure for reconnection; on successful reconnection, the modem raises the DSR, DCD, and CTS signals. Should the reconnection attempt fail, the modem resets any signals it might have raised during the reconnection.
Even when the reconnection attempt fails, the router has the DTR on for approximately two minutes before taking it down. This delay spaces the reattempts to connect two minutes apart, preventing excessive telephone traffic. If the connection does occur, the DTR remains on indefinitely, and the dialed connection then simulates a permanent connection.
The router actions remain the same, whether the router is connected to a calling modem or an answering modem. Hence, the router code is unaware of the asymmetry in the dialed connection.
Note that although the preceding description is based on the experience gained from using Hayes* smart modems, it is valid for a wide variety of compatible modems.
Following are the dial-up synchronous modem requirements:
The following example illustrates the programming needed to set the Hayes ULTRA* 14,400-bps modem for dialed synchronous operation. To do this, connect the modem to a terminal device or PC with a terminal emulation program. The router provides a method of addressing the modem through the CPECFG program (refer to "Configuring Modems and DTR-Controlled Devices" on page 87 for information about using CPECFG).
The left dip switch (sw 1 , seen when the front cover is removed) has the following settings:
This switch is set to DOWN after the modem is configured for autodial/ autoanswer. This prevents the synchronous data from accidentally being interpreted as commands (for example, when the DTR is turned off).
AT&F; &F - Recall Factory settingsAT&Z0=<dest tel no>; &Z0 - store no to be calledAT&Q2&C1&D2; &Q2 - Stored No redial on DTR OFF -> ON; &C1 - Track status of DCD; &D2 - Track DTR, DTR ON -> OFF go to cmd stateATS37=11 S37=11 - Connect to remote modem at 14400bps speedATE0Q1&Y0&W0 E0 - Disable character echoing; Q1 - DO not return result codes; &Y0 - Select profile `0' as power on config; &W0 - store as profile `0'
AT&F; &F - Recall Factory settingsAT&Q1&C1&D2S0=2; &Q1 - Sync mode 1 (async to sync on connect); &C1 - Track status of DCD (don't ignore); &D2 - Monitor DTR, DTR ON -> OFF enter cmd stateCall automatically answered only if DTR is ON; S0=2 Auto Answer after 2 ringsATS37=11; S37=11 - Connect to remote modem at 14400bps speedATE0Q1&Y0&W0; E0 - Disable character echoing; Q1 - DO not return result codes; &Y0 - Select profile `0' as power on config; &W0 - store as profile `0'
Should the need arise to reprogram the modem (for example, to change the destination telephone number), the following procedure should be adopted. Because character echoing and result code returns have been disabled, the modem does not respond to a user's attempt to communicate with it (in asynchronous mode). To reprogram the modem, complete the following steps:
Turn off the modem.
Set dip switch 1 to the UP (smart mode) position.
Turn on the modem.
Enter the following modem command:
ATE1Q0; E1 - Enable character echoing
; Q0 - Enable returning of result codes
Novell's most recent products, and those in development, are designed to be modem independent . This enables new modems to be supported by these Novell products without a new version of the software being released. All that is required is to load the appropriate modem description file onto the specified system.
Novell products can interpret modem description files and execute script commands in the files to perform modem operations as the application requires. Neither the modem control components nor the software products themselves are specific to any one modem or set of modems. Any details specific to modems are contained in the modem description files.
When Novell products are installed, modem description files are copied along with other product files. As users configure the software, they identify the modems to be used from lists of modem names. Any modem that has a modem description is presented in these lists for the user to select.
When a port is configured from the Network Interfaces screen of the Novell Internet Access Server Configuration utility (NIASCFG), the type of modem attached to the port is specified in the Modem/DCE Device field. This option enables you to select a modem initialization script that is specified in the compiled NIASCERT.MDC, NIASMDM1.MDC, and NIASMDM2.MDC files in the SYS:SYSTEM directory.
Because these files are compiled, they require a special modem script editing tool, WMDMMGR, to read them and make changes to them. Multiple *.MDC (Modem Definition Compiled) files can exist in SYS:SYSTEM; however, if a description of a particular type of modem appears in multiple *.MDC files, there is no guarantee as to which description is used. To avoid confusion, a modem description should appear in only one *.MDC file. When Novell Internet Access Server 4.1 is installed, any previously installed *.MDC files are moved to the SYS:SYSTEM\BACKUP directory. Only files included in Novell Internet Access Server 4.1 remain in the SYS:SYSTEM directory.
If you create new modem description files, copy them to the SYS:SYSTEM directory so that they are available to the routing software. If the routing software is running, issue the REINITIALIZE SYSTEM command to have the modem script changes take effect
This section discusses the format and content of the information present in the modem description files. The method of defining the capabilities of a modem is specified, and the process of constructing scripts to accomplish modem operations is outlined. Several examples illustrate uses of the details presented.
A modem description file includes information describing both a modem vendor and individual modems. The information about the modem vendor is specified first, with from one to many descriptions of modems following.
One way to organize modem descriptions is to collect information about all modems from one vendor into a single file. This makes it easy to register the single filename with Novell. Another possibility is to group modems by family, as might be done with all the XYZ Xxxx sample models. We suggest that all modems manufactured by a vendor be located in a small number of files.
A typical modem description file includes the following:
The vendor information begins with the vendor's name, which identifies the company creating the description file. A copyright notice can be included to protect the company's rights. Version information should be added to allow tracking of additions or corrections to description information.
Modem-specific information begins with a line specifying the modem name. This name must be unique within the entire set of modem names known to Novell and should include some form of the vendor's name to avoid conflicting with any other vendor's descriptions.
Modem option lines supply information regarding the features, capabilities, and default values of the modem. This information is needed by the modem control components to determine which logical operations can be performed. The information would include the highest interface bit rate possible for the modem, the link types the modem can use (analog, ISDN, and so on), and whether the modem supports a fixed rate.
Modem scripts that perform particular operations are specified. These scripts are simply strings encoding suboperations to be executed that together accomplish the desired operation. Multiple sequences of commands can be combined, if required.
The final section of a modem description file contains the strings used to decode a modem's responses when the modem answers an incoming call. For example, the string returned by a modem when a call is successful might be associated with the CONNECT response. Additional response recognition allows modem control components to record the options that are negotiated for this call.
This section describes the components that can be used in modem description files.
The following fields are part of the vendor description:
The manufacturer and copyright string values can be up to 80 characters long. The version numbers can have numeric values from 0 to 99. Currently, the values are not used directly by modem control components, but they are provided for use by modem vendors.
This section explains the modem keywords and how to use them.
The modem name string value can be up to 39 characters and must be unique within the entire set of modem names known to Novell.
There can be multiple descriptions for the same modem, with each appropriate for distinct circumstances. For instance, it might be found that most revisions of a particular modem can be initialized quickly, but that some ROM levels require delays between output characters. Rather than force all users to wait for a lengthy initialization operation, it is possible to create two descriptions, as follows:
XYZ Modem XxxxXYZ Modem Xxxx (Slow Init)
The following rate options require values to be defined:
When a modem operation specifies the use of fixed rate mode, the FIXED rate option supplies the bit rate used to communicate with the modem. When that mode is not selected, modem control uses this option to determine the default bit rate for the interface to the modem.
Modems can be initialized to use one unchanging bit rate between themselves and the data terminal equipment (DTE). This bit rate is usually set to a value high enough to permit use of compression, no matter what line speed is used on a connection. The numeric value is the bit rate to be used when the modem is put into fixed rate mode. NOTE: This option also implies that fixed rates are supported by the modem.
Some modems permit the use of the FIXED DTE RATE feature, but with only one allowable bit rate, as specified by the FIXED option. This option specifies that this restriction is true for this modem.
The set of interface bit rates that can be used to communicate from the DTE to a modem usually has an upper bound. This option supplies the maximum interface bit rate to be used with a modem. The numeric value for this option is the maximum rate in bits per second.
Depending on how your modem is being used, two of the following options might have to be configured. The first two of the following options are configurable; the last two options are not configurable. These options are described as follows:
Some modems require a greater amount of time to process complex commands. Complex commands that are sent to these modems one character at a time are successful. This option enables you to specify the amount of time to insert between characters of selected commands.
The numeric value is the time, in tenths of a second, that modem control should wait between sending characters. There are two script operations for output: one inserts delays between characters; the other does not insert delays between characters. If this option is not specified, the default delay is zero (no delay).
Possible values are as follows:
Modem scripts are text strings that are sent to the modem to cause a particular behavior. They are associated with a particular modem capability and are transmitted to the modem when the application software wants to invoke that operation.
More information on the content and creation of modem scripts is given later in Script Operations Individual scripts are summarized here:
This script enables the use of any of the error correcting protocols implemented by a modem when the next data connection is begun. Because which protocols might be activated depends on the remote modem, this script only specifies that the best possible protocol for each connection be used. Through monitoring the negotiation progress responses, the modem control components can be informed of the characteristics of the protocol activated.
This script places the modem in the mode of automatically answering incoming telephone calls. A connection can begin without intervention by modem control. Modem control monitors the progress of connection initiation and detects when the connection is complete and data transfer can begin.
This script enables the use of any of the data compression methods implemented by the modem when the next data connection is begun. Because the particular compression method employed depends partly on the remote modem, this script specifies only the preferred method to be used. Through monitoring the negotiation progress responses, the modem control components can be informed of the characteristics of the method activated.
This script is executed when a call origination operation is requested on a switched line. The operation request parameters include whether the dialing should use pulse or touch-tone signaling, and the destination telephone number. These parameters are inserted into the dial script string using the substitution tags [T] and [P] . These tags are described in detail in Script Operations.
This script places the modem into fixed interface bit rate mode. This allows the interface to be programmed to one bit rate that can be used for all subsequent connections. The actual rate used is determined by the associated FIXED rate value and SINGLE FIXED RATE rate flag.
This script causes the modem to disconnect any call that might be in progress (that is, place the modem on-hook). This script should specify all required operations that ensure that the call is disconnected, irrespective of the current modem state.
This string is part of the overall HANGUP script for the modem. To change only the ESCAPE output string, you can type directly into the edit box. To modify the overall HANGUP script and sequence, select the HANGUP button.
This script places the modem into a hardware flow-controlled mode. In this mode, data transfer between modem and interface is controlled through the use of the Request-to-Send (RTS) and Clear-to-Send (CTS) RS-232 signals. Each signal controls data transfer in one direction.
This string is part of the overall INIT script for the modem. To change only the RESET output string, you can type directly into the edit box. To modify the overall initialization script and sequence, select the INIT button.
This script causes the modem to be initialized to a known state. This state must have all optional features disabled. That is, the purpose of the INIT script is to put the modem into a state in which any of the other features can then be added by individually executing scripts. The INIT script is usually the first script executed when a modem operation is begun; the only script that could precede it is the HANGUP script to disconnect a call in progress. The INIT script can make no assumptions about the previous state of the modem. Indeed, the previous user of a modem might not have been Novell's modem control; therefore, not even modem control knows the state of a modem. The script must reset everything that can be affected by modem commands. This includes features like echo, call progress, result code, modem signal usage, flow control modes, and so forth. The script must set the correct modes so that modem response strings can be recognized.
When a modem initialization operation is requested and the leased-line feature is requested, this script is executed to place the modem into leased-line mode. In some cases, this feature is not under control by commands, but rather, some switches must be set. In this case, the script might be absent.
This script is executed when a call answer operation is requested on a leased line. The modem should attempt to connect to the remote modem using answering frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when call origination is requested on a leased line. The modem should attempt to connect to the remote modem using origination frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when a manual call answer operation is requested. The modem should attempt to connect to the remote modem using answering frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when manual call origination is requested. The modem should attempt to connect to the remote modem using origination frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when a modem is initialized for a synchronous connection. Certain modems allow synchronous mode connections, especially when trying to connect to mainframes and UNIX-based systems.
A modem script contains a sequence of nano-operations that inform modem control about which actions to perform. These actions include output of ASCII characters, controlling interface signals, checking for expected input, and so forth. There is no facility for conditional execution of nano-operations; the entire script is executed unless an error occurs.
Each nano-operation consists of an alphabetic character optionally followed by parameters for that operation. These values can be string or time values, or other modifiers for that basic operation.
Following are the operations summaries:
This operation turns on the asynchronous break signal momentarily. Toggling the break signal can be used to switch a modem into command mode.
The break operation can be qualified by a decimal number giving the length of time, in tenths of a second, for which break is to be turned on. If a time value is not given, the default break of 0.5 second is used.
This operation controls the DTR signal to the modem. The DTR signal is turned off momentarily and then turned on again. Turning off this signal can be used to switch a modem out of data transfer mode. An optional parameter, TIME is the duration, in tenths of a second, for the DTR signal to be turned off. If a time value is not given, the default DTR off time of 0.5 second is used.
Characters that have been buffered for output or input but not yet processed can be discarded by this operation. This might be useful when modem responses, up to a point, can safely be ignored, or if prior output should be discarded when new commands are entered. The flush operation must specify which streams should be flushed.
This operation allows a script to check for a specific string to be received from a modem. For example, after most modem commands, a script should check for the returned indication of success, usually OK. There are two variants: must match or optional match . The operation can optionally be qualified by a decimal number specifying the maximum time to wait for this response. This value is specified in tenths of a second. If it is not given, the default value of 5 seconds is used. Modem control continues receiving characters from the modem until one of two occurrences. If a matching string from the modem is completed, the nano-operation finishes and the script continues. If a match is not completed and the timeout period has elapsed since the last character was received from the modem, an input timeout is declared. If this was a must match input string operation, the timeout causes the script to be terminated with a bad modem response error code. Otherwise, the timeout simply terminates the optional match operation and continues with the rest of the script.
This operation allows output of character strings from the script to a modem. The output string can contain any non-null, noncontrol ASCII characters. If a delay must be inserted between characters, the Output with Delay operation uses the delay time specified by the OUTPUT DELAY option value. The string to be output is bounded by a delimiter character chosen by the script creator. The script creator should choose a string delimiter character that is not used for any interactions with the modem. This character should not be an alphanumeric character because this would make reading descriptions difficult. A survey of several modems has identified the many punctuation characters that are used within modem commands and responses. The following set of characters is recommended for use: ` < ^ _ { } | : ' , By convention, a colon (:) is used. Control characters can be inserted into output strings using the back-quote character (` ). Variable strings can be substituted in output or input strings with the use of a substitution marker. A substitution is indicated by a substitution tag name surrounded by brackets ([ ]). For example, the substitution of the tone or pulse modifier and the phone number in a dial-out command might be coded as follows: ATD[T][N] where [T] is replaced with T or P , and [N] is replaced with a dial number. Only a limited number of substitution tags are defined, and the substituted strings are not variable by modem type. The predefined tags are as follows:
Care should be taken that the longest command sent to a modem does not exceed what the modem can handle. Many modems are limited to a maximum of 40 command characters, excluding the leading AT , spaces, hyphens, and final carriage return. The input command can be used to break up long command-output sequences. This operation allows a script to pause execution for a period of time. This is useful when modems might require additional time to complete complicated modem commands. An optional parameter, TIME is the pause time in tenths of a second. If a time value is not given, the default time value of 1 second is used (time = 10). This operation skips all the responses from a previous command before issuing a new command. It causes a wait until the modem remains continuously quiet for the specified time. An optional parameter, TIME is the pause time in tenths of a second. If a time value is not given, the default time value of 1 second is used (time = 10). This nano-operation discards any data received from the modem. Whenever a character is received, the elapsed time timer is reset to 0. When the elapsed time timer reaches the specified wait time value, the nano-operation completes successfully. An additional timer records the total time since the nano-operation began. If this timer reaches the sum of the specified wait time plus 5 seconds, a timeout is declared and the nano-operation completes unsuccessfully, causing the script to be terminated with an error. This operation allows scripts to change the data rate used to communicate with the modem. This is used with modems that do not automatically resynchronize interface data rates after switching back to command mode from data transfer mode. After execution of this operation, any further output or input through the interface uses this data rate. Some asynchronous equipment must flush one or both of the input and output streams when changing data rates.
The response strings in a modem description allow recognition and interpretation of data sent from the modem to the DTE. Response strings inform the modem control software of the success or failure of a command. These strings also let modem control detect when a call is arriving.
As the responses generated differ between modems, the modem vendor must supply information to allow modem control to recognize responses. Response strings contain from one to many pairs of substrings, the first giving the input string to be recognized and the second representing the standard meaning of the string.
With the ever more complex responses found in newer modems, it is sometimes necessary to perform multistage matching of response strings. An example would be when the modem is using negotiation progress monitoring to capture added information about connections. When the PROTOCOL response is received, the first stage of recognition would identify the input as the PROTOCOL message. The second stage of recognition would then identify the particular substrings that might be present in this message. This progression from one stage to the next is called chaining.
Modem control accumulates ASCII characters received from a modem until a carriage return character (\x0D or decimal 13 ) is received; all other control characters are ignored. The accumulated string is then compared to the match strings in the RESPONSES keyword string. When a match is found, the meaning is interpreted and the appropriate action is taken.
Modem response strings can comprise two string elements: the match string and the meanings string .
The first of each pair of strings in the RESPONSES string is known as the match string . When modem control is monitoring modem responses, characters received from a modem are collected until a carriage return is received. The input string is then compared against all the match strings found in Modem Responses. This matching operation is case-insensitive and proceeds in the same order in which the string occurred in the description file.
Match strings do not need to be the entire response string to declare a match. Only the initial characters of a response must match the match string. Thus, the match string ERR matches both the response strings ERROR and ERRONEOUS , but not ERASE . However, this might make the order in which match strings are tried even more important.
The second string of each pair of strings is known as the meanings string . The interpretation of this string defines what the recognized response means to modem control. This includes whether the response is a success, a failure, or some intermediate indication. When certain optional connection features are recognized, they can be signaled to modem control by this method. Finally, this is the way that bit rates are given to modem control. There are four types of meanings information, as shown in Table 6 : status, rate, feature, and match chaining. The status and feature values are decimal indices into tables used by modem control. The rate decimal value is the actual data rate in bits per second. The match chaining value is described in Match Chaining. STATUS Reports a status; might terminate scanning. RATE Reports a data rate. FEATURE Reports an enabled feature for this connection. CHAINING Continues scanning using another string.
Table 6. Meanings String Types
Type
Meaning
Status information is used to notify modem control when something of significance has been discovered in a response, or to report that scanning should continue. Possible status types are as follows:
NONE |
CONNECT |
RESERVED 1 |
BUSY |
RESERVED 2 |
NO_ANSWER |
RESERVED 3 |
NO_CARRIER |
RESERVED 4 |
ERROR |
RESERVED 5 |
NO_DIALTONE |
OK |
VOICE |
RING |
UNKNOWN |
RRING |
|
The rate meaning tells modem control what the current line data rate is in bits per second. For most modems that implement negotiation progress messages, this rate value can be captured from the CARRIER response by using the <R> construct, as in CARRIER <R> or CONNECT <R> . This construct matches any speed response from the modem and captures that value to return it in the rate definition command.
The feature values indicate to modem control when optional connection features have been enabled on the current connection. Information about which features are enabled or disabled is made available to applications. Applications can use this information to determine whether they must independently perform error control or data compression for a connection. The features are as follows:.
NONE |
V.42BIS |
ERROR_CONTROL |
UNBALANCED |
MNP5 |
SYNCHRONOUS |
The match chaining directs modem control to continue matching using the remainder of the input string (after the initially matched portion) and using a different modem response string. This permits the multistage matching that is so useful with complex sets of responses, such as negotiation progress messages. The following example illustrates this approach:
RESPONSE = PROTOCOLRESPONSES STRING 1 = ERROR-CONTROLInput from modem: PROTOCOL: ERROR-CONTROL/LAP-B
The first string is part of the first stage matching string formed from all the RESPONSES keyword strings. Modem control interprets it to mean that the response beginning with PROTOCOL is not a final response; rather, that additional matching must be performed using RESPONSES STRING 1 .
Modem control begins checking the remainder of the input string repeatedly against the RESPONSES STRING 1 match strings. Each time the match strings are used up, modem control advances to the next character in the input string and tries again. This process continues until all the characters in the input string have been exhausted. In this manner, modem control finds the ERROR-CONTROL substring and notes that feature one, ERROR CONTROL , is enabled for this connection.
Novell's modem control is implemented in multiple environments. This section briefly describes how modem description files are used in each environment.
Modem description files on a NetWare server are placed in a subdirectory accessible to NetWare Loadable ModuleTM (NLMTM ) files. The files for both the routing and the remote access components of Novell Internet Access Server 4.1 are located in the SYS:SYSTEM directory. You should work in this directory when adding new scripts, editing existing scripts, and compiling scripts. Novell Internet Access Server 4.1 uses all compiled scripts with the .MDC extension that exist in the SYS:SYSTEM directory.
The modem control components of the remote access software exist in a subdirectory called SYS:SYSTEM. All files containing compiled modem descriptions are copied to this subdirectory. When NetWare Asynchronous I/O (AIO) is loaded, it searches this subdirectory for files with the extension .MDC. AIO then creates a list of all modem names defined in these files and indicates which file contains the description for each modem. When one of the remote access services attempts a modem operation on a port, AIO determines which modem is attached to that port and ensures that the modem's description has been read into memory. AIO then starts the execution of the operation using the service's request parameters and the modem description.
The standard set of scripts that are included in the remote access software are contained in the following three files:
The routing software uses modem definition files that are placed in the SYS:SYSTEM directory. It interprets these files as required for modem control. The standard set of scripts that are included in the routing software are contained in the following three files:
| |