OS/2 Shareware BBS: 14 Text/14-Text.zip/remote.zip/REMOTE.TXT

Text File | 1994-02-09 | 152KB | 3,592 lines

..... REMOTE ANSWERS modified at 18:13:55 on 93/09/14 GMT (by RAGAN at AUSVM1)
:ndx.         :abs.

----- REMOTE ANSWERS appended at 00:29:15 on 93/06/15 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 17:26:29 on 93/06/16 GMT (by RAGAN at AUSVM1)
:ndx.MODEM001 :abs.COMMON PROBLEM #1: "Modem failed to initilize" error
:key.RLA TBIRD modem
:QUESTION.
  What do I do if I get the error message:
  "Modem failed to Initilize."?
:ANSWER.

  ****************************************************************
  Common problem #1:
  ***************************************************************
  SYMPTOM:
  Error message upon starting RLA:
  --------------------------------------------
                 INFORMATION
       Modem could not be initialized.
            Port Manager:    xxxxxx
            Port:            COM1
            Local Number:    xxx-xxxx
  --------------------------------------------

  When you try to dial from the phonebook you get the message:
  -----------------------------------------------
       No ports are available for the call to...
  -----------------------------------------------

  SOLUTIONS:
  1) A common problem occurs when an unsupported modem is used.
  Step #6 details how to configure for an unsupported modem.  This
  is a technically difficulty step, so you may want to confirm
  Steps #2 through #5 are completed correctly before attempting
  Step #6.
  2) You may have a bad modem cable, switch it out with another
  modem cable, or test your COMport/cable/modem connection with an
  async emulation package to confirm this connection is working.
  3) You may have failed to configure a modem and a COM port
  correctly.  To re-configure the COM port and Modem correctly,
  please follow these steps:
       Start RLA (double click on the RLA icon).
       Wait 45 seconds for RLA to start.
       Open the workstation icon as Settings.
       Wait 60 seconds for the Settings notebook to open.
       Select on the Ports tab.
       Delete any ports you may have put in.
       Select the Modems tab.
       Delete any modems you may have put in.
       Select the Ports tab.
       Select the Add pushbutton.
       Select OK, accepting the Async Comm Adapters
       Select the COM port you need, e.g., COM1
       Double click on the System Menu in the upper left-hand
         corner to close the <com1> - notebook.
       Select the Modems tab.
       Select the Add pushbutton.
       Select your modem from the list box entitled: Available
         modem types.
       If your modem is not listed, see STEP #6 below.
       Select OK
       Select Add from the <modem> - Settings notebook.
       Type in a telephone number in the "Phone number" entry field
       Select OK
       Select from the ports configured, e.g., COM1
       Select OK
       Double click in the upper left-hand corner to close the
         <xxx modem> - notebook with only the Ports chapter.
       Double click in the upper left-hand corner to close the main
         Settings notebook.
       Stop all applications that are running, Shutdown your
         workstation, press Ctrl+Alt+Del to re-start your
         workstation.

  4) You may have a workstation that is non-FIFO, supporting only
    COM port speeds under 9.6Kbps.  To see if your workstation is
    non-FIFO, type at the OS/2 command line:
            MODE COM1
  4a) If the system response is:
            BUFFER = AUTO  (or anything other than N/A)
    then you have a FIFO machine.  You have a FIFO workstation
    supporting faster speeds, move to step #5.
  4b)   If the system response is:
            BUFFER = N/A
    then you have a non-FIFO machine (that will only support modem
    speeds of 9.6 or lower).  Complete the following steps for your
    non-FIFO machines.
         WARNING: Complete the sequence below, ONLY if you have a
                  good understanding of editing System
                  configuration files.
    Stop RLA, close all RLA windows.
    Using your favorite ASCII editor, edit the WCLNET.INI file in
    the \WAL subdirectory.  For the parameter labeled:
       SerialPortSpeed =
    change the number to
       9600
    so the entire line will now read
       SerialPortSpeed = 9600
    Save the file, then  re-start RLA.
  5) You may have a modem that is configured (via the modem
  switches) to run at a lower speed.  Edit the WCLNET.INI file as
  described in STEP #4b.
  6) Configuration of non-supported modems.  If you have a modem
  that is not contained in the RLA Settings, Modem, "Available
  modem types", then you will need to either:
       > locate a modem that is supported  <<< an easy solution
       > proceed with the following hand editing of RLA
           configuration files based upon information you research
           in the modem's user manuals  <<<< not an easy solution.

       *** WARNING: do not attempt to carry out the following steps
                    unless you have advanced knowledge of
                    communications, OS/2 configuration files, and
                    modems.

  Here are the steps to add a non-supported modem:
  6.1)  Close all RLA windows.
        At an OS/2 command prompt, type
            C:
            CD WAL
            COPY ASYNCSW.PIF MYMODEM.PIF
            EPM MYMODEM.PIF

       Locate and modify the following parameters in this file:

       the very first line:
            ìMYMODEM┘

            PIF = MYMODEM.PIF

            Title = "My newly configured modem"

       scroll down the file until you find:

            ìAutoBaudDetect┘
            Default =

            ìSerialPortSpeed┘
            Default =

            ìInitialization1┘
            Default =

            ìInitialization2┘
            Default =

  These parameters vary from modem to modem with a specific brand
  of modem, and vary considerably between brands of modems.  Only
  the modem manual can give you the values that fit each of these
  parameters.  You can contact the modem company for further
  information on these values.

  Once the new file has been created and edited, you will now need
  to enter the RLA user interface Settings to use this file to
  configure your RLA workstation correctly.

  6.2) Save the MYMODEM.PIF file
       Shutdown and re-start your workstation.
       Start RLA (double click on the RLA icon).
       Wait 45 seconds for RLA to start.
       Open the workstation icon as Settings.
       Wait 60 seconds for the Settings notebook to open.
       Select the Ports tab.
       Delete any ports you may have put in.
       Select the Modems tab.
       Delete any modems you may have put in.
       Select the Ports tab.
       Select the Add pushbutton.
       Select OK, accepting the Async Comm Adapters
       Select the COM port you need, e.g., COM1
       Double click on the System Menu in the upper left-hand
         corner to close the <COM1> - notebook.
       Select the Modems tab.
       Select the Add pushbutton.
       Select your new modem from the list box entitled: Available
         modem types, you new modem should be entitled: MYMODEM.
       If your modem is not listed you have not done STEP 6.1
         correctly, repeat STEP 6.1.
       Select OK
       Select Add from the <modem> - Settings notebook.
       Type in a telephone number in the "Phone number" entry field
        (don't forget to add numbers such a 9 to dial out, etc.)
       Select OK
       Select a port from the ports configured list, e.g., COM1
       Select OK
       Double click in the upper left-hand corner to close the
         <my modem> - notebook, with the single Ports chapter.
       Double click in the upper left-hand corner to close the main
         Settings notebook.
       Stop all applications that are running, Shutdown your
         workstation, press Ctrl+Alt+Del to re-start your
         workstation.
  If you continue to have the same symptom as stated at the top of
  this note, please respond back to us with a further request for
  assistance.
:from.Rick Ragan, IBM Austin, TX

----- REMOTE ANSWERS appended at 16:56:53 on 93/06/15 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 21:18:10 on 93/06/15 GMT (by RAGAN at AUSVM1)
:ndx.INFO_001 :abs.COMMON PROBLEM #2: Domain Controller not Available, part 1/2
:key.RLA TBIRD Doamin Controller Bridge LAPS
:QUESTION.
  What do I do if I get the error messages: Domain Controller not Available,
  or The Server is not responding?
:ANSWER.

  Part 1 of 2 for Common Problem #2.

  ****************************************************************
  Common problem #2: Cannot logon to the Server
  ***************************************************************

  SYMPTOMS:
  RLA starts correctly, without error messages.
  RLA dials correctly, establishing a connection:
       > No dial error messages.
       > Modem lights flash at both workstations.

  However, you cannot get IBM LAN Requester at the RLA remote
  workstation to logon to the IBM LAN Server at the RLA Server
  workstation.  You may often get the messages:

            -------------------------------------
             Domain Controller not Available.
            -------------------------------------
                        or
            -------------------------------------
             The Server is not responding.
            -------------------------------------

  SOLUTIONS
       A--Bridge is not configured at the server.
       B--Timeout value is too small
       C--Pre-existing bug in BRIDGFH.OS2 device driver.
       D--IBM LAN Server/Requester 2.0 incompatibility

  Below are two step-by-step solutions for RLA configuration from
  Binh Tran - "Mr. Configuration."

  SOLUTION A -- BRIDGE IS NOT CONFIGURED AT THE SERVER.

  This problem may indicate the RLA Server has not been configured
  correctly.
  Philosophy:
       Sometimes users will assume that since the RLA Remote
       Workstation installation process installs code AND
       configures the communications parameters, that the RLA
       Server Workstation installation process also configures the
       RLA Server.  RLA Server configuration is not automatic and
       must be accomplished via the RLA Settings notebook as
       explained below.

  CONFIGURATION FOR A RLA SERVER
  1) Install the RLA Server code.
  2) Stop all programs, shutdown your workstation, and reboot your
       workstation (Ctrl+Alt+Del).
  3) At an OS/2 command prompt, change to the \IBMCOM subdirectory
       and run LAPS, type:
            LAPS
     The LAN Adapter and Protocol Support configuration window will
       appear.
     Select the "Configure" pushbutton on the IBM LAPS Logo window.
     Select the "Configure LAN Transports" item, then select the
       "Continue..." pushbutton on the Configuration message
        window.
  4) You should now be at the main LAPS configuration window
       entitled: "Configure Workstation"
     Configure LAN Transports as follows:
     In the List box entitled "Current Configuration" select the
       "IBM OS/2 NETBIOS" entry for the "IBM Token-Ring Network
       Adapter", then select the "Change Number" pushbutton and
       select 0 on the "Change Logical Adapter Number" window.
       Select the "Change" pushbutton.
     Repeat this process for the "IBM OS/2 NETBIOS" entry for the
       "remote LAN access Logical Adapter", making this adapter
       number 1.
     You should now have a "Current Configuration" list box with
       the following information in it:
      +--------------------------------------------+
      |  IBM Token-Ring Network Adapter.......     |
      |     0 - IBM OS/2 NETBIOS                   |
      |  remote LAN access Logical Adapter.......  |
      |     1 - IBM OS/2 NETBIOS                   |
      +--------------------------------------------+

  5) Placement of Protocols.
     Philosophy:
       The remote workstation's application protocols should be
       located at the RLA remote workstation, not at the RLA
       Server. Only applications that will be run from the RLA
       Server should have protocols configured to exist at the
       Server.

     For example, if you plan to run 3270 emulation via
     Communications Manager, you do not place the 802.2
     protocol at the RLA Server.  Only the RLA remote workstation
     needs this protocol.  If you place an unnecessary protocol at
     the RLA Server, there is a bug in the RLA first beta code that
     may cause a Trap D at component PDFH$.  This bug will be fixed
     in the second beta.
  5.1) Delete all unnecessary protocols from the RLA Server.  Do
       not place any protocols here in an effort "to match" the RLA
       remote workstation with this RLA Server.
  6) After you have changed the Adapter Numbers and deleted any
       unnecessary protocols, select the OK pushbutton located in
       the lower right-hand corner of the "Configure Workstation"
       window.
     Select the Exit pushbutton on the IBM LAPS Logo window.
     Select the Continue... pushbutton on the CONFIG.SYS Update
       message window.
     Select OK to CONFIG.SYS Updated message window.
     Select the Exit pushbutton at the Exiting LAPS message.
    This configuration will allow you to bridge from the RLA Wide
    Area LAN to the Token-Ring LAN.  In other words, once RLA makes
    a connection between the RLA Remote and the RLA Server, the RLA
    Server then must bridge the Remote's frames onto the physical
    LAN via the TR adapter.  By making the TR adapter 0 and the RLA
    adapter 1, you instruct the RLA Server to bridge from the WAN
    to the LAN.
  7) Double click on the RLA icon to start RLA Server.
  8) Open as > Settings
  9) Click on the Answer Chapter
  10) Select PSTN_ALL_CALLS in the List Box.
        (PSTN is async and sync.  ISDN is digital telephone lines).
  11) Select the Change pushbutton.
  12) If you want to have the RLA Server put itself into Answer
        Mode when RLA starts up, check the "Enable answer mode on
        startup" checkbox.
      If you choose not to enable answer mode on startup, then you
      will need to select the Start Mode pushbutton within the
      Answer chapter in order to place the RLA Server in Answer
      mode.  This pushbutton's effect lasts until you select the
      Stop Mode pushbutton, or until you stop RLA.
  13) Double click on the System Menu in the upper left-hand corner
        of the Answer Criteria notebook to close and save these
        changes.
  14) Configure the Ports and modems via the following steps:
       Select on the Ports tab.
       Delete any ports you may have put in.
       Select the Modems tab.
       Delete any modems you may have put in.
       Select the Ports tab.
       Select the Add pushbutton.
       Select OK, accepting the Async Comm Adapters
       Select the COM port you need, e.g., COM1
       Double click on the System Menu in the upper left-hand
         corner to close the <com1> - notebook.
       Select the Modems tab.
       Select the Add pushbutton.
       Select your modem from the list box entitled: Available
         modem types.
       If your modem is not listed,
          see Common Problems #1, Step #6.
       Select OK
       Select Add from the <modem> - Settings notebook.
       Type in a telephone number in the "Phone number" entry field
       Select OK
       Select from the ports configured, e.g., COM1
       Select OK
       Double click in the upper left-hand corner to close the
         <xxx modem> - notebook with only the Ports chapter.
  15) Click on the Bridge chapter.
  16) Click once on the right-hand pointing arrow at the bottom
        right-hand corner of the notebook to move to Page 2.
  17) Type the LAN segment ring number.  While the default is 1, if
        you plan to run 3270 terminal emulation, this number must
        represent the LAN segment ring number to which the RLA
        Server is attached.
  18) Click on the Workstation chapter.
  19) You can type any name for the RLA Server (optional), type
        the desired name in the "Local RLA workstation name" entry
        field.
  20) Double click on the System Menu in the upper left-hand corner
        of the main RLA Settings notebook to close and save these
        changes.
  21) Double click on the System Menu in the upper left-hand corner
        of the RLA Workstations window to stop RLA.
  22) Stop all applications, shutdown your workstation,
        Ctrl+Alt+Del your workstation.

  continued on Part 2 of 2...
:from.Rick Ragan, IBM Austin, TX.

----- REMOTE ANSWERS appended at 16:59:13 on 93/06/15 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 21:18:48 on 93/06/15 GMT (by RAGAN at AUSVM1)
:ndx.INFO_002 :abs.COMMON PROBLEM #2: Domain Controller not Available, part 2/2
:key.RLA TBIRD Doamin Controller Bridge LAPS
:QUESTION.
  What do I do if I get the error messages: Domain Controller not Available,
  or The Server is not responding?
