Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

802.2 Interface Pacing for Transmits

IP.com Disclosure Number: IPCOM000121905D
Original Publication Date: 1991-Oct-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 96K

Publishing Venue

IBM

Related People

Belscher, MS: AUTHOR

Abstract

A method was needed to solve the problem of how OS/2* applications written to the IBM 802.2 DLR interface should handle the situation of the remote entering and exiting a busy state. The importance of proper handling of the remote busy case was exhibited during testing for the OS/2 Extended Edition gateway testing. The LAN DLC code which is the Layer 3 code for SNA and written to the 802.2 DLR interface ran into problems in this handling. An architected solution was necessary to handle this situation. The possible result, if not handled properly, could not only affect that link but other active links since all the adapter handler's resources come out of one pool. The result would limit the resources for the other links and, in extreme cases, cause an overrun of the adapter handler resources. An 802.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 51% of the total text.

802.2 Interface Pacing for Transmits

      A method was needed to solve the problem of how OS/2*
applications written to the IBM 802.2 DLR interface should handle the
situation of the remote entering and exiting a busy state. The
importance of proper handling of the remote busy case was exhibited
during testing for the OS/2 Extended Edition gateway testing. The LAN
DLC code which is the Layer 3 code for SNA and written to the 802.2
DLR interface ran into problems in this handling. An architected
solution was necessary to handle this situation. The possible result,
if not handled properly, could not only affect that link but other
active links since all the adapter handler's resources come out of
one pool. The result would limit the resources for the other links
and, in extreme cases, cause an overrun of the adapter handler
resources. An 802.2 pacing mechanism was needed to handle the restart
of the link across the interface.

      This solution was derived for the LAN DLC code but can be
utilized for other 802.2 applications. LAN DLC due to internal
restrictions had to continue to transmit the adapter handler CCBs
(AHCBs) when the remote entered the busy state and allow them to
queue the data. The reasoning behind this is that we had no mechanism
of chaining AHCBs and, even if we could, we had a fixed number of
these AHCBs. The original design was to queue Communication Subsystem
CCBs (CSCBs) on adjacent lists. The problem was that these lists were
a fixed size and the CSCBs were also limited to a fixed number. If
the remote was busy we would set a flag not to transmit off this list
and the usual result would be an overrun of the list. If the size of
the list was increased, APPC would run out of CSCBs. At the time the
best solution, although it had some major drawbacks, was to disable
the lists and continue to transmit. The main reason for using this
solution was that it allowed LAN DLC to remain active for a longer
period of time while the remote station was busy.

      For the remote busy case to be handled properly, the LAN DLC
code had to chain AHCBs when the remote was busy. The restriction of
the fixed number of AHCBs was removed by placing the transmit I-frame
AHCB inside the DLC header of the frame to be transmitted and
allocating all other AHCBs by using the getframe verb of the APPC
frame manager.  This presents us with the problem of running unpaced
across the interface when the remote exits the...