Mega Top 1

home *** CD-ROM | disk | FTP | other *** search

/ Mega Top 1 / os2_top1.zip / os2_top1 / APPS / DATACOM / DIVERSEN / SNAAOS2 / SNAAOS2.SCR (.txt) < prev

Wrap

Microsoft Windows Help File Content | 1992-12-30 | 48KB | 916 lines

:userdoc. :prolog. :docprof fbc=no duplex=sb tipage=right bodyhd0='Section' layout=1 ldrdots=yes. :title. :tline.User's Guide for the OS/2 SNA over Async Prototype Package :etitle. :author.James J. Martin :date. :address. :aline.F93A/B673 :aline.RTP :aline.JJM at RALVM6 :eaddress. :eprolog. :frontm. :tipage. :toc. :body. :h1.Abstract :p.This document is the user's guide for the SNA-A OS/2 prototype code. The code provided is PROTOTYPE code and is NOT a part of the OS/2 Communications Manager product. All service issues and questions will be handled through the SNAASYNC forum on the IBMPC disk. This package is available on both OS2TOOLS and MKTTOOLS disks. The package is also available on CompuServe via the APPC Info Exchange Forum. The intent is to make the prototype available to any (internal and external) OS/2 Communications Manager customers. If the package is distributed to external customers, the following must be understood: :li.Distribution/service for this package may be stopped without notice. :li.Communications Manager's service organization MUST NOT BE called for anything dealing with this prototype. :eul. :h1.Introduction :p.SNA-A, also referred to as SNA over async or SDLC over async, is an extension to the SNA architecture allowing SNA traffic to flow across asynchronous (start/stop) communications lines. This document is the user's guide for the prototype code which enhances OS/2's Communications Manager (EE 1.3 and ES 1.0) with SNA-A connectivity. An overview of SNA-A is provided, followed by a detailed description of how to install, configure and operate the prototype. Several appendices have been added to provide additional information. I would recommend reading section 2 (SNA-A Background) and then Appendix A (Summary of the SNA-A protocol) before proceeding with sections 3 through 5 which discuss the prototype. :h1.Background :p.Early SNA simply ignored asynchronous communications. The thinking was that synchronous communications (e.g., SDLC) would be sufficient for any PC requiring remote connections into an SNA network. This decision has caused many problems for many customers. Work arounds developed to fill this void include protocol converters and (non IBM) SNA implementations which support some form of SNA over async communication (such as Hayes autoSync modems). Since the PC's inception, there has been a requirement for SNA over async. :p.It is estimated that 40% of all data communications travels across asynchronous lines. The volume of asynchronous communications will continue to increase (as will the demand for SNA over async). Some reasons for this include: :li.The number of PC's, especially laptops, in use will continue to increase. :li.The increase use of async dialup information services (e.g., BBS, CompuServe, Dow Jones, etc.). :li.A growing requirement for remote any-to-any connectivity. :eol. :p.However, the key factor which will keep async as the dominant method of remote PC communications is technology. PC technology has generated laptops, notebooks, palmtops and pen based machines. These new forms of PC's are forecasted to be the highest growing segments of the PC market. Each of these machines rely heavily (if not solely) on asynchronous communications. :p.Additionally, PC technology has created the "type 2" COM port which provides separate tx and rx 16 byte deep FIFO's. Such ports allow PC's to support async data rates of over 38.4 kbps. All PS/2's are shipped with a type 2 COM port on the system board. The recently released "type 3" COM port (available on the system board COM port of the PS/2 MOD 90 and MOD 95) supports normal CPU memory mapped I/O or DMA I/O. Furthermore the port provides hardware capabilities for a character hunt mode. The type 3 COM port will allow the PC to support async protocols at line speeds of 64 kbps comfortably. :p.Modem technology is keeping pace with PC async technology (in fact the modem industry is being driven by the PC industry). The standard PC async modem is 2400 bps. Within the next few years, the standard will be 9600 bps modems capable of supporting error correcting protocols and compression. Asynchronous data link throughputs of 38.4 kbps will become the standard. :p.Two completely new forms of PC communications have emerged: RF modem and infrared. RF modem technology has created a new industry: mobile communications. This technology uses cellular and RF packet networks (e.g., the Ardis network) modems which are all async based (at least at the DTE level). Infrared technology (available in some palmtops) allows unconnected, line of sight point to point communications. To the DTE, the infrared port looks like a COM port. Both of these technologies are really "application enablers". They will provide the power of PC's to industries (such as the service industries) which in the past have not been able to exploit computers. :p.SNA-A will be able to exploit these future technological advances and trends. Today, the driving force behind SNA-A is the laptop market. SNA-A adds value by enabling laptops (as well as the existing base of PC's) to be remote SNA nodes without having to buy additional hardware adapters, special modems or FEP's such as protocol converters. Any SNA customer with a salesforce has a requirement to be able to take their SNA applications "on the road". SNA-A is the IBM solution for this requirement. :p.Architecturally, SNA-A is quite simple to understand. SNA-A consists of an SNA tower using an SDLC data link, except instead of using synchronous hardware, it uses asynchronous ports. Traditional SDLC has an SDLC protocol stack driving a low level synchronous MAC (machine access layer). The MAC layer is responsible for sending and receiving frames across the wire. SNA-A uses the same SDLC protocol stack (and consequently uses SDLC frames), but substitutes an asynchronous MAC in place of the synchronous MAC. Looking at the data on the wire, rather than seeing a bit oriented synchronous data stream, you now will see a character oriented start/stop data stream. At the frame level on the wire, you will see SDLC frames using start/stop communications. :p.The SNA-A async framing MAC, defined internally by Architecture Working Paper (AWP) 224, is based on an ISO standard (3309) which defines HDLC frame formats for start/stop communications. Appendix A describes the async framing technique in detail. :p.Since SNA-A defines a new SNA data link, both nodes must be equipped and configured properly (both must have async ports and both must have the port controlled by the same SNA-A data link). SNA-A can be used with a switched or nonswitched line, although it obviously is intended for dial-up lines. The typical customer scenario will have many remote SNA-A nodes which periodically dial into an office based SNA node supporting the same SNA-A link. Therefore there is a requirement for a SNA node capable of supporting a large number of SNA-A ports. More importantly, this SNA "async concentrator" node must be scalable with respect to both performance and cost. Furthermore, if the partner LU is not located on this node, either a gateway service or APPN network node capability is required to be able to route the session traffic. :p.Current available products which can serve as this async concentrator SNA node are AS/400 or OS/2 (via this prototype). The AS/400 is a very good choice since it can support many SNA-A ports. OS/2 can be used, however it has the limitation of supporting only 2 SNA-A ports. Both the AS/400 and OS/2 are capable of being APPN network nodes and consequently can route LU6.2 session traffic into a customer's SNA network. Future IBM SNA products will be introduced over the next several years which can also serve in this role. :p.The remote SNA node platforms can be either DOS (using NS/DOS, a memory light DOS APPC CPI-C implementation available in 3Q92) or OS/2 (via this prototype). Due to the layering within OS/2's Communications Manager, the SNA-A data link can be used by all SNA components: 3270 emulator, 5250 emulator, APPC/APPN, SNA Gateway. :h1.Overview of the OS/2 SNA-A Prototype :p.The OS/2 SNA-A prototype code relies on the existing SDLC support provided by Communications Manager (CM) EE 1.3 and ES 1.0. A CM SDLC data link requires the Multi Protocol Adapter (MPA). The prototype code has replaced the bottem end of the SDLC stack which talked to the MPA and inserted the async framing MAC which talks to COM ports. The prototype will support up to 2 COM ports (COM1 and/or COM2). Examples of COM ports supported: :li.PS/2 system board COM port :li.Dual async adapters :li.MultiProtocol Adapters (MPAs) configured for async :eol. :p.A point which needs to be stressed, the SNA over async support is completely separate from the current CM async support (ACDI). In fact with the initial release of the prototype (we may or may not fix this), you can not have ACDI loaded. Consequently, you can not dedicate one COM port for ACDI and one for SNA-A. :p.This new data link (let's call it ADLC) is really fooling CM into thinking that it is an SDLC data link. Therefore, the operation of the ADLC data link is done using the SDLC support of CM. To activate and deactivate the ADLC data link, you would use the CM subsystem data link control facilities by selecting SDLC. Also, to configure the ADLC data link, you would use the SDLC configuration screens. When you specify the SDLC Adapter 0, this translates to COM1. SDLC Adapter 1 translates to COM2. :p.Because this new data link shares features of the SDLC stack, it also inherits the limitations. For example, as CM can only support up to 2 SDLC ports (and only 1 on AT's), CM can only drive up to 2 SNA-A ports. Our implementation limits the SDLC stack to support either 2 SDLC ports OR 2 COM ports, not 1 of each. One limitation not inherited is on an AT, CM will be able to support 2 SNA-A ports. :p.As with SDLC, the ADLC data link can be used across a switched or unswitched link. A serial cable (either 9 pin "D" shell connector or a 25 pin RS-232 connector depending on the machine) is obviously required. A switched link requires a modem and a nonswitched link will require either a modem eliminator or a NULL modem cable configured to connect 2 serial ports directly together. :p.Configuration of the ADLC data link is done using the CM SDLC config panels. We have introduced several optional async specific config parameters as well. For example, the data rate, the transparency level or an autodial modem command string are configurable options supported by the prototype. This type of configuration data is entered in the config.sys "DEVICE" statement of the ADLC device driver. Configuration will be discussed in detail later in this document. :p.Some miscellaneous pieces of information concerning the prototype: :li.Autobaud detect is not supported (although a later section will explain how some modems can provide a work around). :li.A limited form of transparency level negotiations (see appendix A) has been implemented. The transparency level is configurable however, we are not able to dynamically change the transparency level as specified by the transparency negotiations protocol. :li.The max supported data rate is currently 38. 4kbs on 386 PS/2's (however, an AT is limited to 4800 bps). :li.The normal async line configuration (in fact the default) is 8 data bits per character, 1 start and 1 stop bit with no parity. :li.Currently the implementation prevents other async drivers from being loaded (e.g., COM02.SYS and ACDI drivers). :eol. :h1.Installation and Configuration of the Prototype :p.The steps to install and configure the prototype are summarized below. We will explain each step in detail. :li.Install/configure the hardware :li.Install the prototype code :li.Configure Communications Manager for an SDLC data link :li.Configure the rest of SNA as needed :li.Configure the config.sys async specific options :eol. WARNING: With the current release of the prototype, make sure that CM's async support (ACDI) is not loaded AND OS/2's async device drivers (COM01.SYS, COM02.SYS) are not loaded!!!!!!!!!!! :h2.Install and configure the hardware. :p.The prototype supports only COM1 or COM2 ports. Using a reference disk, verify that the COM port(s) to be used are setup for either serial 1 (COM1) or serial 2 (COM2). On an L40 (and any other laptop), verify that the COM port is activated as well. :h2.Install the prototype code. The following assumes CM has been installed with SDLC configured. The SDLC CM support requires 2 modules: :li.C:\CMLIB\SDLCDD.SYS :li.C:\CMLIB\DLL\ACSSDDLC.DLL :eol. :p.If you do not have these modules, you can manually pull the files from the installation diskettes or you can do a REINST of CM to get them. The only one you will need for SNA-A is ACSSDDLC.DLL. The prototype code replaces SDLCDD.SYS. :p.The prototype has only 1 module which needs to be loaded onto the system. This module is effectively replacing the existing SDLC device driver (c:\cmlib\sdlcdd.sys). :li.First, create a new directory c:\cmlib\async :li.Next, copy the module into this directory using the module name "ADLCDD.SYS" :li.Next, in the file c:\config.sys, comment out the existing DEVICE=C:\CMLIB\SDLCDD.SYS statement if it exists by adding an REM in front of the line (REM DEVICE=C:\CMLIB\SDLCDD.SYS). Then add a new device driver statement for the SNA-A device driver (DEVICE=C:\CMLIB\ASYNC\ADLCDD.SYS). :eol. :h2.Configure CM for an SDLC data link. :p.In this step, you follow the CM screens to create an SDLC data link. If one exists, you can use it. The config sequences to do this can be summarized as: :li.Go into the CM main menu :li.Select Advanced :li.Select Configuration :li.Select SNA Feature Profiles :li.Select Data Link Control Profiles :li.Select SDLC :li.Select which adapter you want to use (Adapter 0 implies COM1, Adapter 1 implies COM2) :li.Select if you are creating, changing or displaying the SDLC link :li.All default SDLC profile configurations are ok, the options which you probably need to set: :li.switched or nonswitched :li.primary/secondary/negotiable (if unsure select negotiable) :li.select modem rate (full speed implies 9600 bps, half speed implies 2400 bps). :eol. :li.Hit Enter when done with this screen. A DSR timeout value of 5 minutes is fine. :li.Hit Enter again and select the local station address. Any value 0x01-0xFE is fine. Then select an XID repoll and non-XID repoll count :li.Hit Enter and you should get a message indicating the profile has been saved. :li.Hit the ESC key until you are prompted to Verify the configuration :li.After the Verify is completed you need to shutdown CM and bring it back up for the config changes to take affect. :eol. :h2.Configure the rest of SNA as needed. :p.Configure your SNA node as needed. Whenever you need to map a logical link to the ADLC data link, use SDLC. For example, the following is an excerpt from a wrkbase.ndf file (e.g., NS/2) defining a logical link using the COM1 port. :xmp. DEFINE_LOGICAL_LINK LINK_NAME(ASYNCLNK) ADJACENT_NODE_TYPE(LEARN) DLC_NAME(sdlc) ADAPTER_NUMBER(O) CP_CP_SESSION_SUPPORT(YES) ACTIVATE_AT_STARTUP(NO) PREFERRED_NN_SERVER(NO) LIMITED_RESOURCE(NO) LINK_STATION_ROLE(USE_ADAPTER_DEFINITION) FQ_ADJACENT_CP_NAME(USIBMSER.ASYNC_O1) COST_PER_CONNECT_TIME(USE_ADAPTER_DEFINITION) COST_PER_BYTE(USE_ADAPTER_DEFINITION) DESCRIPTION(Sample sdlc link to served EN); :exmp. :p.This link definition would be necessary only if the SNA-A link defines a logical link to an adjacent network node. :p.If you are going to configure the 3270 emulator to use the ADLC data link, simply configure the emulator to use SDLC. Likewise for the SNA Gateway. Refer to Appendix B for configuration examples. :h2.Configure the async specific options. :p.Since this prototype did not touch any higher layer code of CM (e.g., the configuration code), we needed a mechanism by which we can configure async related options specific to the ADLCDD data link. We used OS/2's mechanism of supplying parameters to device drivers at initialization time. In config.sys, each "DEVICE" statement can have an ascii string of characters which is made available to the device driver. The negative of this mechanism is whenever you want to change one of the config params, you must reboot the machine. The positive side, is that for normal use, these async specific config options are not necessary. The default values for most situations should be sufficient so that no parameters are required. :xmp.All config options must be entered in the following format: "/"<command id>{port id}="data" For example: DEVICE=C:\cmlib\async\adlcdd.sys /N0=1 /T=2 ********************************************************** *WARNING: There can not be any spaces in this line except * between config options. There CAN NOT be any * spaces within a config option!!!!!!!!!!!!!!!!!! ********************************************************** :exmp. :p.Some comments concerning the command line syntax: :li.The command id (in our example, N and T) specifies the config option. It must be in capital letters. :li.The port id is optional. This specifies which port (0 or 1) the config option will apply to. If this is not specified then the option will be done to both ports. :li.Port 0 maps to COM1 and Port 1 maps to COM2!!!!!!!!!!!!! :li.The data field is the data for the command. It usually will be a single character. :esl. :p.If an option command is not in the correct format, the prototype simply ignores it- no error message is generated!!!!!!!!!!!!!!!! So if you are trying to autodial but nothing is happening, recheck the syntax of the config command. The most likely problem is a blank space used. :p.Available option commands and data values: :xmp. /T<O|1>={O|1|2} This specifies the transparency level to be used. Note that a different level might be negotiated. The data: O implies Basic transparency 1 implies Flow control transparency 2 implies Full transparency :exmp. :p.Refer to Appendix A which explains the async protocol. Transparency is described there. :p.The default is flow control and will be used in 99% of the time. In fact, the default for all current SNA-A implementations (PCS,AS/400,NS/DOS and OS/2) is flow control transparency. :p.Full transparency implies control character transparency and 7 bit data (as opposed to 8 bit data) using 1 start, 1 stop bit and even parity. Note that Basic and flow control transparency implies 8 bit data, 1 start, 1 stop bit, no parity. :xmp. /N<O|1>={O|1|2} This configures transparency negotiations to be performed by the node. O implies transparency negotiations are disabled. 1 implies transparency negotiations are enabled and this node will act as the calling party. 2 implies transparency negotiations are enabled and this node will act as a called party. :exmp. :p.Refer to Appendix A for a description of transparency negotiations. :p.For a switched connection, the default is transparency negotiations are enabled and the role (caller or called party) does not matter (it is determined dynamically). :p.For unswitched, the default is to disable transparency negotiations. If you want to enable transparency negotiations for an unswitched line, you must use this config param and the 2 partners must be configured with different roles (one must be a caller and one must be a called). :p.The only time you need to use this config option is if you are unswitched and you want transparency negotiations. If you want to connect with PCS and NS/DOS over an unswitched, you must configure the OS/2 node with transparency negotiations enabled and and as a called party (/N=1). This is because both PCS and NS/DOS require transparency negotiations and are limited to being a caller only. If you are connecting to an AS/400 over an unswitched line (if going over a switched line you don't need this config param), you must configure this OS/2 node with transparency negotiations enabled and as a caller (/N=2). This is because the AS/400 requires all partners to implement transparency negotiations and it assumes a called party role. :xmp. /B<O|1>={O|1|2|3|4|5} This configures the data rates. data rate values: O: 12OO; 1: 24OO; 2: 48OO; 3: 96OO; 4: 19.2k; 5: 38.4k; :exmp. :p.If the CM config option "full speed" is set, then the data rate used is the option provided. If configured for half speed, we drop the data down by 2 speeds. For example, if you use /B=3 (9600 bps) but have the config option set for half speed, then the actual data rate will be 2400 bps. :p.Exceptions to this are if you specify config line options of 1200 or 2400 bps. If you use /B=1 (2400), then for half speed this results in a data rate of 1200 bps. If you use /B=0 (1200), then half speed has no effect- the data is still 1200 bps. Therefore, the lowest speed the prototype supports is 1200 bps. :p.The default (if no config params are given) will be 9600 bps for full speed, 2400 bps for half speed. :xmp. /D<O|1>="{ascii string up to 128 characters}" This is a modem init string which is output to the modem at each link activation. Autodial can be performed this way. For example, if you wanted to auto dial the phone # 9-123-4567 out COM1 port, the config data should be: /DO="AT DT 9-123-4567" ******************************************************** * WARNING: Be careful of illegal spaces. For example, * the following is not allowed: * /D0= "AT DT 9-123-4567" ******************************************************** :exmp. :p.The string must be encased in quotes. The first 2 ascii characters of the string must be AT to wakeup the AT command set of the modem. The string must be a valid AT command string. Mulitple commands can be sent in the same string. For example, if you wanted to keep the same autodial command, AND you want to enable the speaker audio output from the modem .. :p./D0="AT M1 DT 9-123-4567" :p.Consult the users guide of the modem for a description of the AT command set (or any other commands the modem can respond to). Also refer to Appendix C for configuration information for particular modems. :h1.Current Status of the Prototype :p.We have tested the prototype as follows.. :li.up to 38.4 kbps on an unswitched link :li.up to 9600 bps on a switched link :eol. :p.We have tested with the following modems .. :li.IBM 5853 and 7855 :li.L40's internal modem :eol. :p. (note: see Appendix C for details on configuring these modems.) :p.The following is planned on being added to the prototype in the near future: :li.Add modem to DTE flow control so that modem features such as modem to modem error correcting protocols and modem compression can be supported. :eol. :p.The following are known bugs: :li.For version ES 1.0, autodial does not work (it does work in EE 1.3 however). This will be fixed in the next release. :li.For OS/2 (versions 1.3), if a session is active across the ADLC data link (e.g., an APPC TP), and then if you go into the DOS box the TP will end in an error although the data link remains alive. :eol. :h1.Appendices :h2.Appendix A Summary of the Async Protocol :p.SNA-A implies an SDLC stack driving an async MAC. The async MAC is based on an ISO standard (3309) for HDLC framing across start/stop communications lines. The framing MAC can be summarized as follows: :p.The frame format used across the wire is the same as that defined by SDLC and HDLC with 2 exceptions: :li.start and stop bits that delimit each character :li.characters inserted for transparency as opposed to bit insertion techniques :eol. :p.The HDLC/SDLC frame format is illustrated below: __________________________________________________________ | FLAG | ADDR | CONTROL| I field | FCS | FLAG | ---------------------------------------------------------- :exmp. :p.The difference between an SDLC frame and an SDLC over async frame is that SNA-A frames are no longer a synchronous bit stream. The bit stream is divided into characters (typically 8 bits per character) with each character surrounded with a start and stop bit. Therefore, this protocol immediately has a 20 percent performance loss over traditional SDLC due to the overhead involved with the S/S bits. Although, modems which implement error correcting protocols (e.g., MNP) use synchronous communications across the wire. This will not eliminate the performance degradation (due to the overhead involved with the modem protocol) but it will normally be less than 20%. :p.Traditional SDLC (and HDLC) uses bit insertion and bit deletion for data transparency. This means that if the flag symbol (6 consecutive 1's followed by a 0) occurs within a frame (in between the start and stop flags), the transmitter will insert a 0 after the fifth consecutive 1 to hide the flag sequence. If the receiver receives 5 consecutive 1's followed by a 0, then it will delete the 0 from the data stream. This guarantees that the flag symbol will never occur within a frame. :p.The SNA-A version of transparency is character oriented rather than bit oriented. For example, if the flag character occurs in the frame (a flag is the character 0x7E), we hide the character with the use of an escape character followed by the original character with its sixth bit inverted. Hence the framing protocol has the essence of older character oriented data link protocols such as BSC. :p.However this introduces another special character (the escape character) which must also be hidden if it occurs in the frame. Therefore the following character transparency is performed by the transmitter. :li.(FLAG) 0x7E -> gets transmitted as 0x7D, 0x5E :li.(ESCAPE) 0x7D -> gets transmitted as 0x7D, 0x5D :eul. This is known as the basic transparency level. :p.The ISO standard (and the IBM architecture) identifies 2 further levels of character transparency. Each further level is optional and the partners must either negotiate or must be statically configured to operate at the same transparency level. :p.Flow control transparency is meant to hide XON/XOFF characters within the frame. Obviously, this level of transparency is used if XON/XOFF flow control active. All IBM implementations use this level of transparency as the default level. Flow control transparency is defined as: :li.(XON) 0x11 -> gets transmitted as 0x7D, 0x31 :li.(XOFF)0x13 -> gets transmitted as 0x7D, 0x33 :li.(FLAG) 0x7E -> gets transmitted as 0x7D, 0x5E :li.(ESCAPE) 0x7D -> gets transmitted as 0x7D, 0x5D :eul. :p.The final level of character transparency is control character transparency. This is meant to hide non-ascii characters. It includes basic and flow control transparency. Additionally, characters in the range 0x00-0x1f plus a 0x7f character get hidden using the same transparency method as defined above. :p.In addition to character transparency, the async framing protocol handles 7 bit data networks. 7 bit data transparency is a technique allowing 8 bit characters to flow across a 7 bit async data wire. 7 bit data transparency must be either negotiated dynamically at link bringup or statically configured. :p.The transparency algorithm is fairly straight forward. The source data (8 bit characters) is divided into blocks of 7 characters. For each block of 7 characters sent out on the wire, an eighth character is additionally transmitted. This eighth character, the suffix byte, contains the most significant bit of each preceeding 7 bytes of the source block. The receiver would need to collect the first 7 characters of each incoming block and when the 8'th character is received, it regenerates the original 7 data bytes. :p.If the source block contained less than 7 characters (e.g., the final block of a frame), the suffix character would have its most significant bits (ie., the unused bits) cleared. The receiver detects this case if it receives the end of frame flag and if it has not received a full 7 byte block of characters. :p.When a link is activated, prior to any SNA XID exchanges, a process know as transparency negotiations is performed. Transparency negotiations (which is not a part of the ISO standard) allows 2 partners to negotiate: :li.data rate :li.character format (7 or 8 bits/character, even/odd or no parity) :li.the transparency level (basic,flow or full: full transparency implies control character transparency plus 7 bit data transparency). :eol. :p.Transparency negotiations works as follows. There is a called party and a caller party (this is the transparecy role configured for the station). Several IBM SNA-A products have a fixed transparency role. For example, NS/DOS is always a caller and AS/400 is always a called party. The OS/2 prototype can be either or none, it is a configurable option (using the "/N" config parameter). :p.The caller party ALWAYS initiates the link bringup. It will xmit a series of NULL XID frames. Once the called party has received 3 good NULL XID frames, it responds by xmitting a matching series of NULL XID frames. Since it is a known pattern being sent, the called party can do autobaud detect. The frame is sent by the caller using its desired transparency level. All IBM products use either flow control or full transparency. The called party is able to determine the tranparency level by looking at the NULL XID data. After this exchange of NULL XID's, normal SNA XID exchange occurs and the link comes up. :h2.Appendix B: Configuration examples :p.The OS/2 prototype can currently connect with: :li.another OS/2 machine also configured with the ADLC link :li.NS/DOS configured with the async router :li.AS/400 (limited to just APPC over async) :eol. :p.1.To connect OS/2 to OS/2: :p.For a switched connection, no config.sys DEVICE parameters are necessary. Select half speed in the SDLC adapter config if using 2400 bps modems. Otherwise, full speed implies 9600 bps. Although, if you want autodial enabled, you must have the "/D" config.sys parameter. :p.For an unswitched connection, if no config.sys parameters are used, the default is to bypass the transparency negotiations. If you want to enable transparency negotiations, you must specify the "/N" parameter, and you must make one partner a caller and the other a called party!!!!! :p.The OS/2 3270 emulator can be configured with the ADLC data link. You can configure an office based machine which has, for example, an upstream T/R connection to a host as a SNA gateway with downstream ADLC connections to remote 3270 sessions. The trick to this configuration is each ADLC data link configuration must be configured for a max RU size to be the same as the max RU size used in the upstream T/R connection to the host. :p.2.Connecting NS/DOS to OS/2: :p.NS/DOS supports only a secondary SDLC link station only. Therefore, make sure to configure the OS/2 ADLC link as either negotiable or primary role. :p.NS/DOS requires a partner to participate in transparency negotiations. Therefore on a switched data link, do not disable transparency negotiations. Since the OS/2 prototype learns dynamically what transparency negotiations role it must be, you don't have to specify the role. However, if using an unswitched connection, you must specify the OS/2 station to be the called party (e.g., /N=2). NS/DOS is always going to be a caller role. Note that this also implies OS/2 can not initiate the connection. It must be NS/DOS which initiates a connection, this is true for both switched and unswitched connections. :p.THEREFORE, you must not enable autodial on the OS/2 side!!!!! :p.The following is a sample NS/DOS CONFIG.NSD for SDLC over Async connection to OS/2. :xmp. NSDC ASYN NSDN USIBMZP1.JOE SDLD RALAS101,01 SDLF HALF ASBR 2400 //IF THE PCs ARE DIRECTLY CONNECTED .. //SDLT NONSWTPP //IF MODEMS ARE USED .. SDLT SWTPP SWAD ATDT 9-123-4567 :exmp. :p.3.Connecting OS/2 to AS/400: :p.The AS/400 implementation requires OS/2 to be configured as a secondary link station. :p.If you are using NS/2, the OS/2 SNA node must be configured as an end node (EN) and NOT a network node (NN). :p.The AS/400 requires all partners to participate in transparency negotiations. Using a switched link, a "/N" parameter is not necessary since the OS/2 prototype will default to using transparency negotiations over a switched link. For an unswitched connection, you must configure the OS/2 SNA-A data link to be enable transparency negotiations and to be a caller role (e.g., "/N=1"). The AS/400 is always a called party. Note this implies the AS/400 can not initiate a connection- it must be the OS/2 side. :p.The AS/400 SNA-A support was originally done just to support PC/Support on DOS. It does work with our OS/2 SNA-A implementation. To configure the AS/400 side, you can make use of some configuration tools which were really for PCS, but we can use them as well. PCS simply provides a user friendly front end to create several "descriptions" required by the AS/400 APPC implementation. :p.The following shows how to configure the AS/400 using the PCS config tools. We show each config screen. You can accomplish the same without PCS by manually creating the descriptions. :xmp. AS/4OO Side ----------- Add a PC support user - On the AS/4OO Main Menu, select option 11, PC Support tasks. - Select option 21, Enroll PC Support users. - You will need to fill out the User profile and User ID fields. Both of these fields should be to match the partner's network name. - The Address field should automatically default to the name by which the AS/4OO is known on the network. - Press Enter and you should return to the PC Support Task menu. ---------------------------------------------------- Enroll PC Support Users Type choices, press Enter. User profile . . . . . . JOE User identifier: User ID . . . . . . . JOE Address . . . . . . . RALAS1O1 User description . . . . Joe Smiths access to system. F3=Exit F12=Cancel --------------------------------------------------------- Configure PC support connections. - From the PC Support Task menu, select option 22, Configure PC Connections. - Select option 5 for Asynchronous communications. - On the Add PC to ASYNC connection screen you will need to supply the following information. Device Description - This is the network name of the partner SNA-A node. Port number - This is the port on the AS/4OO work station controller that the line from the PC is physically connected to. This must match. Attachment type - This is the type of attachment you will be using. This can be either direct or through a modem. Attached controller- Specifies the name of the controller to which the device is connnected. The first available controller name is the default. PF4 will display a list of ASCII workstations controllers on your system. SNA-A can only communicate through an AS/4OO ASCII workstation controller. -------------------------------------------------------- :exmp. :xmp. Add PC to ASYNC Connection Type choices, press Enter. Device description . . .JOE Name Port number . . . . . .1 O-17 Attachment type . . . .*MODEM *MODEM, *DIRECT, *PTT Attached controller . .CTLO2 Name, F4 for list F3=Exit F4=Prompt F12=Cancel --------------------------------------------------- To configure or add a SNA-A connection attached to an ASCII work station controller on your AS/4OO system, you must create a configuration description for the partner on the AS/400. To create a configuration description, go to the Work with Device Device Descriptions display. 1) On any display with a cmd line, type WRKDEVD *LCLDSP. 2) On the Work with Device Descriptions display, press PF6 (CREATE). You will need to supply the following information. :exmp. :xmp. Device description- Specifies the user defined name of the device description. Device class - Specifies the device class for the PC. Enter *LCL for this field. Device type - Specifies the type of device which the description represents. Enter 515O for this field. Device model - Specifies the model number of the device for this description. Enter A1 for this field. Port number - Must match the physical port to which the modem or line is attached on the AS/4OO. Read the "Determining the ASCII port address" section which follows to determine an available port number. Physical attachment - Used to describe whether the partner is directly attached to the AS/4OO or through a modem. Online at IPL - Specifies if device should be automatically varied online at IPL. Use the default of *YES. Attached controller - The attached ASCII Controller name. Read the "Determining the ASCII port address" section which follows to determine the correct attached controller. Keyboard language type- Specifies the country keyboard laguage identifier for the attached PC. Enter the default of *SYSVAL. Inactivity timer - Specifies a inactivity timeout value for the attached PC. Change this value to *NOMAX and press Enter. Line speed - Specifies baud rate of communications. change this value to *CALC. Word length - Change this value to *CALC. Type of parity - Change this value to *CALC. Stop bits - Change this value to 1. Maximum outstanding frames - Accept the default of 7 Idle timer - Accept the default of 4O. ------------------------------------------------ :exmp. :xmp. Create Device Desc (Display) (CRTDEVDSP) Type choices, press Enter. Device description . . ASYNCPC Name Device class . . . . . *LCL *LCL, *RMT, *VRT Device type . . . . . 515O 31O1, 3151, 3161, 3162. Device model . . . . . A1 O, 1, 2, 4, 11, 12, 23. Port number . . . . . 1 O-17 Switch setting . . . . ______ O, 1, 2, 3, 4, 5, 6 Physical attachment . . *MODEM *DIRECT, *PTT, *MODEM. Online at IPL . . . . . *YES *YES, *NO Attached controller . . CTL02 Name Keyboard language type . *SYSVAL *SYSVAL, AGB, AGI, BLI Inactivity timer . . . . *NOMAX 1-3O, *ATTACH, *NOMAX. Line speed . . . . . . . *CALC *TYPE, *CALC, 15O, 3OO. Word length . . . . . . *CALC *TYPE, *CALC, 7, 8 Type of parity . . . . . *CALC *TYPE, *CALC, *EVEN,*ODD. Stop bits . . . . . . . 1 *TYPE, 1, 2 Maximum outstanding frames . 7 1-7 Stop bits . . . . . . . 4O 1O-5O (O.1 seconds) More... F3=Exit F4=Prompt F5=Refresh F12=Cancel F13=How to use this display F24=More keys -------------------------------------------------- :exmp. :p.DETERMINING THE ASCII PORT ADDRESS FOR ASYNCHRONOUS CONNECTION :p.The following steps show you how to determine which addresses are available on a particular port on a particular ASCII work station controller card on the AS/4OO. :li.Determine which controller is associated with the particular ASCII controller card on the AS/4OO. Using the Work with Controller Description (WRKCTLD) command, you can view a list of all the controllers on your system. Controllers of the following types are associated with a ASCII card: 2637, 6O41, 6141. :li.Once you have found the controller name you must determine the available addresses for each port on the twinaxial card. This can be done by entering the Print Device Address command (PRTDEVADR) and specifying the controller name determined in step 1. This program creates a spool file which can be viewed by issuing the Work with Spool Files (WRKSPLF) command. The file should have a filename of QPDCDEVA. :eol. :h2.Appendix C: Modem configurations :p.Modem configuration will most likely be the leading cause of problems in getting a SNA-A data link up. Modem configuration can be quite complicated. There are entire books written on the subject. The following are some suggestions and some potential pitfalls: :li.use a default Hayes AT base profile :li.the modem must assert DSR at connect time- it can not be asserted all the time. You can use the AT command AT &S1 to do this. :p.NOTE: for L40 internal modem users, you must do this. The L40 user's manual does not document support for the &S AT command- however the modem does support it! The default for the modem is &S0- this will cause a data link failure! You change this in one of 2 ways. First, using some type of communications program and issue the AT command &S1 AND then issue a &W0 to save this in profile 0 to save this change. Or you can add the command &S1 to the modem initialization string. Let's say you wanted to autodial 123-4567 and you want to issue the &S command. The config.sys DEVICE line would be: DEVICE=C:\CMLIB\ASYNC\ADLCDD.SYS /D0= "AT &S1 DT 123-4567" :li.AT S register 0 must be nonzero if you want auto answer So, you can add the following to the /D string: "AT S0=1" :li.Currently (4/29/92), MNP protocols, V.42 protocol and any compression (MNP 5, V.42bis) must be disabled in the modem until we support modem to DTE flow control. :eol. :p.Another aspect of modems which needs clarification deals with the various terms floating around for serial line (either asynchronous or synchronous) speeds. There are 3 aspects associated with a line speed: baud rate, bits per second and throughput. Each of these can be used to describe different perspectives of line speeds. :p.The baud rate describes the rate of signalling changes which occur across the wire. The baud depends entirely on the modulation technique being used. There is not a one-to-one corresponence between a modulation signal change and an information bit (ie. a data bit). For example, the CCITT standard for 2400 bps modem modulation (V.22bis) uses a 600 baud modulation technique (Quadrature Amplitude Modulation, or QAM) which encodes 4 bits of information in a signal change. For our purposes, the baud rate is entirely a function of the modem and we need not concern ourselves with it. :p.The second aspect of line speed is the bit rate or the bits per second (bps). I also refer to the bps as the data rate. A modem (and a modulation technique) is typically described by the bps it supports. Bps also describes the physical line speed the COM port is normally programmed with. For example, if we are using a V.22bis modem, even though the baud rate is 600, since 4 bits of information are being sent for each signalling change, the actual bps is 2400. The COM port would be programmed for 2400 bps to match the modem speed. :p.The actual line speed, however, might be quite different from the data rate. For example, if the COM port has been setup for a data rate of 2400 bps using a V.22bis modem, the modems might temporarily lose synchronization (e.g., lose carrier). Typically the modem would assert some sort of flow control back to its controlling COM port (the DTE) telling it to stop sending data for a while until the modems have regained synchronization. If this happens, the actual data throughput will be less than the data rate available across the line. So the throughput is the actual amount of data sent and received across the wire. :p.There may be cases when the throughput across the wire is actually greater than the allowable data rate support. This can happen if modem to modem compression is being used. For example, if a V.22bis modem supports compression (such as V.42bis), it is possible that the effective modem to modem throughput (across the 2400 bps wire) can be up to 9600 bps. The actual throughput would vary from 2400 to 9600 bps depending on the contents of the data. :p.In order for the async data link to take advantage of this, the COM port must be programmed to use the maximum possible throughput available across the wire. In our example, this would be 9600 bps. Since the modem will most likely not be able to achieve a constant throughput of 9600, flow control must be enabled between the modem and the COM port so that when the throughput drops down to less than 9600, the modem can tell the COM port to stop sending data (since it would be sending at a higher speed) until the modem has caught up. :p.Modem to COM port flow control is required in order to use modem to modem compression and also to use modem to modem error correcting protocols. The OS/2 prototype will support CTS modem handshaking flow control (whenever the modem wants to pace the COM port, it negates CTS). :p.Modem to COM port flow control can also be used to bypass the prototype's lack of autobaud detect. For example, if the modems being used supported baud rate negotiations (such as IBM's 7855 modem), the COM port driving such a modem would be set to support its maximum throughput. When a partner dials into this modem, it might be using any data rate (1200 through 9600). The modems would negotiate what modulation technique to be used, any error correcting protocols to be used and/or if compression will be used. As long as the COM port was setup for the maximum throughput, it will be able to support any type of modem. This technique simply allows the COM port to take advantage of a modem's line rate negotiations capabilities. :euserdoc.