:ANSWER.

  Part 2 of 2 for Common Problem #2.

  SOLUTION B) -- TIMEOUT VALUE IS TOO SMALL

  Philosophy:
       A 4Mbps LAN send LAN frames around the LAN wire at very fast
       speeds.  Once you introduce IBM RLA into the LAN as a
       virtual TR node, the LAN must slow down to accommodate this
       remote client operating at 14.4Kbps speeds (this slow WAN
       speed is 0.00036% of the faster LAN speed)

  IBM LAN Requester/Server assumes the LAN applications will run at
  4Mbps speeds. The Netbios timers (TI, T1, and T2) of the LAN
  workstations are defaulted for the 4Mbps LAN speed.  IBM remote
  LAN access modifies these values for 19.2Kbps in order to
  introduce the slower remote client.  You may have to further
  modify these values for even slower telephone line speeds.

  1) Increase the T timers in the PROTOCOL.INI file, see below.
  2) Make sure the 15 bit in the SRVHEURISTICS parameter in the
       IBMLAN.INI file is a 1, it should not be a 0.  The first bit
       for this Netbios timeout value is 0, so you count from 0th
       bit to 15th bit.

  These values should be adjusted on the IBM RLA remote workstation
  and RLA server, and also ALL the LAN Workstations or Servers (LAN
  Server, LOTUS Notes server, etc) that will communicate with the
  RLA remote workstation.

  Here are the suggested settings for the PROTOCOL.INI file for
  modems extending as low as 9600Kbps:

         DEFAULT       IBM RLA
  TI =    30,000        60,000      Inactivity timer
  T1 =       500        10,000      Response timer
  T2 =       200         2,000      Acknowledgement timer

  PLEASE NOTE:
  Low speed modems are supported primarily for remote workstation
  to remote workstation, not for remote workstation to LAN.

  9.6 Kbps modems or higher are recommended for the Remote to LAN
  environment due the inherent nature of LAN Timers.  The lower the
  line speed, the higher the LAN Timer value needs to be set, which
  may lead to LAN performance problems.

  Some modems will start at a high line speed and negotiate down to
  lower line speeds until the line errors are corrected.  You could
  have a 14.4Kbps modem that has an effective line speed well
  below 9600Kbps.

  SOLUTION C) -- PRE-EXISTING BUG IN BRIDGFH.OS2 DEVICE DRIVER.

  If you have configured the RLA server correctly and modified your
  timer values to match the speed of your modems, you may be
  experiencing a bug in the IBM RLA code.  The bug manifests itself
  with LANs having even number of hops.  You will receive the
  errors listed at the beginning of this note if your LAN
  destination workstation is an even number of hops (bridges) from
  your RLA Server.  For instance, if there are two bridges between
  your RLA Server and your Communications Manager SNA gateway, then
  the hop count is 2 and your will not access the SNA gateway, but
  will receive one of the error messages listed above.

  Please request the fix module BRIDGFH.OS2 on this forum with the
  following VM command:
       REQUEST BRIDGE FROM BETASRUS AT AUSVM1

  SOLUTION D) -- IBM LAN SERVER/REQUESTER 2.0

  There is a further bug in the RLA 1st Beta that prevents RLA from
  working with LAN Server/Requester 2.0.  If you use this
  application, you will receive the messages at the beginning of
  this note.  Please install IBM LAN Server/Requester 3.0 or
  higher.

  You are now ready to start the RLA Server and receive calls from
  the RLA Remote Workstation.  Please remember this first Beta for
  RLA does not contain security, so your RLA Server may be
  vulnerable to others dialing into your server.

  <end of file>
:from.Rick Ragan, IBM Austin, TX.

----- REMOTE ANSWERS appended at 17:06:01 on 93/06/15 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 13:58:43 on 93/07/13 GMT (by RAGAN at AUSVM1)
:ndx.INFO_003 :abs.COMMON PROBLEM #3: LAPS on the Remote Workstation.
:key.TBIRD RLA LAPS remote workstation
:QUESTION.
  What do I do if I get the following error messages: " An error occurred
  while opening network device driver NET1=NETBEUI$" or "The REQUESTER
  service could not be started"?
:ANSWER.

  ***************************************************************
  Common problem #3: LAPS configuration
  ***************************************************************

  SYMPTOMS:

  RLA starts correctly, without error messages.

  RLA dials correctly, establishing a connection:
       > No dial error messages.
       > Modem lights flash at both workstations.

  However, you cannot get
      > IBM LAN Requester or
      > 3270 Communications Manager
  to work.

  Error messages:

  IBM LAN Requester places info into CONFIG.SYS that will fail
  at boot time with the following words:
  ----------------------------------------------------------------
  Net3406 :An error occurred while opening network device driver
           NET1 = NETBEUI$
  SYS1719: The file "C:\IBMLAN\NETWKSTA.200" specified in the
           IFS command on line (94) of the CONFIG.SYS file does not
           contain a valid device driver or file system driver.
  ----------------------------------------------------------------

                          or

  When the IBM LAN Requester starts up:
  ---------------------------------------------------------------
  The REQUESTER service could not be started.
  NET3060: The service did not respond to a control signal and
           was stopped with the DosKillProc function.
  ---------------------------------------------------------------

                              or

  If you are trying to run 3270 emulation (Communication Mgr):
  ---------------------------------------------------------------
  ACS 2390  ALERT: An unexpected OS/2 function call or
            802.2 LAN Transport error has closed the logical
            LAN adapter.
  (This is a full screen message, white letters, black background)
  ----------------------------------------------------------------

  Below are two step-by-step solutions for RLA configuration from
  Binh Tran - "Mr. Trouble Shooter."

  PROBLEM -- LAPS is not configured correctly.

  The problem is that when you configured for LAPS, you deleted the
  Token Ring adapters at 0 (zero) and added protocols to the RLA
  logical adapter as 1 (one).

  Philosophy:
       The applications should be configured to run on the remote
       machine just as if they were running at any LAN workstation.
       Thus, the protocols (NETBIOS, 802.2, etc) must be located at
       the RLA remote workstation, not at the RLA Server.  Secondly
       the RLA remote workstation expects to use the RLA logical
       adapter 0.

  SOLUTION:

  LAPS CONFIGURATION FOR A RLA REMOTE WORKSTATION

  1) At an OS/2 command prompt, change to the \IBMCOM subdirectory
     and run LAPS, type:
            LAPS
     The LAN Adapter and Protocol Support configuration window will
       appear.
     Select the "Configure" pushbutton on the IBM LAPS Logo window.
     Select the "Configure LAN Transports" item, then select the
       "Continue..." pushbutton on the Configuration message
        window.

  2) You should now be at the main LAPS configuration window
       entitled: "Configure Workstation"

     Configure LAN Transports as follows:

     In the List box entitled "Current Configuration" select the
            1 - IBM OS/2 NETBIOS
     protocol and select the Remove pushbutton, select the Yes
     pushbutton to remove this protocol.  Repeat the same steps
     for the
            remote lan access Logical Adapter...

     In the List box entitled "Current Configuration" select the
            IBM Token-Ring Network adapters
     In the list box entitled "Network Adapters" select the
            remote lan access Logical Adapter...
     Select the Change pushbutton under the list box entitled
     "Network Adapters" in order to make the "IBM Token-Ring
     Network adapters" switch to "remote lan access Logical
     adapter."

     You should now have a "Current Configuration" list box with
       the following information in it:

      +--------------------------------------------+
      |  remote LAN access Logical Adapter.......  |
      |     0 - IBM OS/2 NETBIOS                   |
      |     0 - etc                                |
      |     0 - etc                                |
      +--------------------------------------------+

     The applications that will run on your remote workstation will
     now run on adapter 0 instead of adapter 1.

  3) Let's make sure that your protocols under the RLA logical
     adapter are clean.
     In the list box entitled "Current Configuration" select the
             0 - IBM OS/2 NETBIOS
     protocol.  Select the Edit pushbutton.  You now see the
     "Parameters for IBM OS/2 NETBIOS" dialog box.  Delete all
     information from the "Network adapter address" entry field.

     Repeat Step #3 for each of the protocols under the remote LAN
     access Logical Adapter.

     Do not delete the critical network adapter address for the
     remote lan access Logical Adapter.  This adapter must have a
     destination address.

  4) OK pushbutton located in the lower right-hand corner of the
       "Configure Workstation" window.
     Select the Exit pushbutton on the IBM LAPS Logo window.
     Select the Continue... pushbutton on the CONFIG.SYS Update
       message window.
     Select OK to CONFIG.SYS Updated message window.
     Select the Exit pushbutton at the Exiting LAPS message.

  <end of file>
:from.Rick Ragan, IBM Austin, TX

----- REMOTE ANSWERS appended at 17:08:28 on 93/06/15 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 16:37:02 on 93/11/30 GMT (by RAGAN at AUSVM1)
:ndx.INFO_004 :abs.COMMON PROBLEM #4: Leased Line or Null Modem problems
:key.RLA TBIRD Null Modem, Leased line
:QUESTION.
  What do I do if I have problems with Leased line or null modem configuration?
:ANSWER.

  ***************************************************************
  Common problem #4: Null modem (cable) configuration
  ***************************************************************

  |  11/30/93 - All of the configuration information below has
                been revised.

  PROBLEM:
       Cannot get Null modem configured.

  PHILOSOPHY:
       A null modem is a type of cable connecting two workstations
       in close proximity without using modems. The LAN Distance
       product allows for a null modem connection.

       This solution can be used to test your LAN Distance
       installation and configuration.  If you are trying to use
       modems not listed in the Available modem types list box, you
       can confirm, by using a Null modem connection, that the
       problems you may be experiencing are do to the mis-match
       between your modem hardware and the Modem type you have
       selected.  There are steps in the LAN Distance documentation
       to use modems not listed with the LAN Distance product.

       For null modem configurations you must set the values:
            Ports ---------------- Switched
            Modems ----------- Non-switched
            Phonebook -------- Non-switched
            Answer criteria -- Non-switched

  SOLUTION:  Null modems steps and wiring:

  For the LAN Distance Connection Server:

    Open as Settings
       Select the Ports tab, a Ports - Settings notebook will
            appear.
       Delete all ports.
       Select the Add Pushbutton and select a port with a
            "switched" (this is not a typo) Line Type.  Close this
            notebook.
       Select Modems tab
       Delete all modem types
       Select the Assign push button
       Select "Null Modem" in Available modem types list box.  On
            the Notebook that appears (xxxxx modem ---Settings).
            Select Add... to add a Port, the dialog box Null Modem
            - Settings will appear.  Non-switched is selected, for
            "Permanent connection name" type a name that matches on
            both the Connection Server *and* the Remote
            workstation.  Select OK. For the next Notebook that
            appears assign the COM port (if there are multiple COM
            ports make sure you choose the switched COM port).
            Select OK, close the Null Modem - Settings notebook.
       Select the Answer tab
       Select the Add push button.  On the next dialog box select
            Network Type of "PSTN" and Line Type of "Non-switched."
            Select OK.  On the Notebook that appears (Answer mode
            criteria -- Settings) for "Answer mode name" type in
            any unique descriptive name and select "Enable answer
            mode on startup", close this notebook.
       Close Settings
       Shut down and re-start your workstation.

  For the LAN Distance Remote workstation:

    Open as Settings
       Select the Ports tab, a Ports - Settings notebook will
            appear.
       Delete all ports
       Select the Add Pushbutton and select a port with a
            "switched" (this is not a typo) Line Type.  Close this
            notebook.
       Select Modems tab
       Delete all modem types
       Select the Assign push button
       Select "Null Modem" in Available modem types list box.  On
            the Notebook that appears (xxxxx modem ---Settings).
            Select Add... to add a Port, the dialog box Null Modem
            - Settings will appear.  Non-switched is selected, for
            "Permanent connection name" type a name that matches on
            both the Connection Server *and* the Remote
            workstation.  Select OK. For the next Notebook that
            appears assign the COM port (if there are multiple COM
            ports make sure you choose the switched COM port).
            Select OK, close the Null Modem - Settings notebook.
       Select the Phonebook tab
       Select the Add pushbutton
       Select PSTN for "Network type" and Non-Switched for "Line
            type".  On the Notebook that appears (Phonebook --
            Settings) type a unique and descriptive "Entry Name".
            On the Phonebook - Settings notebook, select the
            Connect tab.  The "Modem" entry field has Null Modem
            pre-filled, and the "Leased Line" entry field name is
            pre-filled.
       Close this notebook.
       Close Settings
       Shut down and re-start your workstation.

       Start both Remote and Connection Server workstations
       Start LAN Distance on both Remote and Connection Server
            workstations.
       Dial from the LAN Distance Remote workstation to the LAN
            Distance Connection Server workstation.

                     THE NULL MODEM CABLE WIRING

  NOTE: You can obtain this modem cable from Radio Shack stores.

  There are over four types of Null modem cables.  Make sure your
  null modem cable has the following wiring when you are using a
  null modem for the LAN Distance product.

  (FG)     1----------------------1   (FG) Pin 1 straight through

  (TD)     2----------------------3   (RD) Pin 2 and 3 are crossed
  (RD)     3----------------------2   (TD)

  (RTS)    4----------------------5   (CTS) Pin 4 & 5 are crossed
  (CTS)    5----------------------4   (RTS)

  (SG)     7----------------------7   (SG)  Pin 7 straight through

  (DSR) +--6                      6---+ (DSR) Pin 6 & 8 together to
        |                             |    Pin 20 of the other side
  (CD)  +--8----------------------20  | (DTR)
                                      |
  (DTR)  20-----------------------8---+ (CD)

:from.Rick Ragan, IBM Austin, TX

----- REMOTE ANSWERS appended at 17:11:01 on 93/06/15 GMT (by RAGAN at AUSVM1)
:ndx.INFO_005 :abs.COMMON PROBLEM #5: IBM LAN Server/Requester copy large files
:key.RLA TBIRD LAN Server, large files copy
:QUESTION.
  What do I do if I have problems with my IBM LAN Server/Requester system
  when I try to copy large files?
:ANSWER.

  ***************************************************************
  Common problem #5: Large File copy with IBM LAN Server
  ***************************************************************

  SYMPTOMS:

  RLA starts correctly, without error messages.

  RLA dials correctly, establishing a connection:

  IBM LAN Requester works correctly.

  When you try to copy files larger than 2 Kbytes, or XCOPY a lot
  of files, you may have one of the following problems.

  Error messages:

  ----------------------------------------------------------------
  REQUESTER
  NET3193: A virtual circuit error occurred on the session
  to STLCORE.  The NCB command and return code are the data.
     96  18
  ----------------------------------------------------------------

                         or

  ----------------------------------------------------------------
  REQUESTER
  NET3190: Netwksta Internal Error.
  NCB Done msg incomplete in redir NCB!
     06  00
  A virtual circuit error on the session to ***.
  The NCB command and return code are the data.
  ----------------------------------------------------------------

                         or

  ----------------------------------------------------------------
  The results of a large file copy simply does not complete,
  leaving the file partially copied, or XCOPY does not copy all
  files.
  ----------------------------------------------------------------

                         or

  ----------------------------------------------------------------
  Failed logon attempts.
  Domain not available.
  ----------------------------------------------------------------

  These solutions are from the technical minds of Steve Tipton and
  Binh Tran.

  PROBLEM

  The problem is that the blocks of data that the IBM LAN Server
  sends to the IBM LAN Requester over the WAN link are too large
  for the slow WAN link to handle.  The IBM LAN Timers and Block
  sizes must be modified.

  Philosophy:
       A 4Mbps LAN send LAN frames around the LAN wire at very fast
       speeds.  Once you introduce IBM RLA into the LAN as a
       virtual TR node, the LAN must slow down to accommodate this
       remote client operating at 14.4Kbps speeds (this slow WAN
       speed is 0.36% of the faster LAN speed)

  SOLUTION #A: -- TIMEOUT VALUE IS TOO SMALL FOR THE LAN

  WARNING: Please back up any file that you plan to modify.  If you
       make the changes to your files as described below, you will
       be modifying the performance of your LAN.  Do not attempt
       these procedures unless you have a good understanding of
       LANs, control files, and data communications.

  IBM LAN Requester/Server assumes the LAN applications will run at
  4Mbps speeds. The Netbios timers (TI, T1, and T2) of the LAN
  workstations are defaulted for the 4Mbps LAN speed.  IBM remote
  LAN access modifies these values for 19.2Kbps in order to
  introduce the slower remote client.  You may have to further
  modify these values for even slower telephone line speeds.

  Back up any files BEFORE you start to modifying them.

  1) THE IBM LAN SERVER'S IBMLAN.INI FILE:
       Make sure the 15 bit in the SRVHEURISTICS parameter in the
       IBM LAN Server's IBMLAN.INI file is a value from  1 to 9, it
       should not be a 0.  The first bit for this Netbios timeout
       value is 0, so you count from 0th bit to 15th bit.

       A useful way to adjust this bit is to first set the bit to
       9.  This sets the Netbios timer to infinite.  Once you have
       done this, retry the COPY or the XCOPY command.  If the LAN
       Server was timing out, the problem should disappear.  If you
       still cannot copy, remove the SMB RAW bits for the
       workstation (See SOLUTION B below).  After removing these
       values, you can decrease the timer value (the 15th bit)
       until you reach a timer value that maximizes the IBM LAN
       Server's performance while still allowing large files to be
       copied over the LAN. (NOTE: The Timeout is the same for
       values 2 to 8.)

  2) THE IBM LAN SERVER'S IBMLAN.INI FILE:
       If you are receiving the message regarding failed Logon
       attempts, you may also wish to change SRVHEURISTICS bit 15
       to a 9.

  3) THE IBM LAN REQUESTER'S IBMLAN.INI FILE:
       In the IBM LAN Requester's IBMLAN.INI file, increase the
       SESSTIMEOUT = value to a range of 45 to 200.  Increasing
       this value will help keep the transmits and receives from
       timing out due to slow WAN speeds.

  4) THE IBM LAN SERVER AND REQUESTER'S PROTOCOL.INI FILE:
       The values listed below may be increased above the IBM RLA
       values.  Here are the suggested settings for the
       PROTOCOL.INI file for modems extending as low as 9600Kbps:

                   DEFAULT       IBM RLA
            TI =    30,000        60,000      Inactivity timer
            T1 =       500        10,000      Response timer
            T2 =       200         2,000      Acknowledgement timer

       These values should be adjusted on the IBM RLA remote
       workstation and RLA server, and also ALL the LAN
       Workstations or Servers (LAN Server, LOTUS Notes server,
       etc) that will communicate with the RLA remote workstation.

  SOLUTION B) -- KNOWN BUG WITH IBM LAN REQUESTER:

  APAR IC04667 exists.  This is a time out problem when copying
  large files from the IBM LAN Requester.  NET3190 error typically
  occurs due to this error.

  A work-around is to adjust the IBM LAN Requester's SMB RAW
  WRKHEURISTICS values in the IBMLAN.INI file.  Make sure the 11th,
  12th, and 13th bits for the WRKHEURISTICS parameter in the IBM
  LAN Requester's IBMLAN.INI file are set to 0.  The first bit for
  this Netbios timeout value is 0, so you count from 0th bit to
  11th bit, etc.  Make this change only for the IBM LAN Requester,
  so only the remote operations are affected.  Locally LAN-attached
  workstations will have better performance if the IBM LAN Server's
  WRKHEURISTICS bits are left on.

  New NETWKSTA.200 and MFSD20.SYS files will soon be available for
  this APAR.  Call 1-800-237-5511 to request this fix.

  <end of file>


:from.Rick Ragan, IBM Austin, TX

----- REMOTE ANSWERS appended at 15:57:51 on 93/06/16 GMT (by RAGAN at AUSVM1)
:ndx.MODEM002 :abs.Constructing Modem Strings for unsupported RLA modems
:key.RLA TBIRD Modem strings
:QUESTION.
  If I have a modem that is not supported by RLA, how do I construct a
  modem string on my own?
:ANSWER.

  Subject: Modem String Construction Rules for non-RLA modems

    Addition of steps 2-8 below, 6/1/93.
    This is a complete listing thanks to our RLA async team.

  Please refer to Common Problem #1, Step 6.1 to modify the modem
  string (in order to create a .PIF file for your modem that RLA
  does not support currently).

  The modem initialization string should contain commands so that
  the modem controls the RS-232 signals in the following way.

  RLA Modem String Construction rules:
   1)  Do not attempt to construct modem strings unless you have
         a good understanding of modems and configuring communications
         software.

   2)  DTR - When DTR drops, the modem hangs up and goes to the
         command state.  The modem does NOT do a reset when DTR
         drops.  The modem should not answer the phone when DTR
         is low.  For almost all modems the correct command is &D2.

   3)  CD - CD tracks the carrier signal from the remote modem.
         For almost all modems the correct command is &C1.
         Note:  Some modem manuals refer to CD as DCD or RLSD.

   4)  DSR  - DSR follows standard RS-232 operation.  DSR must drop
         when a connection terminates.  For almost all modems
         the correct command is &S1.

   5)  RTS/CTS - Modem uses bidirectional hardware (RTS/CTS) flow
         control.  For some modems the correct command is \Q3,
         however the correct command for this behavior varies
         widely from modem to modem.  Note:  Some modem manuals
         refer to CTS as RFS.

   6)  The speed between the modem and the computer is fixed.  The
         connect speed over the phone line may change per connection,
         but the speed between the computer and the modem never changes.

   7)  The modem buffers data between the computer and the phone line.

   8)  The modem answers an incoming call on the second ring.  The
         correct command for this is S0=2.

   9)  Never assume factory defaults are correct.

   10) If Initialization 2 is too long move part of the sting to
         Initialization 1.

   11) Character echo enable

   12) Full duplex

   13) Speaker on until carrier detected

   14) Result codes displayed as words (verbal mode)

   15) Modem negotiates highest possible link rates with remote mode.

  In the "You too can contribute to RLA" department, we would like for
  those of you out there who have successfully created .PIF files for
  your non-RLA supported modems to send these PIF files to me, we will make
  them available to the RLA Beta community, and if they are confirmed by
  others to work, then the modem string you construct will go into
  the RLA final product!
:from.Rick Ragan, IBM Austin, TX

----- REMOTE ANSWERS appended at 20:30:48 on 93/06/18 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 16:45:39 on 93/07/13 GMT (by RAGAN at AUSVM1)
:ndx.NETWR001 :abs.COMMON PROBLEM #6: Configuring IBM RLA for Netware
:key.NETWARE Novell, TBird, configuration
:QUESTION.
  How do I configure my Novell software to run with IBM RLA?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #6: Novell NetWare Server/Requester configuration
  ****************************************************************

  I will detail the specific steps in the near future, but for now,
  here are the general details for configuring IBM remote LAN
  access for NetWare.

  This information is brought to you by Mike Gibson.

  Configuring Novell NetWare for IBM remote LAN access

  NOVELL SERVER:
    To configure the Novell Server for connecting with the OS/2 RLA
    Server:
       1) Have a Novell LAN with Token Ring adapters
       2) At the Novell Server type:
                 LOAD ROUTE BOARD=x
            (Where x is the LAN adapter number the Novell Server
            will use to communicate with the OS/2 RLA Server.)
        This command adds the source routing bridge information
        to the LAN frames (ROUTE.NLM).

  NOVELL REQUESTER:
    To configure the Novell Requester to run over the OS/2 RLA
    Remote workstation:
       1) Have OS/2 2.x installed
       2) Have Novell NetWare Requester installed. Choose the
          Network Interface Card Driver: TOKEN.SYS  This action
          places the ROUTE.SYS device driver into CONFIG.SYS so
          that the LAN frames will have the source routing
          information in it that IBM RLA requires to run.
       3) Have IBM RLA installed (always install RLA last)

  Make sure before doing the following steps you have installed the
  Novell NetWare Requester.

       4) Using LAPS, configure the remote LAN access logical
          adapter to have the following protocol:
                 0 - NetWare Requester Support
       5) Using LAPS, configure the NetWare Requester Support
          protocol to match the network address of the RLA logical
          adapter.
       6) Using LAPS, configure the NetWare Frametype so that the
          frame type of the NetWare Requester is the same as the
          frame type of the NetWare Server that will be accessed.
          If you have a Token-Ring network, the TOKEN-RING frame
          type is the most common, to choose this frame type set
          this entry field to "yes".  If you have an Ethernet
          network, the ETHERNET_802.3 frame type is most common, to
          choose this frame type set this entry field to "yes".

  ERROR: Once you have configured and re-booted your IBM RLA
         workstation you may receive the NetWare message:
             NWD0115: Error getting connection ID (0X880F).

  REASON: The Novell Requester has been started through CONFIG.SYS
          and cannot find the Novell Server until after IBM RLA has
          dialed and connected.

  SOLUTION: With your favorite ASCII editor, comment out (place the
            letters REM and a space at the beginning of) the line
            in your remote workstation's CONFIG.SYS file:
                 RUN C:\NETWARE\NWDAEMON.EXE

            Shutdown, and re-start your workstation.
            Dial RLA.
            As RLA connects, and before you attempt to logon to the
            server, type from the command line:
                 START C:\NETWARE\NWDAEMON.EXE

            This will allow the Novell Requester to connect with
            the Novell Server without displaying the error message.

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 23:47:59 on 93/06/22 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 16:30:30 on 93/06/23 GMT (by RAGAN at AUSVM1)
:ndx.LAPS_001 :abs.COMMON PROBLEM #7: LAPS for RLA Remote and Server, part 1/3
:key.RLA TBIRD LAPS
:QUESTION.
  How do I configure LAPS for IBM remote LAN Access?
:ANSWER.

  ***************************************************************
  Common problem #7: LAPS for RLA Remote and Server, part 1/1
  ***************************************************************

  Common Problem #7, part 1 of 3...

  This information will assist you if you wish to run NetBIOS
  applications such as IBM LAN Requester,  802.2 applications such
  as Communications Manager, TCP/IP applications, or Novell NetWare
  Requester on IBM remote LAN access.

  The information below describes how to use LAPS and what should
  appear in both the RLA Remote and Server's PROTOCOL.INI files.

  For the sake of a starting point we will assume you have:
            > Set up a workstation currently located on
                the LAN, that will be converted to a "remote
                workstation."
            > Installed your applications
            > Installed IBM remote LAN access (always do RLA last)
            > The LAN applications are configured for LAN adapter 0
            > Now are looking at LAPS or PROTOCOL.INI

  This information has been brought to you by Binh Tran and Rick
  Ragan.

  ----------------------------------------------------------------
  LAPS CONFIGURATION FOR A RLA REMOTE WORKSTATION
    >> RLA Remote Workstation <<
  ----------------------------------------------------------------

  Philosophy for the RLA Requester:
       The applications should be configured to run on the RLA
       remote machine just as if they were running on any LAN
       workstation.  Thus, the protocols (NETBIOS, 802.2, etc) must
       be configured at the RLA remote workstation, not at the RLA
       Server.

  STEPS FOR LAPS CONFIGURATION:
  (See assumptions for starting point above)
  1) At an OS/2 command prompt, change to the \IBMCOM subdirectory
     and run LAPS, type:
            LAPS
     The LAN Adapter and Protocol Support configuration window will
       appear.
     Select the "Configure" pushbutton on the IBM LAPS Logo window.
     Select the "Configure LAN Transports" item, then select the
       "Continue..." pushbutton on the Configuration message
        window.

  2) You should now be at the main LAPS configuration window
       entitled: "Configure Workstation"

     Configure LAN Transports as follows:

     In the List box entitled "Current Configuration" select the
            1 - IBM OS/2 NETBIOS
     protocol and select the "Remove pushbutton," select the "Yes"
     pushbutton to remove this protocol.  Repeat the same steps
     for the
            remote LAN access Logical Adapter...

     In the List box entitled "Current Configuration" select the
            IBM Token-Ring Network adapters
     In the list box entitled "Network Adapters" select the
            remote LAN access Logical Adapter...
     Select the "Change" pushbutton under the list box entitled
     "Network Adapters" in order to make the "IBM Token-Ring
     Network adapters" switch to "remote LAN access Logical
     adapter."

     You should now have a "Current Configuration" list box with
       the following information in it:

    +--------------------------------------+
    |  remote LAN access Logical Adapter...|
    |            0 - IBM OS/2 NETBIOS      | <--- Required by RLA
    |            0 - IBM IEEE 802.2        | <--- Optional NOTE #1
    |            0 - IBM NetWare Requester | <--- Optional NOTE #2
    |            0 - IBM TCP/IP            | <--- Optional NOTE #3
    +--------------------------------------+

       NOTE #1: 802.2 protocol is optional and is needed only if
                you are going to run an 802.2 application such as
                Communications Manager on the remote workstation.

       NOTE #2: NetWare Requester is optional and is needed only if
                you are going to run the Novell Requester over IBM
                RLA to a Novell Server.

       NOTE #3: TCP/IP is optional and needed only if you are going
                to run applications that require TCP/IP.

  3) In the List box entitled "Currently Configuration" select "rla
     Logical Adapter"

  4) Select the "Edit" pushbutton.

  5) Enter the Network adapter address for the rla logical adapter.
     This is the virtual LAN Network address by which your RLA
     remote workstation will be identified to the LAN.  This
     address must be unique for the logical LAN RLA creates.

  6) Let's make sure that your protocols under the RLA logical
     adapter are clean.
     In the list box entitled "Current Configuration" select the
             0 - IBM OS/2 NETBIOS
     protocol.  Select the Edit pushbutton.  You now see the
     "Parameters for IBM OS/2 NETBIOS" dialog box.  Delete all
     information from the "Network adapter address" entry field.

     Repeat Step #3 for 802.2 and NetWare Requester as needed.

  7) OK pushbutton located in the lower right-hand corner of the
       "Configure Workstation" window.
     Select the Exit pushbutton on the IBM LAPS Logo window.
     Select the Continue... pushbutton on the CONFIG.SYS Update
       message window.
     Select OK to CONFIG.SYS Updated message window.
     Select the Exit pushbutton at the Exiting LAPS message.

  For technical people who want to know more about what the
  PROTOCOL.INI file looks like, we list an example below.

  WARNING: Please do not edit this file unless you have an
            excellent understanding of OS/2 control files,
            protocols, and adapters.

  NOTE: Due to translation problems, the normal square brackets you
        would see before and after each keyword will have the
        curly brackets instead, e.g., {PROT_MAN}   Your file must
        have keywords surrounded by square brackets.

  ----------------------------------------------------------------
  PROTOCOL.INI for RLA Remote
  ----------------------------------------------------------------
  {PROT_MAN}
     DriverName = PROTMAN$

  {IBMLXCFG}
     LANDD_nif = LANDD.NIF
     NETBEUI_nif = NETBEUI.NIF
     ODI2NDI_nif = ODI2NDI.nif
     TCPIP_nif = TCPIP.NIF
     PDFH_nif = PDFH.nif

  {LANDD_nif}                         <----- 802.2 protocol
     DriverName = LANDD$
     Bindings = PDFH_nif              <----- RLA as adapter 0
     ETHERAND_TYPE = "I"
     SYSTEM_KEY = 0x0
     OPEN_OPTIONS = 0x2000
     TRACE = 0x0
     LINKS = 8
     MAX_SAPS = 3
     MAX_G_SAPS = 0
     USERS = 3
     TI_TICK_G1 = 255
     T1_TICK_G1 = 15
     T2_TICK_G1 = 3
     TI_TICK_G2 = 255
     T1_TICK_G2 = 25
     T2_TICK_G2 = 10
     IPACKETS = 250
     UIPACKETS = 100
     MAXTRANSMITS = 6
     MINTRANSMITS = 2
     TCBS = 64
     GDTS = 30
     ELEMENTS = 800

  end of part 1 of 3.

:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 13:32:54 on 93/06/23 GMT (by RAGAN at AUSVM1)
:ndx.LAPS_002 :abs.COMMON PROBLEM #7: LAPS for RLA Remote and Server, part 2/3
:key.RLA TBIRD LAPS
:QUESTION.
  How do I configure LAPS for IBM remote LAN access?
:ANSWER.

  Common Problem #7, part 2 of 3...

  {NETBEUI_nif}                       <----- NetBIOS protocol
     DriverName = netbeui$
     Bindings = PDFH_nif              <----- RLA as adapter 0
     ETHERAND_TYPE = "I"
     USEADDRREV = "YES"
     OS2TRACEMASK = 0x0
     SESSIONS = 40
     NCBS = 95
     NAMES = 21
     SELECTORS = 5
     USEMAXDATAGRAM = "NO"
     ADAPTRATE = 1000
     WINDOWERRORS = 0
     MAXDATARCV = 4168
     TI = 60000                       <----- LAN Timers adjusted
     T1 = 25000                       <----- for IBM RLA
     T2 = 2000                        <-----
     MAXIN = 1
     MAXOUT = 1
     NETBIOSTIMEOUT = 500
     NETBIOSRETRIES = 8
     NAMECACHE = 0
     PIGGYBACKACKS = 1
     DATAGRAMPACKETS = 2
     PACKETS = 350
     LOOPPACKETS = 1
     PIPELINE = 5
     MAXTRANSMITS = 6
     MINTRANSMITS = 2
     DLCRETRIES = 5

  {ODI2NDI_nif}                       <----- NetWare ODI to NDIS
     DriverName = odi2ndi$
     Bindings = PDFH_nif              <----- RLA as adapter 0
     TOKEN-RING = "yes"
     TOKEN-RING_SNAP = "no"
     ETHERNET_802.3 = "no"
     ETHERNET_802.2 = "no"
     ETHERNET_II = "no"
     ETHERNET_SNAP = "no"
     TRACE = 0x0

  {TCPIP_nif}                         <----- TCP/IP
     DriverName = TCPIP$
     Bindings = PDFH_nif              <----- RLA as adapter 0

  {PDFH_nif}
     DriverName = PDFH$
     NETADDRESS = "t4000000000AA"     <----- RLA LAN Network
                                             address, must be
                                             unique for the LAN.

   {VLAN_KERNEL}                      <----- RLA Virtual LAN
     DRIVERNAME = VLANKNL$                   device driver
     CFGTYPE = "Locked"
     MODE = "POINT_TO_POINT"
     LANTYPE = "802.5"
     MAXADDRESSES = 512

  {COM1}
     DRIVERNAME = WCLCPMC$
     CFGTYPE = "LOCKED"
     PCMSUPPORT = "YES"
     MACTYPE = "802.5"
     CONN_TYPE = "SWITCHED"
  ----------------------------------------------------------------
  end of PROTOCOL.INI for RLA Remote workstation
  ----------------------------------------------------------------

  ----------------------------------------------------------------
  LAPS CONFIGURATION FOR A RLA SERVER
    >> RLA Server <<
  ----------------------------------------------------------------

  Philosophy for the RLA Server:
       The only protocol stack needed for the RLA Server is NetBIOS
       for both the Token Ring adapter and for the IBM RLA logical
       adapter.  All application protocols are configured at the
       RLA Remote workstation.

  1) Configure the RLA Server to include the following adapters and
     protocols.  See the above steps (1-7) if you are unsure about
     how to work with LAPS to achieve the results listed below.

     Once completed, your LAPS "Current Configuration" list box
     should have the following information in it:

    +---------------------------------------+
    |  IBM Token Ring Network Adapters      |
    |            0 - IBM NetBIOS            | <--- Required by TR
    |            0 - xxxxxxxxxxxxxx         | <--- NOTE #1
    |  remote LAN access Logical Adapter... |
    |            1 - IBM OS/2 NETBIOS       | <--- Required by RLA
    +---------------------------------------+

       NOTE #1: If the server is strictly a workstation dedicated
                to IBM RLA, then no other protocols will be under
                the TR adapter.  Only if this Server has the dual
                purpose of running IBM RLA and also running
                applications as a LAN-attached workstation for a
                user sitting at this Server would there ever be a
                need to include other protocols under the TR
                adapter.

  For technical people who want to know more about what the
  PROTOCOL.INI file looks like, we list an example below.

  NETBIOS is configured for IBM Token-Ring as adapter 0 and for
  remote LAN access Logical Adapter as adapter 1. RLA Setting
  configuration: RLA bridge, COM1, and COM3 for async switched
  connection to the receive calls.

  WARNING: Please do not edit this file directly unless you have an
            excellent understanding of OS/2 control files,
            protocols, and adapters.

  NOTE: Due to translation problems, the normal square brackets you
        would see before and after each keyword will have the
        curly brackets instead, e.g., {PROT_MAN}    Your file must
        have keywords surrounded by square brackets.

  ----------------------------------------------------------------
  PROTOCOL.INI for the RLA Server
  ----------------------------------------------------------------
  {PROT_MAN}
     DRIVERNAME = PROTMAN$

  {IBMLXCFG}
     NETBEUI_nif = NETBEUI.NIF
     IBMTOK_nif = IBMTOK.nif

  {NETBEUI_nif}                       <----- NetBIOS protocol
     DriverName = netbeui$
     Bindings = IBMTOK_nif,PDFH_nif   <----- Token-Ring as
     ETHERAND_TYPE = "I"                     adapter 0 and
     USEADDRREV = "YES"                      RLA as adapter 1
     OS2TRACEMASK = 0x0
     SESSIONS = 40
     NCBS = 95
     NAMES = 21
     SELECTORS = 5
     USEMAXDATAGRAM = "NO"
     ADAPTRATE = 1000
     WINDOWERRORS = 0
     MAXDATARCV = 4168
     TI = 60000                <----------- LAN timers adjusted
     T1 = 25000                             for WAN speeds
     T2 = 2000
     MAXIN = 1
     MAXOUT = 1
     NETBIOSTIMEOUT = 500
     NETBIOSRETRIES = 8
     NAMECACHE = 0
     PIGGYBACKACKS = 1
     DATAGRAMPACKETS = 2
     PACKETS = 350
     LOOPPACKETS = 1
     PIPELINE = 5
     MAXTRANSMITS = 6
     MINTRANSMITS = 2
     DLCRETRIES = 5

  {IBMTOK_nif}
     DriverName = IBMTOK$
     ADAPTER = "PRIMARY"
     MAXTRANSMITS = 6
     RECVBUFS = 2
     RECVBUFSIZE = 256
     XMITBUFS = 1
     ENABLEBRIDGE

  end of part 2 of 3.
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 13:35:06 on 93/06/23 GMT (by RAGAN at AUSVM1)
:ndx.LAPS_003 :abs.COMMON PROBLEM #7: LAPS for RLA Remote and Server, part 3/3
:key.RLA TBIRD LAPS
:QUESTION.
  How do I configure LAPS for IBM remote LAN access?
:ANSWER.

  Common Problem #7, part 3 of 3...

  {VLAN_KERNEL}                      <----- RLA's Virtual LAN
     DRIVERNAME = VLANKNL$                  device driver
     CFGTYPE = "Locked"
     MODE = "POINT_TO_POINT"
     LANTYPE = "802.5"
     MAXADDRESSES = 3500

  {PDFH_nif}                         <----- RLA logical adapter
     DRIVERNAME = PDFH$
     NETADDRESS = "t4000000000FF"    <----- Logical LAN Network
                                            Address, must be unique
  {sr_bridge}
     DriverName = BRIDGE$
     Bridgenum = 15                  <----- Make sure there are no
     Maxframe = 516                         duplications within the
     Spanningtree = NO                      same LAN segment.
     CfgType = "Locked"
     Bindings = IBMTOK_nifB,BRIDGEFH
     Ringnum = 0xA54,0x222           <----- Your LAN Segment in Hex
     Maxhopcount = 3,3                      and WAN Segment in Hex

  {BRIDGEFH}
     DriverName = LANFH$01
     CfgType = "Locked"

  {COM1}
     DriverName = WCLCPMC$
     CFGTYPE = "LOCKED"
     PCMSUPPORT = "yes"
     MACTYPE = "802.5"
     CONN_TYPE = Switched

  {COM3}
     DriverName = WCLCPMC$
     CFGTYPE = "LOCKED"
     PCMSUPPORT = "yes"
     MACTYPE = "802.5"
     CONN_TYPE = Switched
  ----------------------------------------------------------------
  end of PROTOCOL.INI file for the RLA Server
  ----------------------------------------------------------------

  end of Common Problem #7
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 19:38:45 on 93/07/12 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 16:47:35 on 93/07/13 GMT (by RAGAN at AUSVM1)
:ndx.SECUR001 :abs.COMMON PROBLEM #8: What security does RLA contain? Part 1/2
:key.security RLA TBIRD
:QUESTION.
  What security features does the IBM remote LAN access product contain?
:ANSWER.

***************************************************************
Common problem #8: What security does RLA contain, Part 1/2
***************************************************************

Common Problem #8, part 1 of 2...

  Part 1 of 2   Page 1 of 7
                05/27/93
                IBM remote LAN access for Token Ring

                         IBM Wide Area LAN/2 for Token Ring

   Wide Area LAN/2 (WAL/2) Server - Security Runtime Services

     The primary goal of WAL runtime security is to protect the LAN
     wire from casual, unauthorized external access.  When a external
     WAN circuit is established at a WAL Server using a Public
     Switched Network, WAL runtime security services will ensure
     that no LAN frames will be transfered onto the WAN circuit and no
     WAN frames will be transfered onto the LAN wire UNTIL
     the caller is authenticated.  In addition, if there are already
     several external users that have been authenticated and are currently
     accessing application servers on the LAN, WAL runtime security will
     ensure that a NEW caller will not see any of the traffic between
     the LAN and any of these prior users until the new caller has been
     authenticated.  A new caller can learn nothing about the names being
     used on the LAN until the caller is authenticated and a new caller
     will not be able to introduce any data (e.g. inject error frames) onto
     the LAN until the caller is authenticated at the WAL Server.

     A secondary goal of the WAL/2 server runtime security is to ensure
     that when a WAL/2 server receives a request for service, the server
     can determine that the request was sent by an authorized user, the
     request received has not been modified in transit, and the current
     message is not a copy of a prior message.

     Before a WAL/2 workstation sends requests to a secured WAL/2 server,
     the WAL/2 workstation must first ensure that the user at the WAL/2
     workstation is authenticated by the WAL/2 server.  If the workstation
     user is authenticated successfully (i.e.  the user provides the
     correct password), the workstation will be able to generate server
     CERTIFICATES that can be added to requests sent to the server.  When a
     secure WAL/2 server receives a request containing a certificate, the
     server (i.e.  its runtime security component) can validate the
     certificate and verify that the user sending the request is authentic
     and is authorized by the WAL/2 server to request the service.
     Moreover, a valid certificate will contain proof that the request
     itself has not been modified since being sent and is not a copy of a
     certified request (sent earlier by a "good" user) that was
     introduced by a "hacker" masquerading as the "good" user.

   RLA/2 Server Security Features
    *  User Permission Types

         A separate data base of user accounts is maintained at each RLA/2
         server.

      -  USER

         This is the lowest security classification.  A user of this type
         has permission to access the dial services of a RLA/2 server in
         order to dial off LAN and can be granted permission to remotely
         attach to the LAN wire by calling a RLA/2 server.  A user of this
         type can also view and change selected information (e.g.  user
         description and user password) within the user's own account at a
         RLA/2 server.

      -  ADMINISTRATOR

         This user type has the same privileges as a USER type and, in
       Page 2 of 7

      -  SECURITY ADMINISTRATOR

         This user type has the same privileges as an ADMINISTRATOR and,
         in addition, is authorized to maintain a RLA/2 Server's User
         Account Data Base.  This user can change user account policy
         parameters (e.g.  maximum number of logon attempts permitted
         during a single call), and can view, add, and delete user
         accounts within the User Account Data Base.  This user can also
         change any of the account information contained in other user's
         accounts.

    *  Optional Security
     The security feature of a RLA/2 Server is a configuration option.
     If security is disabled, any person can access the configuration
     interface at the RLA/2 Server and enable its security option.
     However, once security is enabled, only a user designated as a RLA/2
     security administrator can logon to the RLA/2 server and disable the
     security sub-system.

     Enabling or disabling security at a RLA/2 Server is a LOCAL operation
     only and can not be performed remotely. That is, a RLA/2 security
     administrator must be physically located at the RLA/2 server machine
     when operating the RLA/2 configuration user interface that toggles
     the state of the security sub-system.

    *  User Authentication Protocol
     The RLA/2 security sub-system implements a two party, two way entity
     authentication protocol based upon the IBM patented protocol "2PP".
     Like 2PP the RLA/2 security protocol uses Message Authentication
     as the primitive on top of which it solves the entity authentication
     problem.  The message authentication scheme uses DES to generate the
     required cryptographic checksum and adheres to the X9.9 standard.

     After a successful mutual authentication - client to server and
     server to client - the client and server both share a common secret
     SESSION KEY that is used to build the certificates that
     authenticate all subsequent workstation service requests sent to the
     server.  A different session key is used during each separate logon
     session.

    *  Password Phrases
     To minimize the possibility of off-line "dictionary attacks" to
     discover user passwords, RLA/2 security supports "pass phrases".
     Up to 32 case sensitive characters can be used to build individual
     tokens that comprise a password phrase.  The password phrase is
     one-way encrypted using the xxxxx algorithm into an eight byte
       Page 3 of 7
     is the initial shared secret that is the basis for the message
     authentication scheme used in the RLA/2 user authentication logon
     protocol.

    *  Single Logon
     A user is required to logon and be authenticated by each secured
     RLA/2 Server before accessing the server's services (e.g.  Dialer
     services, Management services, or access to the target LAN wire).
     However, a user need only be involved in a single logon task (i.e.
     supplying his/her User Id and password) provided the user has the
     same User Id and password at each of the RLA/2 servers that the user
     subsequently attempts to access.  The user id and password used
     during the first logon are saved (in memory only) by the RLA/2
     workstation security component and used first for each of the
     following logon attempts at the other servers.  The user will be
     required to participate in a second logon only if the user's User
     Id or password is different at the next RLA/2 server accessed.

    *  Policy Options
     Several user authentication policy options can be configured by a
     RLA/2 Security Administrator when setting up a RLA/2 Server:
      -  Maximum Password Age

         User's with passwords will be required to change their passwords
         when the age of their current password exceeds this time period.
         The user will not be permitted to logon until a valid new
         password has been submitted.  The new password will not take
         effect until the next logon (i.e.  the current password will be
         used for the password change session).  The user will be
         permitted to change his/her own password prior to the password's
         expiration time using a separate User Account Management
         interface.  The default is 30 days and a "no maximum" selection
         is supported.

      -  Minimum Password Age

         A RLA/2 Security Administrator will be able to specify a time
         period during which a user will not be able to change a recently
         established password.  The default time period is 0 days which
         means that there is no restriction on when a user can change a
         newly assigned password.

      -  Minimum Password length

         A RLA/2 Security Administrator can establish the minimum password
         length that is required for each user account.  The minimum
         password length can be from 4 to 32 characters.
         password length is 32 characters. The default is 8 characters.

      -  Password History

         A RLA/2 Security Administrator can specify that a history of from
         0 to 8 prior passwords be saved in the users account.  Whenever
         the user changes his/her password, the new password is checked
         against these password history values to ensure the new password
         is not a duplicate of a recent password.  If a duplicate is
         found, the new password submitted is reported to be invalid and
         the user will be asked to submit another new password.  The default
         is 8 prior passwords.

  end of part 1 of 2, continued.
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 13:21:37 on 93/07/13 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 16:47:43 on 93/07/13 GMT (by RAGAN at AUSVM1)
:ndx.SECUR002 :abs.COMMON PROBLEM #8: What security does RLA contain? Part 2/2
:key.security RLA TBIRD
:QUESTION.
  What security features does the IBM remote LAN access product contain?
:ANSWER.

  Common Problem #8, part 2 of 2...

      -  Maximum Unsuccessful Logon Attempts

         A RLA/2 Security Administrator will be able to specify the number
         of unsuccessful logon attempts that will be permitted for each
         call.  A logon attempt can fail because an unknown User Id is
         submitted, an inactive account is being accessed, the password is
         incorrect, the user is calling from a workstation with a LAN
         adapter address that is invalid for the account, or the user is
         calling during a day of the week or a time of day that is invalid
         for the account.  The default is four attempts.

         If the maximum number of logon attempts is exceeded, the user's
         account will automatically be marked as inactive.  In this situation,
         in order to logon in the future, a user will be required to contact
         the RLA/2 Security Administrator in order to have the account
         re-activated.

   Dialback and Additional Security Options
    *  DialBack

     RLA/2 security supports an optional dialback feature for remote RLA/2
     (standalone) workstations only; dialback to RLA/2 LAN workstations
     (workstations physically attached to the LAN) and RLA/2 Servers is
     not supported.  The dialback option configured within the caller's
     account will not be checked unless the call is placed from a remote
     RLA/2 (standalone) workstation.

     The dialback option within a user account can be configured as
     follows:

      -  Dialback not required
         These user's will never be called back by the called server.
      -  Fixed Dialback
         These user's will be called back at a fixed configured telephone
         number.
      -  Mobil Dialback
       Page 5 of 7
         part of the logon protocol.  The server will then use the
         telephone number submitted to it for the Dialback.

      The caller will be authenticated both prior to the dialback call
      (this will prevent harassment calls) and also after the dialback is
      is complete (this will guard against known hacker techniques that
      can normally only be avoided using special telephone equipment or
      service options).  Dialback can be useful if reversal of telephone
      charges is needed (e.g. the majority of the charges for a call from
      a hotel room can be be charged to the central site instead of the
      traveler at the hotel).

    *  Workstation Address Identification
      A RLA/2 Security Administrator can configure 0 to 8 workstation
      LAN MAC addresses within a user account.  The caller must call from
      a workstation that has been configured with a LAN adapter MAC address
      that matches one of the MAC addresses stored in the caller's account,
      otherwise the logon attempt will fail.

    *  Valid Logon Time Intervals
     A RLA/2 Security Administrator can configure the days of the week and
     the time of day during these weekdays that a user is allowed to logon
     to his account at the RLA/2 server.
     logon at a time that is not within one of the specified time
     intervals within the user's account, the logon attempt will fail.

   Summary of IBM RLA/2 Server Logon protocol
     The RLA/2 server implements a protocol for MUTUAL AUTHENTICATION in
     the shared key model.  Two parties who share a secret
     password-derived KEY want to interact with one another and to be able
     to mutually identify one another.  After the mutual authentication is
     complete, both parties should simultaneously share a random and secret
     SESSION KEY.

     The protocol  satisfies the following requirements:
     *  The protocol provides mutual authentication between a
        client and a server.  In the process of authenticating one
        another, the client and server come to share a random
        session key.

     *  The client initiates the protocol. The client has no information
        about the server except the server's address. The client has a
        user id and user-supplied password for authentication.

     *  The server has no information about the client besides the
        client's id and password-derived KEY.  The server is physically
        secure (and may store secrets).
       Page 6 of 7
     *  The client's computational resources may be quite limited (a
        low-end PC, say). The server's computational resources are
        moderate to high (a mid-range PC, say). The adversary's
        computational resources may be considerable.

     *  An adversary can watch all communication and can interact
        with the client and server to try to subvert authentication.
        The number of such interactions possible in a day is not too large.

     *  Compromise of session keys should have no ill-effects
        outside the current session.

   Description of RLA/2 logon protocol
    A, RA
     from a user password phrase using a one-way cryptographic hash
     algorithm.  The password phrase can consist of 4 - 32 case
         B
     The resulting key is 8 bytes in length.

     The protocol requires three rounds and resembles the patented IBM
     protocol 2PP.  The protocol is shown in the following
     Figure:

      Flow 1  ──────────────────────────────────────────>

                 RB, Fa
      Flow 2  <─────────────────────────────────────────

                 Fa
      Flow 3  ──────────────────────────────────────────>

     Figure 1.  A variant of the protocol 2PP.

     In this protocol, A sends B a random value RA together with the
     name A (the name A should be unique among the entities who share the
     secret key 'a' - for example User Id).

     B responds by choosing its own random value RB and returns both RB
     and Fa, a message authentication code of the contents of the A's
     message, the random value RB, and its own name.

     The message authentication code is derived using the X9.9 standard
     (i.e.  applying DES CBC to the input string using key 'a' and a null
     initialization vector).  The message authentication code is the last
     CBC block in the chain.
       Page 7 of 7
     A compares the message authentication code received from B with the
     message authentication code A has generated locally and if they
     match, A accepts B as authentic.  A then returns a new message
     authentication code Fa back to B (flow3).

     When B gets this message, he computes his own message authentication
     and compares his code with the one received from A. If the two
     codes match, B accepts A as authentic.

     As a result of the exchange, each party that accepts can regard
     himself as being in possession of a random, shared, secret SESSION
     KEY.  This session key is a message authentication code
     which both sides can compute.

     The protocol of Figure 1 is, of course, susceptible to dictionary
     attacks if the user fails to take advantage of the capability of a
     full password phrase (e.g.  a single word is used for the password
     instead of a case sensitive phrase such as "My lily are ASTRO turf").

     In future releases of RLA/2, the protocol above may be enhanced by
     adding information in the scope of the message authentication codes
     of flows 2 and 3 - information that is not known to an adversary and
     that results from a secret key exchange that occurs concomitantly
     with the authentication.  By adding this new information within the
     the flows, the protocol will be made resistant to off-line dictionary
     attacks even if "dictionary words" are used as passwords.  If an
     adversary collects proper authentication transcripts and correctly
     guesses the shared key, there will be no way for the adversary to verify
     the guess by studying the transcripts themselves; instead, the
     adversary will be forced to interact with one of the real parties to
     see if a candidate password works and thus expose his activities to
     auditors.

     In addition, learning a clients password at some point in time
     will not compromise session keys used at EARLIER points in time.

     Unfortunately, the proposed protocol enhancement can not be described
     here - it is currently proprietary and has been submitted as a
     candidate for an IBM patent.

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 20:49:28 on 93/07/27 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 14:14:51 on 93/07/28 GMT (by RAGAN at AUSVM1)
:ndx.LAN_0001 :abs.COMMON PROBLEM #9: LAN Server 2.0 fails to work
:key.RLA TBIRD LAN DISTANCE LAN Server 2.0
:QUESTION.
  Why does my LAN Server 2.0 and LAN Requester 2.0 fail to work with
  IBM remote LAN access (LAN Distance)?
:ANSWER.

  ****************************************************************
   COMMON PROBLEM #9: IBM LAN Server / Requester 2.0
  ****************************************************************

  If you are using IBM LAN Server 2.0 or IBM LAN Requester 2.0, you
  may have problems logging on to the Domain Controller with LAN
  Distance.

  LS 2.0 SYMPTOMS:

  RLA starts correctly, without error messages.

  A wide variety of error messages could occur including LAN
  Requester failing to start, failed logon attempts, etc.

  If you type the following command at the OS/2 command prompt:

        NET ERROR

  You will see a log containing one or both of the following
  errors:

  ----------------------------------------------------------------
  NET 3106: An unexpected NCB was received.
  ----------------------------------------------------------------
  NET 3140: The service has stopped due to repeated consecutive
  occurrence of an NCB error.
  ----------------------------------------------------------------

  LS 2.0 PROBLEM ONLY:

  Due to an incompatibility problem between the latest NETBIOS
  driver that is shipped with IBM LAN Distance and the NETBIOS
  driver provided with LAN Server 2.0, IBM LAN Server 2.0 will
  eventually fail to run over LAN Distance.

  LS 2.0 SOLUTION ONLY:

  *******************************************************************
    >> FOR IBM LAN SERVER 2.0 & IBM LAN REQUESTER 2.0 USERS ONLY <<
  *******************************************************************
  *                                                                 *
  * An APAR exists for this bug, APAR JR07340.  You may either call *
  * IBM at 1-800-237-5511 to request this fix, or you can carry out *
  * the following steps:                                            *
  *                                                                 *
  * Do not apply this fix to your workstations unless they are      *
  * either LAN Server 2.0 or LAN Requester 2.0.                     *
  *                                                                 *
  *    1) Place LAN Distance Diskette #3 into the diskette drive    *
  *        >>> for the 2nd beta diskettes only <<<                  *
  *    2) At an OS/2 command prompt, enter the \IBMCOM\PROTOCOL     *
  *         subdirectory                                            *
  *    2) Backup your old file with the command:                    *
  *              COPY  NETBIOS.OLD                                  *
  *    3) Type the command:                                         *
  *              COPY A:\NETBIOS.LS2 NETBIOS.OS2                    *
  *    4) Remove the diskette                                       *
  *    5) Shutdown and re-start your workstation.                   *
  *******************************************************************

  Rick Ragan,  Austin, TX
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 18:37:13 on 93/07/28 GMT (by RAGAN at AUSVM1)
:ndx.BETA_001 :abs.COMMON PROBLEM #10: Beta code of LAN Distance has expired.
:key.BETA TBIRD expired LAN DISTANCE
:QUESTION.
  What do I do if I get the error message that my Beta code has expired?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #10: "Beta Code of LAN Distance has expired."
  ****************************************************************

  SYMPTOMS:

  You successfully install the 1st or the 2nd beta code on a
  workstation.

  > The current date on your workstation is before: 11/01/93.

  > When you double click on the LAN Distance icon, you receive the
    following error message.
     WCL0590I:
       This beta code of IBM's LAN Distance has expired.
       Please see you IBM representative for information on
       obtaining the official Licensed version of this product.

  PROBLEM #1:
       If you have not run this beta before (and the date on your
       workstation is before 11/01/93), then you have a workstation
       that does not have a valid and formatted C: drive.

  SOLUTION #1:
       Either prepare your workstation to have a usable, formatted
       C: drive, or install LAN Distance's beta on a workstation
       that has a valid C: drive.

  PROBLEM #2:
       If the date of your workstation is after 11/03/93, your beta
       code has expired.

  SOLUTION #2:
       Please discard the LAN Distance beta code and purchase a
       copy of LAN Distance from your local IBM representative.
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 14:08:30 on 93/08/09 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 23:54:00 on 93/11/12 GMT (by RAGAN at AUSVM1)
:ndx.BRIDGE01 :abs.COMMON PROBLEM #11: Setting up the LAN Distance Bridge
:key.Bridge BETA LAN DISTANCE TBIRD hop count
:QUESTION.
  How do I set up my bridge to get the values such as hop count, LAN Segment
  number, etc?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #11: Setting up the LAN Distance Bridge
  ****************************************************************

  | highlighted change in OS2PING command (dropped -sr)

  PROBLEM:

  When setting up the LAN Distance Connection Server, there are
  five major issues to get the bridge part of LAN Distance working
  correctly.

  The "Controller" mentioned below could be an IBM LAN Server's
  Domain Controller, or the 3270 Controller to get to the host,
  etc.

  1) LAN Adapter address to tell the LAN Distance Remote
       workstation the location of the Controller (configured on
       the LAN Distance Remote machine.
  2) Unique bridge number (0-15) for LAN Distance's bridge
       (configure on LAN Distance's Connection Server).
  3) LAN Segment Ring number (3 digit hexadecimal) the LAN Distance
       Connection Server is located (configure on LAN Distance's
       Connection Server).
  4) Network Bridge Hop count from the LAN Distance Remote
       workstation to the Controller (configure on LAN Distance's
       Connection Server).
  5) Possible need to increase the Hop count for all bridges
       between the LAN Distance Remote workstation and the
       Controller (configure at each bridge).

  SOLUTION:

  On OS2TOOLS, there is a very valuable tool called OS2PING.

  This applet is highly recommended for anyone who is having
  problems with the items 1-5 above, or anyone who wants to
  discover more about their LANs.  The 802.2 protocol is required
  to run OS2PING.  This protocol is shipped with the LAN Distance
  product.

  OS2PING COMMAND FOR LAN DISTANCE:

   |    OS2PING -a=xxxxxxxxxxxx -r

   |  WHERE:
   |    xxxxxxxxxxxx is the destination address of the Controller.
   |    r is the command to display formatted routing information.

  THIS EXAMPLE WILL PING:

       from LAN Distance Remote workstation to the Controller.

  THE RESULTING ROUTING INFORMATION FROM OS2PING IS:

       (002) 1 --> (cea) 7 --> (b22) 5 --> (c3a)

  WHAT DOES THIS RETURNED INFORMATION MEAN?

   Each number in parenthesis (cea) is a LAN Segment number for a
       specific LAN.

   Each number after the LAN Segment is the bridge's unique number.

   In this example, the Ping traveled from WAN1 across three
       bridges to LAN4:

       (002)  --- 1 ----> (cea) --- 7 --> (b22) --- 5 --> (c3a)

       (WAN1)  LD/Bridge  (LAN2)  Bridge  (LAN3)  Bridge  (LAN4)

   The LAN Distance connection is WAN1 (the default WAN Segment
       for the LAN Distance product is 002).

   The LAN Distance Connection Server is the first bridge with a
   default number "1".

   The Controller is on LAN4 (this is always the last LAN Segment
       in the returned information).

  LAN DISTANCE BRIDGE SOLUTIONS:

  1) The LAN Adapter address for the Controller is xxxxxxxxxxxx
       (this is the known value you obtained from your LAN
       Administrator).

  2) A unique Bridge number (0-15) for the LAN Distance Connection
       Server worked with the default number 1.

  3) The LAN Distance Connection Server is located on
       LAN Segment Ring number: cea.

  4) The Network Bridge Hop count from the LAN Distance Remote
       workstation to the Controller is 3 (count the bridges = one
       LAN Distance bridge and 2 LAN bridges).

  5) The ping from the LAN Distance Remote workstation to the
       Controller returned from the Controller.  There is no need
       to adjust the bridges to add an extra hop count.

  Additionally, to trouble shoot bridging problems, you can follow
  this sequence:

  a) Ping from Connection Server to any LAN workstation located on
       that LAN segment the Connection Server is located.

  b) Ping from the Connection Server to the Controller.

  c) Ping from the LAN Distance Remote workstation to the
       Connection Server.

  d) Ping from the LAN Distance Remote workstation to the
       Controller.

       If the ping from the LAN Distance Remote workstation to the
       Controller fails, and OS2PING returns the message:

         OS2PING: No responses received during 10 second wait.

       Then you may either have an incorrect destination address
       for the Controller, or you bridges may be tuned so tightly
       that a response cannot return.

       One way to test this is to systematically ping from the LAN
       Distance Remote Workstation to a LAN-attached workstation on
       each intervening LAN.  For example from the LAN Distance
       Remote workstation (WAN1), ping a known address on LAN2,
       ping a known address on LAN3, and ping a known address on
       LAN4.  If all pings return except on LAN4, then the bridge
       between LAN3 and LAN4 may need its hop count increased.

  NOTE: If your OS2PING produces multiple lines:

    OS2PING: First response received
    OS2PING: ADDR=xxxxxxxxxxxx Route was:
    (002) 1 --> (cea) 7 --> (b22) 5 --> (c3a)

    OS2PING: Later response(s) :
    OS2PING: ADDR=xxxxxxxxxxxx Route was:
    (002) 1 --> (cea) 7 --> (b22) 5 --> (c3a)

    OS2PING: ADDR=xxxxxxxxxxxx Route was:
    (002) 1 --> (cea) 7 --> (4ab) 2 --> (c21) 3 --> (b31) 5-->(c3a)

       These additional LANs represent various paths your ping can
       take from your LAN Distance Remote Workstation to the
       Controller.

       Just as you can drive to work using several different roads,
       OS2PING will show you the various paths back to the
       Connection Server from the Controller.  You can use any path
       that is stable; however, you may wish to use the path with
       the fewest hop counts in order to minimize the number of
       bridges and LANs.  The LAN Segment Ring number will always
       be the same (last) number for your Controller, no matter
       which path it takes to get to the controller.  (You always
       make it to work, no matter which road you take to get
       there.)

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 15:19:32 on 93/08/12 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 15:34:44 on 93/08/12 GMT (by RAGAN at AUSVM1)
:ndx.         :abs.

----- REMOTE ANSWERS appended at 15:26:28 on 93/08/12 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 18:45:39 on 93/09/03 GMT (by RAGAN at AUSVM1)
:ndx.ERROR001 :abs.COMMON PROBLEM #12: WCL0336 Error Message
:key.WCL0336 autoanswer modem string
:QUESTION.
  How do I recover from a WCL0336 error message?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #12: WCL0336 Error message
  ****************************************************************

  <update, #7, Practical Peripherial modem string bug>

  ERROR MESSAGE:

  WCL0336: The connection was made, but the LAN Distance frame
           handler could not be attached to the connection.  The
           connection was dropped.

  PHILOSOPHY:
       This error message occurs due to multiple reasons.  There
       are at least six possible problems that could lead to the
       WCL0336 error message:

       #1 - No Autoanswer for the Connection Server
       #2 - Incorrect Modem String
       #3 - Defective Modem Cable
       #4 - Token Ring / Ethernet mis-match
       #5 - LAN Segment / WAN Segment mis-match
       #6 - non LAN Distance Destination mis-match
       #7 - bug in Practical Peripherial modem string

  PROBLEM #1: No Autoanswer for the Connection Server
       If you have a LAN Distance Remote workstation dialing into a
       LAN Distance Connection Server, the Connection Server may
       not be in Autoanswer mode.  The Remote workstation will
       establish a partial link with the Connection Server then the
       connection will be quickly dropped.

  SOLUTION #1: No Autoanswer for the Connection Server
       For the LAN Distance Connection Server (or Remote that may
       be trying to receive a call) Open as Settings, Answer tab,
       select PSTN_ALL_CALLS, for temporary configuration select
       the "Start mode" pushbutton, for permanent configuration
       select the Change pushbutton and check "Enable answer mode
       on startup".

  PROBLEM #2: Incorrect modem string
       The Error message WCL0221: "LAN Distance could not
       initialize the modem" is a precursor to the WCL0336 message
       if you have an unsupported modem, or a damaged cable.  A
       poorly designed modem string or a very badly damaged modem
       cable may be unable to form even a partial LAN Distance
       connection thus producing the WCL0221 error message.  With a
       better modem string or a "not as damaged" modem cable the
       LAN Distance connection would be temporarily established,
       however the LAN Distance session will fail and produce the
       WCL0336 error message.

       If you are attempting to use an unsupported modem and you
       have created a modem string that leads to a temporary LAN
       Distance connection, but fails to establish a fully
       functional LAN Distance session, the WCL0336 error message
       may result.  Below are some of the possible errors in modem
       string constructions:
            DTE rate is not set to fixed in the initialization
            string of WCLNET.INI or PIF file.

            Incorrectly, the AutoBaudDetect keyword
                 Default = "On"
            may have been set in the WCLNET.INI and the PIF
            file.

            DSR is incorrectly set to always be low in the modem
            string of the WCLNET.INI or PIF file.

            CR is incorrectly set to always be low in the modem
            string of WCLNET.INI or PIF file.

  SOLUTION #2: Incorrect modem String
            Set DTE rate to fixed in the Initialization string of
              the WCLNET.INI and/or PIF file

            Confirm the AutoBaudDetect keyword
                 Default = "Off"
            is indeed set to "Off" in the WCLNET.INI and the PIF
            file.

            DSR (Data Set Ready)
            The DSR is a signal the modem sends to the computer to
            indicate that the modem is ready have a dialog.
            Configure the DSR for your modem to go from on to off
            when a connection terminates. (For most modems, the
            correct command is &S1).  Set DSR properly in the
            Initialization string of the WCLNET.INI and/or PIF file

            CD (Carrier Detect)
            The CD signal tracks the presence or absence of the
            carrier signal from the modem on the other end of the
            line.  Some modem manuals refer to the CD as the DCD or
            RLSD.  Modems can be configured to interpret the CD in
            several ways.  Select the CD modem command that causes
            the modem to track the status of the carrier detect
            signal. (For most modems, this command is C1).  Set CD
            properly in the Initialization string of the WCLNET.INI
            and/or PIF file

  PROBLEM #3: Defective modem cable
       The LAN Distance workstation connecting with your
       workstation may have a defective cable.  The modem cable may
       be wired improperly.  Some modems are more sensitive to
       improper modem cables than others.

  SOLUTION #3: Defective modem cable
       Test the modem cable with another asynchronous software
       package (such as OS/2 2.1's PM Terminal in the Productivity
       folder) to insure it is working correctly.  Or switch out
       the suspected modem cable with a cable that is known to work
       correctly.

  PROBLEM #4: Token Ring / Ethernet mis-match
       If you have configured your LAN Distance workstation to work
       on one type of LAN and you have actually dialed into another
       type of LAN, you will get the WCL0336 error message.  For
       instance, if you have configured LAN Distance to work on a
       Token Ring LAN, but dial into a Connection Server located on
       an ethernet LAN, then LAN Distance will fail with this
       message.

  SOLUTION #4: Token Ring / Ethernet mis-match
       Insure that you LAN Distance workstation is configured for
       the same type of LAN hardware that you are actually dialing
       into.

  PROBLEM #5: LAN Segment / WAN Segment mis-match
       If you have a LAN Distance Connection Server dialing into
       another LAN Distance Connection Server, the LAN Segment Ring
       Number and the WAN Segment Ring Numbers must be set
       correctly.  Dialing from one Connection Server to another
       Connection Server is an unsupported feature in the LAN
       Distance product, version 1.0.

  SOLUTION #5: LAN Segment / WAN Segment mis-match
       LAN Distance Connection Servers connecting with each other
       is an unsupported function for the 1st release of LAN
       Distance 1.0, however you may try the following
       configuration:
       > LAN Segment Ring Numbers must be different from each other
       > WAN Segment Ring Numbers must be identical

  PROBLEM #6: non LAN Distance Destination mis-match
       If you have selected "Connect to a non LAN Distance
       destination" and dialed into another LAN Distance
       workstation that has "Connect to a non LAN Distance
       destination" de-select (this is the default LAN Distance
       ships with), LAN Distance will fail with the WCL0336 error.

  SOLUTION #6: non LAN Distance Destination mis-match
       The "Connect to a non LAN Distance workstation" parameter
       must be the same on either side of the LAN Distance
       connection.  Set both workstations to "Connection to a non
       LAN Distance workstation," or set both so that both are not
       set to "Connect to a non LAN Distance workstation."  (Set
       this to not "Connect to a non LAN Distance workstation" if
       you do not plan to have Security enabled and you also desire
       faster performance.)

  PROBLEM #7: bug in Practical Peripherals modem string
       There is a bug in the Practical Peripherals modem strings
       shipped in the LAN Distance second beta.

  SOLUTION #7: bug in Practical Peripherals modem string
    The Practical Peripherals modem strings have an error.
    The PIF file and the WCLNET.INI will read:

  Default = "ATE1L0M1N1Q0V1X4Y1&C1&D2&K3&Q5&R0&S0S0=2S7=60\CR"
                                              |||

  Edit both files (WCLNET.INI to say: &S1 rather than &S0.

  Default = "ATE1L0M1N1Q0V1X4Y1&C1&D2&K3&Q5&R0&S1S0=2S7=60\CR"
                                              |||

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 18:18:24 on 93/09/03 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 14:27:10 on 93/09/30 GMT (by RAGAN at AUSVM1)
:ndx. :abs.

----- REMOTE ANSWERS appended at 19:53:16 on 93/09/14 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 23:55:47 on 93/11/12 GMT (by RAGAN at AUSVM1)
:ndx.   :abs.

----- REMOTE ANSWERS appended at 19:56:08 on 93/09/14 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 14:27:40 on 94/01/04 GMT (by RAGAN at AUSVM1)
:ndx. :abs.

----- REMOTE ANSWERS appended at 14:45:11 on 93/09/27 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 15:18:24 on 93/09/30 GMT (by RAGAN at AUSVM1)
:ndx.FILTER01 :abs.COMMON PROBLEM #13: Filtering, part 1 of 2
:key.filtering bridge
:QUESTION.
  How do I adjust filtering on the Connection Server so that the LAN traffic
  does not flood the slow async wire?
:ANSWER.

    ****************************************************************
    COMMON PROBLEM #13: Bridge Filtering, part 1 of 2
    ****************************************************************

    (Updated 1st usability concern, 9/30/93)

    ERROR MESSAGES:

       The RECEIVE modem light for the LAN Distance Connection Server
       workstation is ON most or all of the time.

       You cannot connect to your destination.

       You may get a "Domain not available." message.

    PROBLEM:

         If the LAN Distance Connection Server is located on a busy
         LAN with large volumes of LAN traffic, the LAN adapter will
         pass all LAN frames into the LAN Distance bridge.  The
         unfiltered bridge will attempt to pass this high volume
         traffic onto the (slower) WAN wire, flooding the LAN
         Distance connection.

    PHILOSOPHY:

         9600 bps WAN wires cannot handle heavy (8Mb) LAN traffic.
         Filtering is required if the LAN has many LAN-attached
         workstation with a lot of activity.

    SOLUTIONS:

    SOLUTION #1:

    Place the LAN Distance Connection Server workstation on a LAN
    segment with minimal LAN activity, i.e., fewer than four
    LAN-attached workstations.

    SOLUTION #2:

    If you place the LAN Distance Connection Server workstation in a
    production environment (i.e., large number of workstations and
    servers) you will need to filter the LAN traffic reaching the LAN
    Distance Connection Server workstation.

    1) Address filtering -- accepts or rejects LAN traffic from
       workstations based on their Network address.

    2) SAP filtering -- allows applications written to specified
       protocols to be filtered.

    3) NetBIOS Names -- filtering reduces broadcast storms from
       NetBIOS applications on your LAN.

    4) Bit mask -- advanced filtering to reduce specific Functional
       Destination Addresses.

    The most popular type of filtering is LAN source address
    filtering, which filters the network address for specific LAN
    workstations.  For example, you could allow LAN frames from only
    the IBM Domain Controller (Server) to cross the bridge to LAN
    Distance Remote workstations. WAN source address filtering
    accepts or discards specific network addresses from remote
    workstations.

    For example, you could allow WAN frames from only specific LAN
    Distance Remote workstations to pass over the LAN Distance bridge
    to the LAN.  All other workstations, even if they logon
    successfully to the LAN Distance Connection Server workstation,
    could not cross the LAN Distance bridge.

    You could further reduce LAN traffic over the LAN Distance bridge
    by filtering SAP information so that only the NetBIOS protocol
    could cross the LAN Distance bridge.  For example, if the IBM
    Domain Controller workstation also functioned as the TCP/IP and
    SNA controller you could set up filtering  to accept only the
    NetBIOS SAP.  The other protocols could not pass over the LAN
    Distance bridge. This is a partial list of SAP values for
    protocols&colon.

         NetBIOS --- F0
         TCP/IP ---- AA
         SNA ------- 04 (and multiples of 4)
         Netware --- E0

    You could set up a NetBIOS names filter for the IBM Domain
    Controller. Since the IBM Domain Controller is a NetBIOS
    application, filtering on specific NetBIOS Names from the IBM
    Domain Controller would further decrease the LAN frames crossing
    the LAN Distance bridge.

    Most LAN Distance Connection Servers will require LAN Filtering.
    While WAN Filtering is not required, it can be used to prevent
    specific remote workstations from accessing LAN resources.

    BETA #2 -- DETAILS:

    Configure your LAN Distance Connection Server workstation bridge
    filters in the Settings notebook, the Bridge tab.

    USER INTERFACE PROBLEM #1:
   |     There is a USABILITY CONCERN in the 2nd beta (was not
   |     fixed in the final design).  Add filtering criteria to
         the list box.  After you have added the filter criteria, YOU
         MUST SELECT ALL CRITERIA IN THE LIST BOX THAT YOU HAVE
         ADDED.  This means that each filter criteria must have the
         black "selection" bar, any filter criterion without the
         selection bar will not be used to filter LAN traffic.
         Before closing the window, ensure the filter criteria are
         selected.

    USER INTERFACE PROBLEM #2:
         Another usability conern with the LAN Distance product (not
         completely fixed in the final design) is that if you
         configure filter criteria and even select it in the above
         problem, the LOAD BRIDGE SUPPORT check box at the top of the
         first page must be checked for the filter criteria to be
         active.

    FUNCTIONAL PROBLEM:
         There is a problem that currently only 10 filter criteria
         can be  entered in the Bridge tab.  This problem is fixed in
         the final product.  For the second beta, the work around is
         to edit \IBMCOM\PROTOCOL.INI.  Copy the 10 entries that you
         have already configured (completed earlier in Settings,
         Bridge tab) and place the copied lines directly below the
         existing entries and modify these new entries manually.

    FUNCTIONAL PROBLEM:
         NetBIOS names filtering is not working in the 2nd beta. This
         problem is being fixed in the final product.

    ETHERNET FILTERING:
         Ethernet filtering is working in the final design, however,
         the 2nd beta will support Ethernet filtering only through
         following the steps detailed in Common Problem #14.

    RECOMMENDATIONS:
         Minimize as much as possible the amount of LAN traffic
         crossing the LAN Distance bridge by placing the Connection
         Server on a LAN segment with minimal LAN activity.   Install
         the fix modules below for 2nd beta to resolve a number of
         filtering bugs.

    continue for fix modules... part 2 of 2
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 14:46:55 on 93/09/27 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 23:57:54 on 93/11/12 GMT (by RAGAN at AUSVM1)
:ndx.FILTER02 :abs.COMMON PROBLEM #13: Filtering, part 2 of 2
:key.filtering bridge
:QUESTION.
  How do I adjust filtering on the Connection Server so that the LAN traffic
  does not flood the slow async wire?
:ANSWER.

    ****************************************************************
    COMMON PROBLEM #13: Bridge Filtering, part 2 of 2
    ****************************************************************

    (Updated 2nd usability concern, 9/27/93)

    continued from part 1 of 2...

    FIX MODULES: (not needed for the 3rd beta or GA code)

    NETBIOS NAMES FILTERING

    Once you download the BRIDGE modules and place them in their
    respective subdirectories, you can use the wildcard feature
    for NetBIOS Names filtering.   Follow the steps and examples
    below:

     Open as Settings
     Select Bridge tab
     Address page
     Insure the LOAD BRIDGE SUPPORT check box is checked
     Page forward to "LAN Segment Filter Criteria"
     Select Add
     Select the NetBIOS tab
     Select Add

    Enter a NetBIOS name into the NetBIOS entry field:

    EXAMPLES:
    Place the fully NetBIOS name in the NetBIOS entry field:
          AUSN001100000000
    In this example, only the NetBIOS name AUSN001100000000 will be
    used as filter criteria.

    With wild card filtering, place the first characters of the
    NetBIOS Name in the entry field.  All trailing characters are
    omitted:
          AUS
    In this example, all addresses starting with the value AUS will
    be used as filter criteria.

    Rick Ragan,  IBM Austin, TX
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 00:12:50 on 93/11/03 GMT (by RAGAN at AUSVM1)
:ndx.CONN0001 :abs.Common Problem #15: Network Address for other Connection Ser
:key.Connection Servers
:QUESTION.
  How can I get more information about the extraneous Connection Servers
  that appear in my Workstations window?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #15: Network Address for other Connection Servers
  ****************************************************************

  PROBLEM:
  Other LAN Distance Connection Server workstations may appear in
  your Workstations window.  If security is enabled on these
  Connection Servers and you cannot perform an Open as Settings on
  them, how do you find more information about them?

  BACKGROUND:
  The LAN Distance development team is considering the function for
  a future release to allow you to keep unwanted LAN Distance
  Connection Servers from displaying in your Workstations window.

  Until that function is available, these steps can show you the
  Network Address of other Connection Servers.  You can consult
  your LAN Administration for the physical location of each Network
  Address.  However, placing these Network Address into your LAN
  Distance's Bridge's Filter Criteria will not prevent these
  Connection Servers from displaying in the Workstation's window.
  There is no current technique available to keep unwanted
  Connection Servers from appearing in the Workstation's window.

  PARTIAL SOLUTION:
  Follow these steps to discover the Network adapter address of the
  other Connection Servers appearing in your LAN Distance
  Connection Server Workstations window.

  Once you have the Network Adapter address, you can use the filter
  criteria to filter any LAN frames to your workstation from these
  unidentified Connection Servers.  However, the Connection Server
  icons will still appear in your Workstations window.  If you have
  a tool that can send messages to a specific Network Adapter
  address, then you may be able to discover where the Connection
  Server is located (i.e., once you have the Network Adapter
  address, you are not guaranteed the location of the Connection
  Server).

  1) Stop LAN Distance
  2) From an OS/2 command prompt, type WCLRSNTB to start up the LAN
     Distance Tracing Notebook (without starting LAN Distance).
  3) Ignore the WCL0146 error message
  4) Select the Trace tab
  5) Select the following three items (use the Ctrl key plus mouse
     button #1 to select the second and the third items):
            WCL Data Received
            WCL Data Sent
            WCL Startup UI
  6) Select the "Start" pushbutton to start the trace, don't close
     the Tracking notebook.
  7) Start LAN Distance (wait for all the other Connection Servers
     to appear in the Workstations window).
  8) In the Tracking notebook, select the "Stop" pushbutton.
  9) Enter a file name to copy the contents of the Trace into,
     e.g., C:\WHERE.ASC
  10) Select the "Copy" pushbutton, Select OK to the message about
      copying the trace into the file.
  11) Close the Tracking Notebook.
  12) Use an editor like EPM to view and search the file:
      EPM C:\WHERE.ASC
  13) Search for the string:
       OBJ STRUC
  14) There may be multiple instances of this string.  Each
      instance is another Connection Server in your Workstations
      window.  Each instance will look like this:

  Event--->Startup UI         11020313P/T=0029/0001   17:28:40.50
  sumainuf: obj struc
      00000000 00000000 00000000 00000000      <................>
      00000000 01004D59 574F524B 53544154      <......MYWORKSTAT>
      494F4E00 00000044 45534352 49505449      <ION....DESCRIPTI>
      4F4E204F 46204D59 20574F52 4B535441      <ON OF MY WORKSTA>
      54494F4E 00000000 00000000 00000000      <TION............>
      00000000 00313030 30354141 43333946      <.....10006BBC39F>
      30000000 00000000 00000000 00414300      <0............AC.>
      D8018A16 02000000                        <Q.......        >

  15) Count six lines down on the right-hand side and starting on
      the sixth line (and one character on the seventh line) you
      will see the 12 digit number that is that Connection Server's
      Network Address. The network address for the example is:
         10006BBC39F0

  16) You can use OS2PING to identify on which LAN Segment that
      Connection Server is located.

  17) As of this writing, I know of no way to send a message to
      that Network Address.  If you require the location of that
      Connection Server, contact your company's LAN Administration
      to see if they have a list of the locations of each Network
      Address.
  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 00:16:05 on 93/11/03 GMT (by RAGAN at AUSVM1)
:ndx.ETHERNET :abs.Common Problem #16: Ethernet cannot be selected
:key.Ethernet
:QUESTION.
  I am at the Address tab, but only Token Ring is availabe on the LAN type
  entry field, what can I do to get Ethernet?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #16: Ethernet cannot be selected
  ****************************************************************

  PROBLEM:
  You Open as Settings, select the Address tab,
  pull-down the "LAN Type" entry field, see only
  Token Ring adapter.

  You wonder how do you get Ethernet support?

  BACKGROUND:
  OS/2 Workplace Shell uses the concepts of pull-down entry fields.
  Often these fields can be scrolled once they are pulled-down.
  This entry field is not designed well, it should pull-down with
  at least two lines (Token Ring and Ethernet) showing.  We plan to
  fix this in the next release.

  SOLUTION:
  1) Open as Settings
  2) Select the Address tab
  3) Pull down the "LAN type" entry field Notice the Token Ring
     line below the entry field
  4) Notice the up and down arrows to the extreme right of the now
     visible Token Ring pull-down.
  5) Click once on the up arrow.
  6) Select Ethernet (click once on Ethernet).
  7) Select the Ethernet adapter from the "Ethernet card" entry
     field now available.
  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 23:04:38 on 93/12/07 GMT (by RAGAN at AUSVM1)
:ndx.MODEM000 :abs.SUPPORTED MODEMS: Updated listing of newly supported modems
:key.Modems LAN Distance
:QUESTION.
  The Advanced Guide for LAN Distance, Appendix A lists the modems that
  LAN Distance shipped with.  What new modems does LAN Distance support?
:ANSWER.

  SUBJECT: LAN Distance Modems
     DATE: December 2, 1993

  The LAN Distance product development team is dedicated to
  supporting as many modems as possible.

  The following new modem types (PIF files) are available for use
  by LAN Distance customers.  You can request these new modem types
  as a binary self-extracting EXE file (download in binary, place in
  \WAL subdirectory, type the command MODEMS at the OS/2 command
  prompt, and use Settings to Assign the new modem to a port):

  IBM:
  REMOTE FORUM
  VM REQUEST:  REQUEST MODEMS FROM BETASRUS AT AUSVM1

    Modem                                           PIF File
    ---------------------------                    ------------
  --older--
    Zenith 2000 Series Modem                        ZEN2000.PIF
    Intel 14.4EX Modem                              INT144EX.PIF
    Intel SatisFAXtion Modem/400                    INTFAX4.PIF
    Intel SatisFAXtion Modem/400e                   INTFAX4E.PIF
    USRobotics WorldPort 9600 Modem                 USRWPRT9.PIF
    Digicom Eagle Plus V.32 Modem                   EAGLEP.PIF      (1)
    IBM Microelectronics 14.4/14.4 Data/Fax
                          (PCMCIA) Modem            IBMTORON.PIF    (3)
  --New--
    Complete PC 14400 TurboModem                    COMPLETE.PIF
    Megahertz XJ1144FM PCMCIA Data/Fax Modem        MH144PCM.PIF    (2)
    Megahertz XJ196FM PCMCIA Data/Fax Modem         MH96PCM.PIF     (2)
    Apex PCMCIA Fax/Modem IBP-1414                  APEXPCM.PIF     (1) (2)
    Intel PCFM7600 14.4/14.4 External Modem         INPCFM76.PIF    (1)
    ViVa 14.4/FAX Modem                             VIVA144.PIF     (1)
    Apex Freedom 14/96 Data/Fax Laptop Modem        APEX1496.PIF
    GVC FM-144V External Fax Modem                  GVCFM144.PIF
    GVC SM-96 External Modem                        GVCSM96.PIF

  (1) Customer generated (not generated in the LAN Distance Development lab).

  (2) PCMCIA Modem.  Must have OS/2 Card and Socket Services
      (available from modem manufacturer) to run on OS/2 LAN Distance.

  (3) There is a bug in Device Driver of this modem. We are working with
      IBM Toronto to tell our customers how to get this fix and will append
      the solution (to get the fix in their code) to the LAN Distance forums.

  Please let us know through the forums which modems you would like
  for us to consider supporting for the LAN Distance products.

  Periodically, the IBM LAN Distance Development team will add
  modems types to this list, and place the corresponding PIF files
  on this forum.

  In an effort to distribute the widest variety of modem types, the
  LAN Distance Development team will also include new modem types
  developed and verified by our customers.  These modem types will
  be labeled above.  While we have confidence they will work with
  LAN Distance, these modem types have not been officially certified
  in the LAN Distance modem lab.

  Your feedback to our LAN Distance team is essential.  Please
  report any modem problems you encounter through the Forums.
  Typical modem errors for LAN Distance include (WCL0221, WCL0336,
  and spontaneous disconnections).  We are also interested in your
  modem successes.  We encourage you to try any modem type with any
  modem, or develop a new modem type for your modem hardware.  Let
  us know how your new modem type works, we would like to include
  them in the LAN Distance product!

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 16:15:38 on 94/01/10 GMT (by RAGAN at AUSVM1)
:ndx.MS000001 :abs.COMMON PROBLEM #17: (MS Windows client only) Traps & WCL0321
:key.Traps MS Microsoft client
:QUESTION.
  The MS Windows Beta for LAN Distance has a number of traps, how do I
  get fixes for these problems?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #17: (MS Windows client only) Traps & WCL0321
  ****************************************************************

  PROBLEMS:

  TRAPS:
  After starting the LAN Distance Windows BETA the next step
  usually is to bring up the settings notebook. On certain machines
  a trap would occur when the user selected the PHONE BOOK tab or
  attempted to enter modems or ports. This trap only occurred on
  certain machines but when it did occur it occurred regularly.

  These files also fix a number of other unspecified traps.

  WCL0321 - CANNOT DIAL FOR LEASED LINES:
  Can start LAN Distance, however, when you try to dial a leased
  line, you will get a WCL0321 error message.  You would find
  multiple bearer capability lines in the WCLDIAL.CXD file.
  Add this fix, re-configure in Settings (or hand edit the file
  \WAL\WCLDIAL.CDX, locate the section for the permanent outgoing
  call directory entry, then remove the first Subfield Bearer
  Capability line), then dial.

  GRAPHICAL USER INTERFACE:
  These files modify the graphical user interface slightly to add
  some usability features.

  SOLUTION:

  From the VM Command prompt, type:
      REQUEST LDPR17 FROM BETASRUS AT AUSVM1

  These are the steps to install the LDPR17 package when you receive
  if from your VM reader:

  1) Stop IBM LAN Distance MS Windows client.

  2) Back up these files, rename them to something like:
            CFMAIN.OLD
            WCLCFG.OLD

  3) Download the LDPR17.EXE file file in binary

  4) At the command prompt, unzip this self-extracting file using
       the command:
            LDPR17

  5) You should now have three files:
            CFMAIN.EXE
            WCLCFG.MSG
            LDPR17.TXT -- this file you are now reading

  4) Place the two files (CFMAIN & WCLCFG) into the \WAL
       subdirectory (for the MS Windows client only).

  5) Start LAN Distance, MS Windows client.

  <end of text>
:from.Rick Ragan, IBM Austin.

----- REMOTE ANSWERS appended at 16:17:58 on 94/01/10 GMT (by RAGAN at AUSVM1)
:ndx.PCMCIA01 :abs.COMMON PROBLEM #18: README changes for PCMCIA, section 2.6
:key.PCMCIA README
:QUESTION.
  How do I get the PCMCIA modems to work with LAN Distance, the README
  file is not correct?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #18: README changes for PCMCIA, section 2.6
  ****************************************************************

  PROBLEMS:

  The README file shipped with IBM LAN Distance, version 1.0 has an error in
  Section 2.6 - Using the LAN Distance Remote product with IBM PCMCIA adapters.

  The file: ICPMU02.SYS should be ICRMU02.SYS.

  SOLUTION:

  The lines where this error occur are:

  INCORRECT:    Name = $ICPMOS2.SYS IBMTOKCS.OS2 IBM2SS02.SYS ICPMU02.SYS
  CORRECT:      Name = $ICPMOS2.SYS IBMTOKCS.OS2 IBM2SS02.SYS ICRMU02.SYS
  CHANGE is to one character>                                   |

  ----------------------------------------------------------------------

  Below is the corrected version of Section 2.6 with a clarified set of
  DEVICE= lines, corrections are marked with an "*".

  ----------------------------------------------------------------------

  2.6 - Using the LAN Distance Remote product with IBM PCMCIA adapters

        If you install the LAN Distance Remote product on a LAN-attached
        workstation, the Shuttle function automatically will enable you to
        switch from the LAN-attached environment to the standalone environment
        where the LAN Distance Remote product will function.

        If your LAN-attached workstation contains an IBM PCMCIA Token-Ring
        Adapter, you must complete Steps 1 & 3 after installing the LAN Distance
        product and before you shuttle to the standalone environment.

        1. Edit the \IBMCOM\MACS\IBMTOKCS.NIF file.
           a) Find the ìFILE┘ section.
           b) On the "Name =" line, add all required device driver names in
  *           order.  For example, the IBM ThinkPad requires this order:
  *           DEVICE=x:\XXX\$ICPMOS2.SYS
  *           DEVICE=x:\IBMTOKCS.OS2
  *           DEVICE=x:\IBM2SS02.SYS
  *           DEVICE=x:\ICRMU02.SYS

        If your LAN-attached workstation contains a PCMCIA asynchronous modem
        adapter, you must complete Steps 2 & 3 after installing the LAN Distance
        product and before you shuttle to the standalone environment.

        2. Edit the \IBMCOM\MACS\PDFH.NIF file.
           a) Find the ìFILE┘ section.
           b) On the "Name =" line add all required device driver names in
  *           order.  For example, the IBM ThinkPad requires this order:
  *           DEVICE=x:\$ICPMOS2.SYS
  *           DEVICE=x:\PDFH.OS2
  *           DEVICE=x:\IBM2SS02.SYS
  *           DEVICE=x:\ICRMU02.SYS

        3. Copy all of the device drivers mentioned in the "Name =" line
           to the \IBMCOM\MACS subdirectory if they are not already there.

        The required device drivers are described in the PCMCIA Adapter
        documentation and included on the Adapter's accompanying diskette.
        The device driver names are specific to each brand of adapter.

        The \IBMCOM\MACS\PDFH.NIF file is shipped, installed, and required
        by the LAN Distance product. PDFH.OS2 is its associated device driver.

        NOTE: this editing technique can be used for any multiple device drivers
        adapter requiring a particular order in CONFIG.SYS.

  <end of file>
:from.Rick Ragan, IBM Austin.

----- REMOTE ANSWERS appended at 16:20:47 on 94/01/10 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 14:59:30 on 94/01/14 GMT (by RAGAN at AUSVM1)
:ndx.FILTER01 :abs.COMMON PROBLEM #19: AUTOMATIC Filtering
:key.Filtering Line-dropping
:QUESTION.
  My LAN Distance connection drops from time to time, or I cannot access
  my domain, or I think filter criteria is difficult to set up, what can
  I do to make filtering easier?
:ANSWER.

  ****************************************************************
  COMMON PROBLEM #19: AUTOMATIC Filtering
  ****************************************************************

  | improvements to Automatic Filtering, new IBMFLTR.OS2 file

  FILTER PROBLEMS:
  While Filtering works correctly in the Shipped version of IBM LAN
  Distance (and in the 3rd beta), the LAN Distance Development team
  has created a new type of filtering that can be used in place of
  (or along with) the earlier Filter Criteria.

  We call this new type of filtering: Automatic Filtering.  It is a
  one-step solution to what was a demanding task of finding Address
  Filters, SAP filters, NetBIOS Names, or using the Bit mask.

  Automatic Filtering is designed to work with small LANs, with
  complex LANs, with Token-Ring LANs, and with Ethernet LANs.

  Why do you need filtering at all?

  Filtering keeps the high-volume LAN traffic from flooding the
  slower async WAN wire.  Symptoms include the LAN Distance
  Connection Server's modem's TD (transmit or send) light is on
  most of the time, or your connection drops a different times
  (busy times) of the day.

  PHILOSOPHY:
  When the LAN Distance Remote workstation dials into the LAN
  Distance Connection Server, the application using the LAN
  Distance Remote product (for instance, the IBM LAN Requester)
  sends out LAN traffic containing a destination names to the IBM
  LAN Server. Similar techniques are automatically applied to
  applications using other protocols (e.g., TCP/IP).

  The new Automatic Filtering in LAN Distance will notice this
  address and automatically make a list of the destination names
  for each Remote workstation.  Only the LAN traffic from those LAN
  workstations (IBM LAN Servers) responding to the LAN Distance
  Remote workstations will be transmitted back over the WAN wire to
  the Remote workstations.  The other LAN activity is automatically
  filtered under the covers, without having to set any filter
  criteria.  This filtering is now on a per-port basis, so the
  filtering is done for each Remote workstation, not (as LAN
  Distance 1.0 had in the past) for all Remote workstations dialing
  into a Connection Server.

  RESTRICTIONS:
       Automatic Filtering works well for most environments.
       If you follow this sequence, the restrictions below may not
       apply:
            Step 1) Start LAN Distance and connect
            Step 2) Start LAN client (e.g., IBM LAN Requester)
            Step 3) Logon onto the LAN.
       If the above steps are not followed in sequence, then the
       following exceptions may exist when using IBM LAN Server:
       1) Currently, IBM LAN Server functions may not work when run
            on the LAN Distance Remote workstation (i.e., IBM LAN
            Server on LAN Distance Remote) when using Automatic
            Filtering.
       2) Currently, Automatic Filtering will not allow the LAN
            Distance Connection Server to forward Netbios Broadcast
            Datagrams from the LAN to the Remote workstation.  For
            example: If you use the NET SEND * command with IBM LAN
            Server or Requester (e.g., NET SEND * Hello World) from
            a LAN workstation, the LAN Distance Remote workstations
            may not receive this message if the LAN Distance
            Connection Server is using Automatic Filtering.
       3) Currently, Automatic Filtering *may* prevent a LAN
            Distance Remote workstation using IBM LAN Server's
            Administrative functions in some LAN environments.  For
            example, in the Statistics and Logs section you may not
            see all LAN Servers on the Domain (e.g., Action >
            Statistics & Logs > Statistics, NET function).

  SOLUTION:
  All of these changes are made strictly at the LAN Distance
  Connection Server, no changes are made to the Remote workstation.

  While the next release of LAN Distance may contain Automatic
  Filtering and the selection of Automatic Filtering would be a
  single step (select the check box that says: "Automatic
  Filtering"), the steps below are slightly involved due to the
  fact that we are placing this new function into a shipped product
  that was not originally designed for this function.
  WARNING: There is a chance that adding this new function into
       your IBM LAN Distance software may disrupt the function of
       LAN Distance.  If this occurs, please report this problem
       via the forums and follow Steps 17-19 to remove Automatic
       Filters and to restore your Filter Criteria.

  If you have configured the LAN Distance bridge to have Filter
  Criteria (Bridge tab), you should turn these filters off so that
  you can test the power and ease at which the Automatic Filters
  work:

To request the binary file over VM, please type at the VM command line:
    REQUEST LDPR19 FROM BETASRUS AT AUSVM1

  Turn off existing Filter Criteria:
  If you have defined LAN Distance Bridge Filter Criteria, you can
  disable this type of filtering with the following steps (1-7):
       1) Start LAN Distance
       2) Open as Settings
       3) Select the Bridge tab
       4) De-select the Filter Criteria item in the "Select Filter
            Criteria" list box (on page 2 of 3).  You do this by
            using the space bar on your keyboard.  Once
            de-selected, the item will not have a black bar through
            it.
       5) Close Settings
       6) You will receive a Message: "You have defined Bridge
            Filter criteria..." This message is asking if you are
            aware that you have created Filter Criteria, but do not
            have the filtering criteria selected.  You do not need
            Filter Criteria with Automatic Filtering (you can go
            back and select this if you wish after you have seen
            how well Automatic Filtering works.  Automatic
            Filtering and Filter Criteria can work at the same
            time).
                 Select the "Cancel" pushbutton
            so that you will *not* activate any filter criteria.
            You will get a message asking "Do you want to save the
            Settings notebook values?"
                 select the "Yes" pushbutton.
       7) Stop the LAN Distance Connection Server.

  Download the LDPR19.EXE file:
       8) Download LDPR19.EXE in binary into a \TEMP subdirectory.
       9) At the OS/2 command prompt, unzip this self-extracting
            file with the following command:
                 LDPR19
       10) You should now have three files:
                 IBMFLTR.OS2      CRC value: X'A0CA'
                 MACFH.OS2        CRC value: X'C932'
                 LDPR19.TXT  <--- This file you are now reading.

  Modifying the LAN Distance files:
       11) Copy IBMFLTR.OS2 (provided above) to the
            x:\WAL directory.
       12) Backup the shipped file named MACFH.OS2 in the
            x:\IBMCOM\MACS directory, with the command:
                 COPY MACFH.OS2 MACFH.OLD
       13) Copy MACFH.OS2 (provide above) to the
            x:\IBMCOM\MACS directory.
       14) Using the System Editor, add the following DEVICE line
            to \CONFIG.SYS.  The DEVICE line can be placed at the
            very end of CONFIG.SYS.  The "x" is the drive where you
            have installed LAN Distance, replace this letter with
            the letter that applies to your workstation.
             WARNING: do not edit this file unless you are familiar
             with editing system files.
                      DEVICE=x:\WAL\IBMFLTR.OS2
       15) Shutdown all other applications and re-start your
            workstation.
       16) When the LAN Distance Connection Server is started and a
            LAN Distance Remote workstation dials in, Automatic
            Filters will be working.

  How to stop Automatic Filtering and return to using only the
  Filter Criteria in LAN Distance, version 1.0:
       17) Using the System Editor, remove the DEVICE line
            in \CONFIG.SYS.  You can do this by either deleting the
            DEVICE line, or by placing the three letters REM in
            front of this line.
              WARNING: do not edit this file unless you are
              familiar with editing system files.
                 Change:   DEVICE=x:\WAL\IBMFLTR.OS2
                 To:       REM DEVICE=x:\WAL\IBMFLTR.OS2
       18) (Optional) Restore the shipped file named MACFH.OS2 to
            x:\IBMCOM\MACS directory, with the command:
                 COPY MACFH.OLD MACFH.OS2
       19) Shutdown and restart your workstation.
  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 16:22:55 on 94/01/10 GMT (by RAGAN at AUSVM1)
:ndx.CM200001 :abs.Common Problem #20: Communications Manager/2, versions 1.01
:key.Communications Manager /2
:QUESTION.
  What can I do to get Communications Manager /2 1.01 to work with
  LAN Distance?
:ANSWER.

  *****************************************************************
  Common Problem #20: Communications Manager/2, versions 1.01
  *****************************************************************

  | dropped the CM/2 2.0 version (does not exist yet)

  SYMPTOMS:

  1) Communications Manager/2, version 1.01 may not work
     over LAN Distance even though Communications Manager/2 1.0
     did.  You may receive the COMM695 error.

                      - AND -

  2) OS2PING works for the -SR option, but not for the -R option.

  PHILOSOPHY:

  Communications Manager/2, version 1.01 has changed their LAN
  broadcast frames from Source Route to General Broadcast.  The
  advantage is that any hardware bridges that use to reject all
  Source Routing frame will now pass CM/2 frames.  The disadvantage
  is that bridges (both LAN Distance's software bridge and your
  LAN's hardware bridge) may reject General Broadcasts information
  if the hop count is too low.

  By moving from CM/2 1.0 to CM/2 1.01, your LAN
  Distance Connection Server's hop count may be too low or your
  hardware bridges hop counts may be too low to pass CM/2 1.01
  General Broadcast frames.

  SOLUTION:
  If CM/2 1.01 does not work with LAN Distance, you will have to
  increase your LAN Distance hop count, or even increase the hop
  count for your hardware bridges.  Here is what you should do...

  Use OS2PING to ping the 3270 Controller destination address.

  If the command:

   OS2PING /A=123456789ABC -SR -R

  returns, but the command

   OS2PING /A=123456789ABC -R

  does not return, then increase your LAN Distance Connection
  Server's (Bridge tab) hop count based upon the number of bridges
  displayed in your -SR information (count each ---> symbol as a
  bridge, which is one hop).

  (NOTE: -SR creates a Source Route frame, while the absence of -SR
  creates a General Broadcast frame.  The -R value is to display
  the information.)

  If after increasing the LAN Distance hop count to the correct
  value (or higher), and the OS2PING command with the -R value
  still does not return (and CM/2 still does not work), either move
  the LAN Distance Connection Server closer to the 3270 Controller
  (on a closer LAN Segment) or contact your LAN Administrator to
  increase the hop count of your hardware bridges.

  ---------------------------------------------------------------

  Optional Notes:

                 IF OS2PING DOES NOT RETURN AT ALL:

  If the command:

   OS2PING /A=123456789ABC -SR -R

  does not return, then check your 3270 Destination Address.  With
  busy LANs, you can increase your wait time by adding the -w=60 to
  the end of the command (60 seconds can be changed to any value).

   OS2PING /A=123456789ABC -SR -R -W=60

      USE ONLY -R TO GET CONN SERVER'S LAN SEGMENT RING NUMBER:

  The -SR option may invert your LAN information.  If you are
  trying to determine the LAN Segment Ring Number for the LAN
  Segment on which your Connection Server is located (in order to
  configure your LAN Distance Connection Server, Bridge tab), then
  use only the -R option (see the LAN Distance Adv Guide, Appendix
  E on OS2PING for more information).  The -SR option may reverse
  the order of the LAN Segments and bridges.  The -SR option is
  useful (as stated above) to determine if your version of CM/2 is
  using Source Route or General Broadcast frames.

  <end of file>
:from.Rick Ragan, IBM Austin.

----- REMOTE ANSWERS appended at 14:35:38 on 94/01/28 GMT (by RAGAN at AUSVM1)
:ndx.0WCL0349 :abs.Common Problem #21: Persistent WCL0349 Returned
:key.NetBios Conversation has been lost
:QUESTION.
  What do I do if I get the WCL0349 erro message: NetBios Conversation has
  been lost, and all calls drop?
:ANSWER.

  *****************************************************************
  Common Problem #21: Persistent WCL0349 Errors Returned
  *****************************************************************

  SYMPTOMS:

  With a number of OS/2 LAN Distance Remote Workstations connected
  to a LAN Distance Connection Server, all calls may suddenly drop
  with the WCL0349 - "NETBIOS CONVERSATION HAS BEEN LOST" message
  displayed at the remote. Subsequent attempts to redial fail with
  the WCL0310 or WCL0349 messages. Only rebooting the server will
  fix the problem.

  BACKGROUND:

  LAN Distance uses Netbios during the call establishment and
  hangup phases. Under high usage conditions a memory leak can
  occur, depleting LAN Distance's internal buffers. Once depleted
  incorrect buffer lengths are reported to Netbios, resulting in
  the reported error. This memory leak occurs only when calls drop
  unexpectedly. The most likely environments for this to occur are
  when noisy lines are in use, or when shutting down the Remote
  Workstation with calls still connected.

  SOLUTION:

  Apply the fix module, WCLCPSRD.DLL to the OS/2 LAN Distance
  Server or Remote Workstation experiencing the problem.

  To receive a copy of the patches contact IBM Service at
  1-800-992-4777 and reference APAR number IC06610.

  APAR: IC06610

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 14:38:37 on 94/01/28 GMT (by RAGAN at AUSVM1)
:ndx.TRAP0001 :abs.Common Problem #22: Conn Server traps during logon/off
:key.Call established Trap
:QUESTION.
  What do I do if when I logon to my LAN Distance Conn Server I get a trap
  error when the call is established or hung up?
:ANSWER.

  *****************************************************************
  Common Problem #22: Server Traps during Logon/Logoff
  *****************************************************************

  SYMPTOMS:

  When logging on or off of a LAN Distance Server from an OS/2 LAN
  Distance Remote as part of call establishment or hangup, the
  server may trap.

  SOLUTION:

  Apply the fix module, WCBSEC.DLL to the LAN Distance Server or
  OS/2 Remote Workstation experiencing the problem.

  To receive a copy of the patches contact IBM Service at
  1-800-992-4777 and reference APAR number IC06607.

  APAR: IC06607

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 14:41:18 on 94/01/28 GMT (by RAGAN at AUSVM1)
:ndx.0SYS3175 :abs.Common Problem #23: SYS3175 Message during shutdown
:key.SYS3175 close main container
:QUESTION.
  What do I do if I get a SYS3175 message when I try to close the main
  container, also I get the WCL0530 message?
:ANSWER.

  *****************************************************************
  Common Problem #23: SYS3175 Message during shutdown
  *****************************************************************

  SYMPTOMS:

  When closing the main container of LAN Distance (OS/2 Remote or
  Connection Server), you may sometimes get a SYS3175 Message
  displayed. Subsequent attempts to restart LAN Distance fail with
  the message:
    WCL0530E: The LAN Distance product did not start in the time
     allowed.
  This problem can only be fixed by rebooting.

  SOLUTION:

  Apply the fix modules, WCLCPME.DLL and WCLCPMER.EXE to the LAN
  Distance Server or OS/2 Remote Workstation experiencing the
  problem.

  To receive a copy of the patches contact IBM Service at
  1-800-992-4777 and reference APAR number IC06608.

  APAR: IC06608

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 14:43:53 on 94/01/28 GMT (by RAGAN at AUSVM1)
:ndx.DRIVE001 :abs.Common Problem #24: SYS3175 Message during startup from D:
:key.SYS3175 Drive D: Startup
:QUESTION.
  What do I do if I get a SYS3175 message from my OS/2 LAN Distance
  workstation when LAN Distance is installed on a drive other than C:?
:ANSWER.

  *****************************************************************
  Common Problem #24: SYS3175 Message during startup from D: drive
  *****************************************************************

  SYMPTOMS:

  On an OS/2 workstation, if LAN Distance is installed and started
  from any drive other than C:, a SYS3175 message may be displayed
  when LAN Distance is started.

  SOLUTION:

  Apply the fix modules, WCLCPME.DLL and WCLCPMER.EXE to the OS/2
  LAN Distance Server or OS/2 Remote workstation experiencing the
  problem.

  To receive a copy of the patches contact IBM Service at
  1-800-992-4777 and reference APAR number IC06471.

  APAR: IC06471

  Rick Ragan,  Austin, TX

  <end of file>
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 16:47:06 on 94/01/28 GMT (by RAGAN at AUSVM1)
:ndx.DLR00001 :abs.Common Problem #25: (MS Windows only) DOS LAN Requester
:key.DOS LAN Requester
:QUESTION.
  For the MS Windows client, I cannot logon usign the DOS LAN Requester,
  what do I do?
:ANSWER.

  *****************************************************************
  Common Problem #25: (MS Windows) DOS LAN Requester
  *****************************************************************

  SYMPTOMS:

  MS Windows client of LAN Distance only:

  DOS LAN Requester cannot logon to the Domain Controller using
  DOS LAN Requester 2.0 or 3.0.

  SOLUTION:

  The DOS LAN Requester code (LS 2.0 and LS 3.0) has a bug that
  (incorrectly) defaults the Mail Slot number to 0 (zero).
  Corrective Service Diskette (CSD) 7003 will fix this problem.

  If you cannot get CSD 7003 easily, you can add the following
  parameter to the x:\DOSLAN\DOSLAN.INI file:

       /NMS:3

  This will specify 3 rather than the incorrect default of 0 as the
  correct Number for the Mail Slot.

  Rick Ragan,  Austin, TX
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 16:51:19 on 94/01/28 GMT (by RAGAN at AUSVM1)
:ndx.TCPIP001 :abs.Common Problem #26: (MS Windows only) TCP/IP fails
:key.TCP/IP
:QUESTION.
  For MS Windows client, I cannot get TPC/IP to work, what do I do?
:ANSWER.

  *****************************************************************
  Common Problem #26: (MS Windows) TCP/IP fails
  *****************************************************************

  SYMPTOMS:

  For the MS Windows client of LAN Distance only:

  TCP/IP fails to work.

  SOLUTION:

  From the VM command line, type:
    REQUEST LDPR26 FROM BETASRUS AT AUSVM1

  1) Download the file LDPR26 EXEBIN in binary.

  2) Type at the DOS command prompt:
       LDPR26
     this will produce:
         LDPR26 TXT -- what your are now reading
         PROTMAN.DOS - the binary file.  CRC=X'5D02'

  3) Back up the file x:\WAL\PROTMAN.DOS
       (COPY PROTMAN.DOS PROTMAN.OLD)

  4) Copy the new file to x:\WAL\PROTMAN.DOS.

  5) In the file CONFIG.SYS, move the statement
       DEVICE = x:\TCPIP\BIN\DOSTCP.SYS
     to the last line of this file after all other DEVICE and
     DEVICHIGH statements.

  6) Make sure you have run TCPSTART.BAT before starting MS
     Windows, place this command in your AUTOEXEC.BAT

  7) Re-start your workstation.

  Rick Ragan,  Austin, TX
:from.Rick Ragan, IBM Austin

----- REMOTE ANSWERS appended at 23:48:38 on 94/02/07 GMT (by RAGAN at AUSVM1)
..... REMOTE ANSWERS modified at 17:22:25 on 94/02/09 GMT (by RAGAN at AUSVM1)
:ndx.SHUTTLE1 :abs.COMMON PROBLEM #25: Shuttle with PCMCIA adapters
:key.PCMCIA Shuttle
:QUESTION.
  What do I do if I cannot get my PCMCIA adapter to work with LAN Distance's
  shuttle function?
:ANSWER.

    *****************************************************************
    Common Problem #27: Shuttle produces incorrect config.sys with
                        PCMCIA adapters
    *****************************************************************

    SYMPTOMS:

    APAR: IC06532

    (1) Shuttle may change the order of some of the PCMCIA
        DEVICE= statements in config.sys.
    (2) Second, shuttle may lose a parameter on the PCMCIA socket services
        device driver (IBM2SS01.SYS) or on a PCMCIA modem device driver
        (ESTDFM.OS2).

    SOLUTION:

    ORDERING PROBLEMS:
    To fix the first problem (device ordering) perform the following
    steps:

    If you have an IBM PCMCIA Token-Ring Adapter perform step (1).

    (1) Edit the \IBMCOM\MACS\IBMTOKCS.NIF file.
        a) Find the FILE section.
        b) On the "Name =" line, add device drivers that are order
           dependent in their correct order.  This will differ
           from one machine model to another and it will differ
           depending on what version of Card and Socket Services
           you have.  Here's an example for how to edit the file
           for an IBM ThinkPad 750C:

           Name = IBMTOKCS.OS2 IBM2SS01.SYS ICRMU02.SYS

           This will result in these device drivers being added to the
           end of CONFIG.SYS in this order.

    If you have a PCMCIA modem, perform step (2).

    (2) Edit the \IBMCOM\MACS\PDFH.NIF file.
        a) Find the FILE section.
        b) On the "Name =" line, add device drivers that are order
           dependent in their correct order.
           The following is an example for the IBM PCMCIA and
           Megahurtz PCMCIA modems:

           Name = ESTDFM.OS2 PDFH.OS2 IBM2SS01.SYS ICRMU02.SYS

           This will result in these device drivers being added to the
           end of CONFIG.SYS in this order.

    (3) Copy all device drivers that you placed on the Name = line
        the above .NIF files to the \IBMCOM\MACS subdirectory.

    The required device drivers are described in your PCMCIA
    Adapter documentation and included on your Adapter's installation
    diskette.  The device driver names are specific to each
    brand of adapter.

    The \IBMCOM\MACS\PDFH.NIF file is shipped, installed, and
    required by the LAN Distance product.  PDFH.OS2 is its
    associated device driver.

    NOTE: This editing technique can be used for any multiple device
    drivers adapter requiring a particular order in CONFIG.SYS.

    MISSING PARAMETER PROBLEMS:
    Fix module, WCLSHUTL.DLL, has been made available to
    correct the problem. This fix is to be applied to all Remote
    Workstations experiencing the problem.

    This fix module will fix parameters lost for the IBM2SS01.SYS and
    ESTDFM.OS2 device drivers.

    NOTE: It is possible that shuttle may lose
    parameters for other device drivers depending on how you edit
    your IBMTOKCS.NIF and PDFH.NIF files to correct the ordering
    problem described above.  If you have edited one of these .NIF files
    and have had to place a different device driver requiring parameters
    on the NAME= line, you must perform the following so that the shuttle
    feature will maintain your parameters:

    (1) Edit the WCLLOCAL.INI file in your \WAL subdirectory.
        In the SHUTTLE section add two lines describing the name
        of your device driver and its parameter.  For example, if
        your SHUTTLE section looks like:

        SHUTTLE
           D1 = IBM2SS01.SYS
           P1 = /S0=1

        and you have a device driver named XYZ.OS2 that needs parameter
        /A, add the following lines so that your shuttle section looks like:

        SHUTTLE
           D1 = IBM2SS01.SYS
           P1 = /S0=1
           D2 = XYZ.OS2
           P2 = /A

    NOTE:  If you use LAPS to change your LAN protocol configuration, your
    parameters may be deleted again.  If so, simply use shuttle your
    LAN Distance remote workstation and the parameters will be restored.
    (Or edit your CONFIG.SYS.)  A LAPS fix will be available in the near
    future.

    To receive a copy of the patches contact IBM Service at 1-800-992-4777 and
    reference APAR number IC06532.