BNS-2000 VCS Release 6.0 Build 91 Release Letter date

BNS-2000 VCS Release 6.0 Build 91 Release Letter date
subject:
BNS-2000 VCS Release 6.0 Build 91 Release Letter
date:
May 9, 2003
from:
BNS-2000 VCS Customer Support
1800Lucent8
Release Description
This letter contains a description of maintenance changes made in BNS-2000 VCS Release 6.0
Build 91.
THIS MAINTENANCE RELEASE OF BNS-2000 VCS REQUIRES A DATABASE
UPGRADE FOR ALL CUSTOMERS WHO ARE RUNNING BUILDS OF RELEASE 6.0 EARLIER THAN BUILD 66. PLEASE FOLLOW THE ATTACHED INSTRUCTIONS ENTITLED
"BNS-2000 VCS DATABASE UPGRADE".
As of January 1997, Lucent Technologies is merging Datakit II VCS and MPC15 into one
BNS-2000 hardware platform. The new name for Datakit II VCS is BNS-2000 VCS; the new
name for the MPC15 is BNS-2000 MPC. Ordering will be simplified through the use of one (1) "J"
drawing for initial orders. There will be different software for the BNS-2000 and BNS-2000 VCS
but one (1) BNS-2000 documentation set that will include the necessary information for the BNS2000, BNS-2000 VCS, and BNS-2000 MPC. Existing Datakit II VCS and BNS-2000 customers will
receive the new documentation set when they purchase upgrades.
The BNS-2000 hardware platform will consist of the following options:
•
BNS-2000. This is the BNS-2000 M1/M2 cabinet configuration supporting both low-speed
(M1) and high-speed (M2) modules. This configuration will require BNS-2000 software.
•
BNS-2000 VCS. This is the BNS-2000 VCS M1-only cabinet configuration supporting lowspeed (M1) modules. The M1 cabinet will contain clock/repeater modules as opposed to
CIM/CTRM modules contained in BNS-2000 M1 cabinets. M2 cabinets are not required. This
configuration requires BNS-2000 VCS/Datakit II VCS R6.0 software.
•
BNS-2000 MPC. This is the BNS-2000 MPC M1 Multipurpose Concentrator cabinet
configuration.
BNS-2000 Release 4.0 documentation will be updated to include information on the BNS-2000,
BNS-2000 VCS, and BNS-2000 MPC.
All BNS-2000 offerings described above are managed by StarKeeper II Network Management System (NMS). (When configuring BNS-2000 VCS, customers select "Datakit II VCS" as the
node option.)
BNS-2000 training courses will be updated to include information on the BNS-2000 VCS and
BNS-2000 MPC offerings.
Unless stated otherwise in this document, the modifications described within are compatible
with those issues of BNS-2000 VCS associated products (e.g., StarKeeper NMS, CommKit
Software) intended to support this version of the product (Release 6.0).
-2-
In all descriptions below, alarms are referred to by their unique id number (unid). This is consistent with the convention in the Data Networking Products Messages Reference.
1. DOWNLOADABLE MODULES VERSIONS
_________________________________________________________
BNS-2000 VCS RELEASE 6.0 DOWNLOADABLE MODULES 
_________________________________________________________



Downloadable Module
Version
_________________________________________________________



BSC HOST MODULE
_________________________________________________________
 bsch.6.0.68
 BSC TERM MODULE

 bsct.6.0.68
_________________________________________________________


CPMML MODULE
cpmml.6.0.68

_________________________________________________________


DKAP MODULE
 dkap.6.0.68
_________________________________________________________


 e1frm.6.0.68
CHANNELIZED FRM (E1) MODULE
_________________________________________________________



V.35 FRM MODULE
frm.6.0.68
_________________________________________________________

 HIGH SPEED CPMML MODULE


hscml.6.0.68
_________________________________________________________
 hsdkp.6.0.74
HIGH SPEED DKAP MODULE

_________________________________________________________

_________________________________________________________

LAN PROTOCOL MODULE
lpm.6.0.68




TRK-PQ MODULE
pwt.6.0.68
_________________________________________________________



SAMML MODULE
_________________________________________________________
 samml.6.0.68
 SDLC8 MODULE

 sdlc8.6.0.68
_________________________________________________________


CHANNELIZED FRM (T1) MODULE
t1frm.6.0.68
_________________________________________________________


_________________________________________________________

TSM8 MODULE
 tsm8.6.0.75


 tsmt1.6.0.68
HIGH SPEED TSM MODULE
_________________________________________________________


X.25 MODULE
xim.6.0.75

_________________________________________________________

 RS232 X.25P MODULE


xprr.6.0.83
_________________________________________________________
 xprv.6.0.83
V.35 X.25P MODULE
_________________________________________________________


When upgrading from earlier builds of Release 6.0, the boot of Release 6.0 Build 91 will only
cause a downloadable module (e.g., TSM8, SAM) to be loaded with new software if a software
change has been made to that module since the last build on the customer’s node. For example, if
a customer were running Build 49 on their node, and they upgraded the node to Build 50, only
downloadable modules that were changed in Build 50 would redownload with the new software.
In the above table, the version numbers of the modules for the current build are listed. The last
digits of the version number, those following the last ".", denote the build number. If the Frame
Relay Module (FRM) had a version number of frm.6.0.51, that would mean that the latest version
of that module was built in Build 51. This will result in the teardown of any existing circuits on
these module types until after the download is complete.
2. UPGRADE INSTRUCTIONS
The instructions for upgrading your software to BNS-2000 VCS Release 6.0 are contained in
the BNS-2000 Node Reference, Release 4.0, Issue 2. There are 3 different procedures that can be
used.
1. UPGRADING THE SYSTEM TO A NEW RELEASE - GENERAL METHOD
These instructions are to be used to upgrade the current hardware and software release on the
node to BNS-2000 VCS Release 6.0. The instructions begin on page 7-23. The instructions include
two sections on upgrading the software.
•
Procedure 7-26, p. 7-73: "Upgrading a BNS-2000 Software Release: Single Control Computer"
-3-
These instructions are for upgrading software from one release to another release on a
node with a single control computer.
•
Procedure 7-27, p. 7-80: "Upgrading a BNS-2000 Software Release: Dual Control Computers"
These instructions are for upgrading software from one release to another release on a
node with dual control computers.
2. UPGRADING THE SYSTEM TO A NEW RELEASE WITH MINIMAL DOWNTIME
These instructions are for upgrading a node running Datakit II VCS Release 3.0, 3.1, 4.0, or a
BNS-1000 Release 1.1 or 2.0 to BNS-2000 VCS Release 6.0 with minimal downtime. For upgrades
from Release 5.0, use the next section, "Upgrading to a New Software Build or Compatible
Release". These procedures can ONLY be used with a dual ECPU Control Computer
configuration being upgraded to a Release 6.0 ECPU system. All other configurations must use
the previous procedures referenced above for upgrading to a new release. The instructions begin
on page 7-101.
3. UPGRADING TO A NEW SOFTWARE BUILD OR TO A COMPATIBLE RELEASE
These instructions are for upgrading a Datakit II VCS Release 5.0 ECPU system to a BNS-2000
VCS Release 6.0 ECPU system, or for upgrading from one build of BNS-2000 VCS Release 6.0 to a
later maintenance build of Release 6.0. The instructions are only for upgrading the software, and
can only be used in cases where no hardware upgrades are required. The instructions begin on
page 7-7.
Upgrades can also be done using the StarKeeper II NMS software download capability. For
further information, see the StarKeeper II NMS Core System Guide.
3. YEAR 2000 SUPPORT
The year 2000 is supported in this release, starting with Build 52.
4. DT-4000
Beginning with Build 81, BNS-2000 VCS (Datakit II VCS) contains enhancements to the controller code supporting the DT-4000. The DT-4000 is a multi-access device that can be used as a
drop-in replacement for the SAM in any BNS-2000/BNS-2000 VCS network, with or without any
IP interconnection. It has 16 async/sync ports with speeds up to 115 Kbps synchronous and
56Kbps asynchronous. It has a built-in IP-GATE and can be used to securely transport IP traffic to
a remote LAN off the BNS-2000/BNS-2000 VCS network. The built-in IP-DSU function can also
be used for IP network access without any BNS-2000/BNS-2000 VCS network connection. For
more information about the DT-4000 please see the DT-4000 user manual, on the BNS website
http://www.datatekcorp.com click on the Documentation link under Products.
5. UMI SUPPORT
Connectivity between an IP network and a BNS (refers to both BNS-2000 and BNS-2000 VCS
(aka. Datakit II VCS)) network is accomplished using the Universal Mediation Interface Module
(UMI). As a state-of-the-art "solid state" module that resides in a BNS node, the UMI is both a
replacement and enhancement of the LCS60 product.
Beginning with Build 87, BNS-2000 VCS Release 6 allows a UMI module to be configured as standard BNS module, namely a UMI module, in the node. Prior to this release the UMI was
configured on the BNS controller as a SAM504, mapping 504 BNS ports to 504 "virtual ports"
residing in the IP network. All IP configuration data was entered directly on the UMI console.
Hence, every virtual port had to be configured twice, once on the node and once on the UMI
module itself. With this release, the Base Configuration of the UMI and the configuration of all
the virtual ports (vports) including their IP information is performed on the BNS node only, and
downloaded to the UMI module when it is restored to service. The major benefits are that all the
-4-
IP configuration information for the module and all the virtual ports can be entered, changed,
verified, saved, and backed-up on the BNS controller, just like for any other BNS module, and
once only. In builds 88, 89, 90 and 91 maintenance fixes and enhancements were added that affect
the UMI configuration in a node. Therefore it is strongly recommended that a node be upgraded
to build 91.
6. BUILD 91 MODIFICATIONS
6.1 Control Computer
1.
BellSouth reported problem with MOVE/COPY command for trunk T1. This problem has
been fixed.
2.
Made changes to the DVDELETE command to allow at to remove UMI files for the UMI
module.
3.
Customers want to backup the database to the hosts, but the "BACKUP HOST" command
only backups cfdata, sysgen and comments files. It did not backup the ipgate file and umi
files. The same problem also exist for the "RETRIEVE HOST" command. Both commands
have been changed to handle ipgate and UMI files.
4.
There is a problem that the database didn’t get sync’ed when backing up the database and
other files to the host. This problem has been fixed.
5. While testing UMI in our lab, it was noticed that the controller caused the UMI calls come
down during a warm reboot (init controller). This problem has been fixed.
7. BUILD 90 MODIFICATIONS
7.1 Control Computer
1.
Qwest requested a stress test of putting multiple UMI vports into the FIX state.While testing this, another problem was found where call process software for SAMs would not exit
after hitting 179 ports. After 179 ports were in the FIX state, trying to set up additional calls
would fail. This problem has been fixed.
2.
For the support UMI version 21, there are four new options for SNMP MIB-II, sysComm,
sysContact, sysName, sysLocation, added to DK/BNS interface to configure. Note that A
DTK41 is not required to save these initial values when the DK/BNS interface is used.
3.
Update the copyright year range to the current year, 2003.
8. BUILD 89 MODIFICATIONS
8.1 Control Computer
1.
BellSouth reported that the problem with "retrieve umi" failure. This problem has been
fixed.
2.
It was found that if the settings for PAP, CCAR and BAUD RATE were incorrectly set,
problems would occur during UMI call setup. The correct setting we enter is PAP=off,
CCAR=off and BAUD= NO AUTO.
3.
After converting from a SAM504 to a UMI, the IP address and related configuration
showed incorrect data. This problem has been fixed.
4.
There is a problem when a converting from a SAM504 to a UMI; the output of "verify umi
vport" incorrectly shows vports as configured and in-service which were never entered into
the database. This problem has been fixed.
5. The connection between the StarKeeper host and a node would be disconnected when the
StarKeeper administrator tried to restore a UMI vport that was already in service. It was
discovered this could also occur on the "A" port. This problem was fixed.
-5-
6.
Several new features were added in build 20 of a UMI. The ability to configure these
features in a Datakit node was added in this release (build 89). Among these features are:
•
CUGS for SNMP requests
•
Multiple DNS entries
•
The configuration of PDD strings in mnemonic form for IP destinations. (This
feature requires that a DTK41 IO board is used with a Series 1:2 UMI
module.)
•
Allow an SNMP GET to verify a DTK41 IO board is used with the UMI.
9. BUILD 88 MODIFICATIONS
9.1 Control Computer
1. New features were added to build 20 of the UMI. The controller has been changed to access
those new features. Build 20 or later of the UMI is needed to utilize these features. If they
are configured on the controller but the UMI is not running a version that supports those
features, the configuration will just be ignored. These features are completely described in
the updated version of "Universal Mediation Interface (UMI) Module User’s Manual Supplement
For
BNS/Datakit II VCS Nodes" which can be found at
http://www.datatekcorp.com.
2. When a customer installed DK R6 build 87, they had a problem with file system space. In
order to get some space back, we deleted AIM and BRIDGE modules, since they have been
DA’d for a long time.
3.
Customer reports that not all alarms were being reported to SK. We found that alarm 8455
was being reported, but not alarm 8452. As it turns out 8455 is a Major alarm and 8452 is
classified as Informational. SK only logs Critical, Major and Minor alarms, not Informational. So alarm 8452 has been changed from type informational to type major.
4. The SAM call process was changed for synchronous ports. The STATION ID and Message
of the Day are no longer sent to ports configured as synchronous.
10. BUILD 86/87 MODIFICATIONS
10.1 Control Computer
1.
Add a new feature in the controller for configuring a UMI module as a UMI instead of as a
SAM504, Details are given in the document "Universal Mediation Interface (UMI) Module
User’s Manual Supplement For BNS/Datakit II VCS Nodes".
11. BUILD 85 MODIFICATIONS
11.1 Control Computer
1. When the DT-4000 is controlled by Datakit, the DT-4000 IP-GATE port does not get
automatically restored on reboot or power-cycle of DT-4000. The problem has been fixed.
2.
A problem was found at AT&T while installing UTM boards into MPC concentrators. If a
high baud rate was configured (ie: 1.544M) the node would "lock-up". If a low baud rate (ie:
9600) was configured the node and the concentrator would operate with no problems. The
problem has been fixed.
3.
BellSouth reported that the Auto Remove Babbling Ports feature was not working on one of
their nodes. The message said that the ports were being marked as DEAD but were not
being removed. The SKII was getting repeated messages and it was generating as many as
36 message log files a day. The problem has been fixed.
-6-
4.
Update the copyright year range to the current year, 2002.
12. BUILD 84 MODIFICATIONS
12.1 Control Computer
1. Enhancement of comand "dmeas conn" by adding feature of displaying information on
average calls and currently active calls.
2. Enhancement of the command DVDISPLAY TBLMOD COOKED 1-127 by adding feature of
displaying information on total used channel.
3.
Update the copyright year range to the current year, 2001.
4. The output of the DVDISPLAY STATUS OOS was incorrect for controller and repeater. This
problem has been corrected.
5.
Add new load module "pvc.4p.r1" for the slm module for Bellsouth.
13. BUILD 83 MODIFICATIONS
13.1 Control Computer
1.
There was a problem when verifying DT-4000 IP ports using the "verify sam ip" command.
This problem is fixed.
2. When entering ipgate information on the DT-4000, the prompt "Virtual Path Number" was
changed to "Route entries" Diagnostics commands run on a DT-4000 were not working
properly. This problem has been fixed. Moved the "ip port" information to be entered when
you’re entering the service type, group, and PDD information. It was previously
incorrectly placed in the routing entry prompt sequence.
3.
There were problems in restoring and verifying a DT-4000 when it was connected to a
SAMML link. These problems have been fixed.
4. The configurable trunk speed for the DT-4000 was increased to T1/E1 rates, reflecting the
ablility of the DT-4000 to operate at these speeds for interworking with a Universal Trunk
Module (UTM).
5.
There were problems using the "convert" command to convert a SAM16 to be type DT-4000
in the node database. This problem has been fixed.
6.
There were problems deleting DT-4000 ipgate information. These problems have been fixed.
13.2 X.25, X.25P and X.75 Services
1. The X.25P module was not working properly when talking through a Universal Media
Interface (UMI) configured for synchronous traffic, operating in PAD mode instead of
PASS-THRU mode. This has been fixed.
14. BUILD 82 MODIFICATIONS
14.1 Control Computer
1. The link on an X25P module port was not being brought back up when the module was
restored to service if it was an RS-232 connection configured for internal clocking, and the
DROP DTR option was set to YES. The link would also fail to come back up when a port
configured for DROP DTR set to YES was removed, modified, and restored. These problems have been fixed.
2.
Added controller support for the DT-4000 feature.
-7-
15. BUILD 80 MODIFICATIONS
15.1 Control Computer
1.
A customer reported that the node was showing average values higher than the peak
values for some concentrator measurement reports. The node was computing the peak
values incorrectly, and this problem has been fixed.
15.2 X.25, X.25P and X.75 Services
1. The link on an X25P module port was not being brought back up when the module was
restored to service if it was configured for internal clocking, RS-232 connection and
DROP_DTR set to YES. This problem was corrected. The link would also fail to come back
up when a port configured for DROP_DTR set to YES was removed, changed and restored.
This problem was also fixed.
16. BUILD 79 MODIFICATIONS
16.1 Control Computer
1.
A previous feature to double maximum number of groups introduced a problem in Build
77, causing the node to PANIC with the message "Special process 8 exiting unhappily"
when more than 2000 group entries were used. The new maximum number of 4096 groups
caused an internal table calculation to overrun it’s storage area and be truncated. This
caused the pointers to a measuements repository area to become invalid, panicking the
node when these measurements were collected. The offending integer has been cast into a
long and the problem fixed.
16.2 X.25, X.25P and X.75 Services
1. The X25P module was not handling the Frame Reject (FRMR) frame from an X25 host properly. It was getting into an infinite loop because it was re-transmitting the frame with
wrong size repeatedly. This fix eliminates problem by improving improving the handling
of the FRMR frame by the module. Note that this problem and fix only occur in the X.25P
module, X.25 module services are unaffected.
17. BUILD 78 MODIFICATIONS
17.1 Control Computer
1. When port B on the node console was administered for password protection, the user was
not always prompted for the password. If a previous user accessed the port B and did not
type "exit" after their session, the next user could get access to the port without entering the
password. This problem has been fixed.
18. BUILD 77 MODIFICATIONS
18.1 Control Computer
1. The year displayed on the node during the boot sequence was incorrectly reporting as 1998
rather than 1999. This date has been updated.
2. The command "dvdisp status all" failed when there was tsm8 or bsc3270 modules in the
node that were not configured in the database. The problem has been fixed.
3. The billing connection was not disconnecting when a trunk failure occurred, due to the process not recognizing a conditional time_out. The problem has been fixed.
4. The mcsusage was reporting the wrong information in the Percent Used field of part 2 of
the report, Controller Channel Usage. Changed the data type from integer to long, which
will calculate the correct value for the Percent Used field in part 2 of this report.
-8-
5. The problem was introduced in Bld. 66, when the maximum number of groups was
increased from 1024 to 2048. The receiving endpoint went into busy state when the call
went down, and only a remove and restore of the module could bring the port back into the
normal state. The reason was that the group ID defined for the receiving group was greater
than 1024, which was the system limit inside the kernel. The solution was to increase the
number of group ids allowed in the kernel to the maximum number of groups allowed.
19. BUILD 76 MODIFICATIONS
19.1 Control Computer
1.
After a dbupgrd a CPM connected host could not make calls. It was determined that the
security parameters on the CPM were not upgraded properly. The dbupgrd was fixed to
properly upgrade the CPM modules in the database.
2.
A problem with several of the change commands resulting in database corruption of the the
Predefined Destination (PDD) tables. If this corruption occurred the following message
would be printed during a change or delete of the effected module.
COMMAND FAILED: Internal database error:
(, chgpvcdest, xxxx, dbm_pdd, 1, 125, 0)
or
COMMAND FAILED: Internal database error:
(, dportpdn, xxxx, dbd_pdd, 1, 91, 0)
The corruption could be cleaned up. Now however, the cause of the corruption has been
eliminated. If a customer experiences this problem loading this software will not correct
the problem, instead it will prevent the problem from occuring. If you experience this problem contact the Customer Assistance Center for instructions to clean up the corruption.
3. The dstat bisync command showed incorrect information for a range of terminals. If status
were displayed on the terminals individually it was correct. This problem has been fixed.
19.2 X.25, X.25P and X.75 Services
1. When X25p was configured for internal clocking, it showed correct lead status for the physical layer but failed to establish the link layer. This problem has now been fixed.
20. BUILD 75 MODIFICATIONS
20.1 Control Computer
1.
A problem was discovered where trunks carrying very large numbers of calls could end up
with half-connected calls under certain conditions. Typical conditions would be trunks
which have high noise levels, where the trunk comes down and up rapidly and repeatedly.
Another condition is on software upgrades, if the calls are left up on the trunk during the
upgrade and the node being upgraded is adjacent to an R6.0 node.
20.2 X.25, X.25P and X.75 Services
1. The following series of events resulted in a buffer not being freed. An X.25 host sends a
X.29 packet to the X.25 module to change the PAD profile. Next a call cleared packet
arrives. The buffer is not freed which results in excessive buffer utilization and impacts performance. This issue applies to the X.25, X.25P and X.75 modules.
2.
EIA leads did not come up during X.25P loop around diagnostics resulting in diagnostic
failures. In addition, after the failure the module failed to bring up the link making the
module unusable.
-9-
3.
A fix in build 73 and 74 caused x25 and x25p SVC calls to fail. This problem has been fixed.
21. BUILD 74 MODIFICATIONS
21.1 Control Computer
1.
At very high utilization (near 100%) the trunk utilization measurements, dmeas trunk. are
incorrect. Specifically the peak trunk utilization is wrong. This error has been corrected.
2. The change x25p port command on an in service module did not work correctly if the
START SVC CHANNEL did not use the default. The STARTING SVC LOGICAL CHANNEL NUMBER is changed back to the default value used in the enter x25p port command.
The problem has been corrected. The
21.2 X.25P Services
1. The dstat x25p command showed incorrect status of DTE, DCE, DSR, RTS, CTS and DCD
leads. This has been fixed. This fix also corrects the lead status response on the debug channel for l1eia command.
22. BUILD 73 MODIFICATIONS
22.1 Control Computer
1. The factory diagnostics for the fdiag db command were modified to use the new list
numbers assigned to the I/O boards.
2. The enter/change profile commands have been changed to limit the CLOSED USER
GROUPS (CUG) allowed from 255 to 254. This change address a problem where CUGs
greater than 128 did not work properly while mainting backward compatability.
22.2 TSM8 Module
1.
An additional modification was made to correct the verify tsm report for the "x5" protocol,
which was added in build 72.
23. BUILD 72 MODIFICATIONS
23.1 Control Computer
1. The year 1998 was added to the copyright message that appears at boot time.
2. The output of the verify schedule command has been changed to reflect the fact that measurements for the FRM are displayed every 15 minutes.
3.
Some users reported problems bringing up a new server on a CPM-connected host when
the CPM was in a concentrator. The following error message was displayed: ACCESS
DENIED. Alarm 8332 was also displayed, and the alarm had err no=28. An internal table
was being incorrectly sized. The problem has been fixed.
23.2 MSM Module
1.
A fix was made to the MSM module. Prior to the fix, alarm numbers 8451 and 8452
displayed the logical channel number instead of the physical port numbers. Those alarms
will now display the physical port numbers.
23.3 TSM8 Module
1.
An enhancement was made to the TSM8 module for one specific customer, and should only
be used by that customer. A new async-based protocol called x5 was introduced for the
TSM8. This protocol is similar to the X1 protocol, but it reduces network delay. It is
intended for lottery applications.
- 10 -
23.4 Synchronous/Asynchronous Multiplexer (SAM)
1.
An enhancement was made to the SAM module for one specific customer and should only
be used by that customer. A new async-based protocol called x5 was introduced for the
SAM. This protocol is similar to the X1 protocol, but it reduces network delay. It is intended
for lottery applications.
24. BUILD 71 MODIFICATIONS
24.1 Control Computer
1.
A user reported that they were unable to get the SC1> prompt on a dual controller ECPU
node, even though they were able to get the SC0> prompt. The problem has been isolated
and fixed.
2. When users executed the diag/cert command and chose a full or a short certify, the time
estimate in parentheses was incorrect. The time estimates have been corrected for the 500
meg disk and the 100 meg disk.
25. BUILD 70 MODIFICATIONS
25.1 Control Computer
1.
A customer reported a problem where running the node_remote diagnostic command on a
session maintenance trunk caused it to fail. This happened when 10 repetitions were
specified. The problem has been isolated and fixed.
26. BUILD 67 THROUGH BUILD 69 MODIFICATIONS
26.1 Control Computer
1.
A user reported a problem with the StarKeeper bandwidth utilization report. The LINK
TYPE SPEED field for a T1 trunk contained garbage. The controller will now send the T1
link speed correctly to StarKeeper. The problem has been fixed.
26.2 X.25P Services
1.
A call into an X.25P port on a certain logical channel number got a response from the X.25P
module on a different logical channel number after the call was connected. The problem has
been fixed.
2.
A customer reported a problem with the output of the dstat x25p module .. command. The
value for the OPERATING STATE field was "up" when it should have been "down". This
problem did not occur with the X.25 module. The problem has been fixed.
3.
If a call was made to an invalid destination, and the connection to the PAD was dropped,
there was a 60 second delay before the call was taken down and the user could try to reconnect. That delay was removed.
26.3 Frame Relay Module (FRM)
1.
A word was misspelled in one of the prompts for the enter frm port ... command. In the
prompt PVC MANAGMENT TYPE, MANAGMENT has been corrected to MANAGEMENT.
27. BUILD 63 THROUGH BUILD 66 MODIFICATIONS
27.1 Control Computer
1. The install release ... command has been enhanced to allow for a database upgrade from
one build in Release 6.0 to another build in Release 6.0. Previously, database upgrades were
not needed when installing a newer build of a maintenance release. This enhancement
allows us the flexibility of making database changes within a maintenance release, while
- 11 -
maintaining the ease of upgrading from one build to another using the new install release
command.
2.
There were some small database changes made to database header files. Those files were
updated in the dbupgrd read program for this release.
3.
An enhancement has been made so that the size of the group table in the database has been
doubled. In addition, the size of the comments file has been doubled. The database shared
memory area has been increased in order to accommodate a larger group table. ALL CUSTOMERS WHO LOAD THIS BUILD WILL HAVE TO RUN dbupgrd, EVEN IF THEY
ARE RUNNING EARLIER VERSIONS OF RELEASE 6.0. The dbupgrd instructions are
attached to this letter.
4.
There were occasions when some or all of the following alarms were being erroneously
displayed on a CCM node:
* 1018 MODADDR= MODTYPE=
REPORT ALARM: stat: Mode switch not enabled
Rec act: Enable mode switch
** 1013 <CABINET/SHELF>=<number>
REPORT ALARM: stat: Power supply failure
Rec act: Schedule power supply maintenance
** 8030 SHELF=<number>
REPORT ALARM: stat: Module fuse failure
Rec act: Check the flag behind power supply for the blown fuse
** 8032 SHELF=<number>
REPORT ALARM: stat: Rectifier failure
** 8034 SHELF=<number>
REPORT ALARM: stat: Carrier temperature too high
Rec act: Check fans; check air filter
*C 1001 SHELF=<number>
REPORT ALARM: 12-volt power failure
Rec act: Check +12 and -12 volt fuses; replace power supply
** 1010 SHELF/LINK=<number>
REPORT ALARM: stat: Fan failure
Rec act: Replace fan
** 8033 SHELF=<number>
REPORT ALARM: stat: Charger failure
Rec act: Check AC utility power supply
These alarms were coming out erroneously, and were generated even though the node did
not have any of these environmental problems. The problem was a software bug that has
now been isolated and fixed.
5. When a module was in the out/fault state, it was not displayed as part of the output of the
verify oosports command. There was no problem when the module was in the
out/manual state. The problem has been fixed, so that the verify oosports command
correctly reports all modules that are out of service.
6.
A database upgrade from R3.1 to R5.0 and R6.0 failed because of an incorrect version string
comparison in the database upgrade program. The problem has been fixed.
- 12 -
27.2 Frame Relay Module (FRM)
1.
There was an extra value (0) following the FRAME SLIP SECS field in the output of the diag
frm online <module> <port> facility command. The value had no heading. The following
heading has been added for that field: BER6.
2. When modules were removed or restored, the following system message would be
displayed:
restore <module type> <module number>
The system message was missing the keyword "module", which will now be displayed in
the message to indicate which component is being restored or removed. The system message will now be displayed as follows:
restore <module type> module <module number>
This fix applies to any module that must be removed or restored by indicating that the
module is the component to be restored.
Example: restore frm module <module>
3.
There were negative values in continuation billing records for the FRM module. The problem has been isolated and fixed.
4. The FRM module was added to the list of excluded modules in the help verify oosports
command since the module is not supported in the verify oosports command.
5.
A new flavor of the sleeping dlci bug was found and fixed. The symptoms of this problem
were that after a period of normal data transmission, sometimes a dlci stopped transmitting
data to the backplane to a remote dlci. The problem has been fixed.
6.
A user was sending data from a FRM-M2 E1 to a CHE1 FRM. After execution of the dmeas
frm ... command, the following error message was displayed:
Measurement request for module <module number> returned error;
report will be incomplete
Measurement request for module <mod number> port <number> dlci <number> returned error;
report will be incomplete.
COMMAND FAILED: EXITED PREMATURELY: REASON 2
Then a few lines of the dmeas report came out, but the starting interval was displayed as
"**:**", and the message "No data available for this section" was displayed. At that point, the
terminal hung, and the user had to hit the delete key to get the CC0> prompt back. The
problem has been isolated and fixed.
7. The output of the remove/restore frm dlci ... command was garbled when specifying a
range of dlci’s that included several that were already out/in service. The problem has
been fixed. In the future, a single message will be displayed at the end of the output if one
or more dlci’s were ascertained to be out/in service when the remove/restore frm .... command was executed.
27.3 MSM Module
1.
An MSM module was placed in slot 14 of an MPC15 (a full remote shelf), and a user could
not restore it to service. It failed with the following error message:
Restore failed: Control computer in slot <module>/14
Other modules worked correctly in that slot. The problem has been found and fixed.
27.4 LAN Protocol Module (LPM)
1.
A user executed the dstat lpm route <module> command, and ascertained that all the
routes were entered. Then the user did a remove and a restore of the lpm module. The
- 13 -
output of the dstat lpm route <module> and the verify lpm route <module> all commands
showed that all the routes were gone. The problem has been fixed.
2. When a user executed the verify lpm route all command through StarKeeper on an LPM
with 26 routes defined, there was no output. The same command was executed on the node
console, and 23 routes were displayed, after which the following error message appeared:
MESSAGE TOO LONG FORCING BREAK: DATA LOST
The problem has been isolated and fixed so that all routes defined will now be displayed.
27.5 X.25 and X.25P Modules
1.
A problem was introduced in build 60 of this release. In that build and subsequent builds,
X.25 switched calls no longer worked. The problem did not manifest itself with X.25P
modules. The problem has been isolated and fixed.
2.
A customer reported a problem with X.25P data transport. The transmission of data from
the X.25P port stopped. In order to restart the data transmission, the customer had to
remove and restore the module. The problem has been isolated and fixed.
27.6 Synchronous/Asynchronous Multiplexer (SAM)
1.
An enhancement was made to the SAM module. Prior to the enhancement, SAM receive
ports asserted the DCD lead when a call was placed to the SAM port. After the call was
disconnected, the DCD lead was dropped. This enhancement allows the receiving SAM
port to keep the DCD lead high after the call has been dropped. It has been made a
configurable option in the enter/change sam port ... command. The new prompt will appear
as follows:
DCD/DTR LEADS ALWAYS HIGH [yes, no: +(no)]:
For further information, see the attached Product Documentation Notice.
28. BUILD 61 THROUGH BUILD 62 MODIFICATIONS
28.1 Control Computer
1. When a user upgraded a dual controller node from one release to another they got the following error messages:
util> copystby cannot access bstat6
copystby cannot access *
The upgrade was done correctly and these error messages were incorrectly generated. The
diskcopy command will now be used when doing upgrades on a dual controller node.
2. The change address command has a prompt which allows all originating security strings to
be changed when the current security string is changed. The security strings were not
properly updated for the speedcall addresses. This has been fixed.
3. Occasionally, after a period of heavy load on a node, the node would panic and the following alarm would be displayed:
*C REPORT PANIC!! Unexpected supervisor bus error
This problem also sometimes happened when an ISN concentrator was attached. This
problem was isolated and fixed.
4.
A problem was found internally when running the dbresize command. The LD table was
full, and the node could not reboot. The problem was fixed by introduction of a checking
routine in another place.
5. When dbupgrd was executed, the CPMML host ID was changed to N/A. The problem has
been fixed so that the host ID is handled correctly during the upgrade.
- 14 -
28.2 SLM Module
1.
On a CCM node, the offline boot diagnostics for the SLM module were failing on an intermittent basis. The problem has been isolated and fixed.
28.3 Switched Bisync Module (BSC)
1. The comment error message for an in-service port on an in-service bsc module contained
the wrong module and port number. If a user tried to change the comment field for the port
on an in-service module when the port was also in service, the following error message was
displayed:
Can only change the comment field with module 1 port 0 in service
The message was erroneous because it always said module 1 port 0, no matter what module
and port the user was trying to change. The problem has been fixed.
28.4 TSMT1 Module
1.
A problem was reported after TSM8’s were replaced by TSM-T1’s or Frame Relay Modules.
The response of the TSM-T1 or the FRM to an unrelated network problem (data loss on
SWTs) caused the module to stop transmitting on the backplane to the other end of the call.
The fault was not in the interface to the attached equipment. In order to clear the problem,
the port had to be removed and restored to service. This problem has been isolated and
fixed.
28.5 DKAP Module
1.
Several calls were set up via the monitor channel of the DKAP module. The calls were to
TY12 ports with PCs attached. After 10 calls were set up, the module reset and requested a
TEXT + CONFIGURATION download. The problem has been isolated and fixed.
28.6 Frame Relay Module (FRM) and FRM-M2 Module
1.
A problem was encountered when executing the diag frm on ...nping command. If, for
example, dlci 100 was selected the first time the test was run, the nping was executed for
that dlci. However, if yes was selcted at the CONTINUE TESTING [yes, no (+no)]: prompt,
and another dlci was specified, the nping still executed on the original dlci selected. The
problem has been fixed.
2.
A problem was reported after TSM8’s were replaced by TSM-T1’s or Frame Relay Modules.
The response of the TSM-T1 or the FRM to an unrelated network problem (data loss on
SWTs) caused the module to stop transmitting on the backplane to the other end of the call.
The fault was not in the interface to the attached equipment. In order to clear the problem,
the port had to be removed and restored to service. This problem has been isolated and
fixed.
3. When a user entered a virtual port on a CHE1 FRM, if all 31 timeslots were already allocated, whatever the user entered at the timeslot prompt was rejected with an error message
and the user was reprompted in an endless cycle. The problem has been fixed so that if a
user is trying to enter a virtual port and all timeslots have already been allocated, an INPUT
ERROR message will be displayed. If the timeslots are all allocated after a virtual port has
been entered, an INFO message to that effect will be generated.
4.
Under heavy load conditions, and after a period of normal data transmission, sometimes a
dlci stopped transmitting data to the backplane to a remote dlci. The problem has been isolated and fixed.
5. When the enter frm-m2 virtual ... command was executed for a comma-separated list of
ports, the port number header line was not displayed while the command looped for time
slot allocation for the list of ports. However, the header line was correctly displayed when a
range of ports was entered. This problem was also seen with the CHT1 frm m1 module.
- 15 -
Also, a blank line has been inserted between the MAXIMUM AGGREGATE CIR FROM
REMOTE DEVICES prompt and the BILLING prompt because the BILLING prompt and
the prompt following it are common to the entire list or range of ports, and not specific to
the last port on the range or list.
6. When executing diag frm on ..., the following instruction was being displayed for link tests:
INFO: Place DSU port in loop-around mode
That instruction should only be displayed when the user executes the virtual port test. The
problem has been fixed.
7.
An incorrect termination of a loop for iop/frm caused some frames to be processed that
were supposed to be ignored. The problem has been resolved.
8.
A change was made so that all INPUT ERROR messages for remove, restore, enter, change
and delete frm-m2, will be formatted in the same way.
9.
A change has been made to the DATA LINK CONNECTION IDENTIFIER prompt in the
verify frm dlci ... command. Previously, that prompt contained both pvc and multicasting
DLCIs specified in one range. Now, this prompt will have the PVC DLCIs (16-1022)
separated from the multicast DLCIs (1019-1022), and will appear as follows:
DATA LINK CONNECTION IDENTIFIER [16-1007, 1019-1022: +(16-1022)]:
28.7 X.25P Services
1.
An enhancement was made to the X.25P module. An option has been added to allow the
user to configure the X.25P port to drop DTR on removal of the port. This option is available for RS232 X.25P modules. It is unnecessary for V.35 modules. Before addition of the
new option, after the port was removed from service, DTR remained high. A new prompt
has been added, which is displayed as follows:
DROP DTR ON PORT REMOVAL [yes, no (+no)]:
For further information, see the attached Product Documentation Notice.
2. When an X.25P module was in service and a user executed the change x25p port ... command to change the packet or window size, there was no warning message telling them the
maximum recommended packet and window size for the number of channels configured.
An enhancement has been added, so that before prompting for the DEFAULT NETWORK
LEVEL WINDOW SIZE and the MAXIMUM WINDOW SIZE, if the module is in service,
the following INFO message will be displayed:
INFO: The largest window size recommended given the number of channels
and packet size currently configured is <num>.
Exceeding this number can exceed the module capacity.
Just before prompting for the DEFAULT NETWORK LEVEL PACKET SIZE, the MAXIMUM PACKET SIZE, and the MAXIMUM REMOTE PACKET SIZE, if the module is in
service the following INFO message will be displayed:
INFO: The largest packet size recommended given the currently configured
number of channels and window size is <num>.
Exceeding this number can exceed the module capacity.
3. When executing the diag x25p ... command, if the user hit the delete key at any of the
prompts, the CC0> prompt came out on the same line as the prompt the user was deleting
out of. The CC0> should come out on a new line. The problem has been fixed.
- 16 -
29. BUILD 60 MODIFICATIONS
29.1 Control Computer
1.
Version information was corrected in the output of the help and the help help command.
2.
A SIM debug command called restime has been added so that the time string of the restoral
time of a module can be printed out. As a check, the command will also print out the
current time string.
3. The dbwalker command has been changed so that the node information and billing table
will not print out unless specifically requested by using the -h option.
4. The year 1997 was added to the copyright message that appears at boot time.
5. When running LOADER switch diagnostics on the standby switch, test #9 failed. Test #9 is
the "Channel number out-of-range or mask error detector" test. The failure occurred on the
second or third time that test #9 was run by itself. The failure of test #9 also occurred every
time test #18 was run. Test #18 is a group test that includes all the tests. When the failure
occurred, the following error message was displayed:
error - Unexpected source module.channel LSE13-15 = (aa00bb,cc0000,
144a)
expected 22337.18
test did not pass
The problem has been fixed.
29.2 Frame Relay Module (FRM)
1. When a FRM port, virtual port, or dlci was entered on an out-of-service module that was in
the "out(fault)" state, the "INITIAL SERVICE STATE" prompt was not being generated, and
it should have been. After entering the port, virtual port, or dlci, when the verify frm ...
command was executed, the service state for the entered component was set to out-ofservice. The problem has been fixed so that the INITIAL SERVICE STATE prompt will now
be generated when entering any of the above-mentioned components.
29.3 LAN Protocol Module (LPM)
1.
There was an incorrect system response to the LPM host portion of an IP address. The host
portion of the IP address is determined by the IP address entered and the subnet mask. A
user entered an IP address with a host portion of 0. The user got a confusing error message.
The original error message was:
INPUT ERROR: 0.0.0.0 is an invalid host value for IP address
The message was not clear, because it printed the host portion (in this case zero) as a complete IP address x.x.x.x Basically, this error message was to let the user know that a host
value of an IP addresss is not allowed to be all zeros or all ones. A new and more informative error message will now be generated in this case. The new error message is as follows:
Host value of IP address of all zeros or all ones is invalid
2.
There were 2 problems with connection and termination billing records for calls originated
by the LPM module and going through a PQ-Trunk to a node. The first problem was that
in both the connection and termination records, the PQ-Trunk slot was displayed as
<module#>/0 instead of just <module#>. The second problem was that in both the connection and termination records, the channel numbers for the PQ-Trunk were off by 4. Output
of the display connections command for dlci’s 16-20 showed PQ-Trunk channels 105-109,
but the billing records showed channels 101-105. Both problems have been fixed.
- 17 -
29.4 X.25 and X.25P Services
1.
After upgrading from R5.0 to R6.0, a user reported that PAD addresses associated with
receive-only SVCs could not be accessed. Attempts to do so generated the "Address is busy"
response. The problem has been isolated and fixed.
2. When a call was placed from an X.25P port, the calling address sent to the destination was
changed to the sr/sa/epn of the originating X.25P port. An enhancement has been made so
that a new prompt has been added that will allow the user to turn the CALLING ADDRESS
SUBSTITUTION feature either on or off. For further information, see the Product Documentation Notice attached to this letter.
3. When a node’s database was converted via the dbclean command, the following error message was displayed for the X.25P modules:
Upgrade error for x25p module
Cannot find x.3 profile
The modules were converted correctly. The message indicated a problem where there was
none, and was generated about 8-15 times per module. The problem has been fixed.
29.5 DKAP and HSDKAP Modules
1.
There were some timing and register access problems found in the backplane access with
the HSDKAP. The problems have been fixed.
2. The EDOS scheduler used for interface modules was inefficient when only the main processor was being used. Performance improvements were added for the case in which no peripheral processors are used. In addition, other performance improvements were added, and
throughput measurements were enhanced.
3.
Some improvements were made to the dkap module. The takedown routine was modified
to better clean up channels when calls on channelsets get taken down. Performance was
improved, and throughput measurements were enhanced. In addition, a new route
manager function was added that will print the current state of the Common Signaling
Channel (CSC).
4.
If the HARDWARE CONFIGURATION TYPE on a dkap module was changed from
"hsdkap" to any other string, or changed from any other string to "hsdkap", the data base
was not properly updated. This problem caused the restore dkap ... and diagnose dkap ...
commands to fail and to generate confusing error messages. After failure of the restore
command, the following error message was generated:
Restore dkap module <num> failed
Module address <num> contains dkap module
(dkap expected)
After the diagnose dkap command failed, the following error message was generated:
INPUT ERROR: Module <num> is a(n) dkap.
MODULE ADDRESS:
In addition, the diag dkap command was modified to prevent illegal diagnostic commands
on the HSDKAP, and to provide better error messages.
5.
If change dkap ... was executed with a current COMMENT displayed as the default, and a
<CR> was entered to accept the current COMMENT, and the HARDWARE CONFIGURATION TYPE was either changed to hsdkap or from hsdkap to something else, the COMMENT information was deleted. When the verify dkap ... command was executed, there
was no entry shown in the COMMENT field. The problem has been isolated and fixed.
- 18 -
6. The enter dkap channelset .. command specified the wrong number in the CHANNELS
PER CHANNEL SET prompt when configuring a HSDKAP. The prompt with the incorrect
number of channels was displayed as follows:
NUMBER OF CHANNELS PER CHANNEL SET [1-2043: +(2043)]:
The maximum number of channels should be 1023, and the default should be 100. The
corrected prompt will appear as follows:
NUMBER OF CHANNELS PER CHANNEL SET [1-1023: +(100)]:
The problem has been fixed.
7. The dkap debug command netprthru has been modified to provide more accurate
throughput calculations. In addition, performance improvements were added.
8.
Support for HSDKAP was added to the dbclean and dbupgrd commands.
30. BUILD 55 THROUGH BUILD 59 MODIFICATIONS
30.1 Control Computer
1. While testing internally with an 8-shelf node, and executing an init hard command, the
node went into a state where it would not take any command at all. The hang was due to
the CPU UTILIZATION reaching 100%. The problem was caused by syncmaint for various
modules getting caught in a tight loop.
Another problem occurred due to the large number of modules. The sendmsg to config
failed because the config message queue was full. This problem has been fixed.
2.
Both the database working area and the database shared memory area have been increased
by 64K.
3.
In parallel with CCM development, a special lab configuration was set up to reproduce
heavy controller loads. During controller overload, customers have seen these symptoms:
controller panics, little or no new call setups and takedowns, trunks going down, trunk
channel state mismatches and failure to restore service after a controller reboot. This testing
effort helped development isolate and fix several operating system deadlocks, expand the
message buffer pool and adjust message thresholds to decrease the chance of running out of
message buffers at a critical time, improve the handling of overload cases by the trunk call
processes, and change operating system algorithms for critical resource allocation. The
changes made in this MR have greatly improved the controller’s ability to handle overloads
and recover gracefully.
4.
In DK3.0, support was added for originating group security strings on speedcall addresses.
Everything was set up so that StarKeeper could administer this field, but it was blocked
until they were ready to do so. SKIM support for security strings on the billing address was
also blocked. StarKeeper has now requested that we allow SKIM processing in these cases.
5. When the billing connection was brought back up after being down, the billing channel
header displayed a message indicating that a negative number of billing records had been
discarded. The problem has been isolated and fixed.
6.
There are some early alarms generated if there are problems when retrieving a database.
These alarms were getting lost. The problem has been fixed.
7.
There was a problem with data being sent to StarKeeper for the enter trunk ... command.
The ENABLE/DISABLE LINK MEASUREMENT field should send either y for yes, or n for
no to StarKeeper. StarKeeper was receiving a null instead. The problem was seen with the
T1 and PQ trunks. The problem has been fixed.
- 19 -
8. When a user was upgrading to a new release and running the disk certifier diagnostic to list
disk defects, they got an error message saying that "Defects exceed buffer space". That problem has been resolved.
9. The year 1997 was added to the copyright message that appears at boot time.
10. The message displayed at boot time was changed to include the new product name of
BNS-2000 VCS.
11. When users were connected to the B port and accessing the MRCM, and then connected to
the standby CC, they found that no commands could be executed. The problem has been
fixed so that commands can now be executed properly from the B port.
12. Occasionally after a period of heavy load on a node, the node would panic and the following alarm would be displayed:
*C REPORT PANIC!! Unexpected supervisor bus error
This problem also sometimes happened when an ISN concentrator was attached. This
problem was isolated and fixed.
13. The LED on a standby CC appropriately went out when the controller slots were changed
via the change node command. However, when a change node command was executed
again, and the controller slots were configured to reflect the current position of the CC, the
ONLINE LED light did not come on. The problem has been fixed.
14. Occasionally a user would type characters at the console, and instead of those characters
being displayed, commands typed earlier at the console would appear. This problem has
been isolated and fixed.
15.
A problem was experienced when changing the tape cartridge in a tape drive. The first
attempt to access the tape always failed, whether the tape device used was block or character. The second attempt to read to or write from the tape worked correctly. This problem
has been fixed.
16.
There was a problem where alarm #7013 was coming out every hour on the hour for some
nodes. The text of the alarm is as follows:
**7013
REPORT ALARM: Controller was overloaded.
Rec act: Reduce load on controller.
This alarm by itself is only an indicator of potential problems, and it should be interpreted
in the light of other error indicators. Because the alarm was often being generated
unnecessarily, we fixed a sensitivity bug in the detection mechanism.
17. References to AT&T have been changed to Lucent Technologies in the copyright message
and in the output of various commands.
18.
Under certain conditions, the IEP connection to StarKeeper could not be made. The controller was sending an invalid response. The problem has been isolated and fixed.
19.
An alarm will now be generated when the install registration command is not run
promptly on a node. The text of the alarm is as follows:
7112
** REPORT ALARM: skforker: This software is not fully operational.
Rec act: Enter install registration for detailed guidance on
software registration.
20.
A user’s node did a switchover after any of 3 alarms were generated. The first was Alarm
#7008. The text of the alarm is as follows:
- 20 -
*7008 MODADDR= MODTYPE=
REPORT ALARM: stat: Channel range error detected by switch.
Rec act: See Messages Reference Manual
The next alarm was Alarm # 7004, the text of which follows:
*7004 MODADDR= MODTYPE=
REPORT ALARM: stat: To bus parity error detected by switch.
The third alarm was Alarm #7024, which reads as follows:
*7024 MODADDR= MODTYPE=
REPORT ALARM: Indeterminable error: channel range or envelope parity.
Source=<source>
After the node generated any of the alarms, it rebooted, causing the switchover. The problem has been fixed.
21.
An enhancement was made to the Session Maintenance feature that would allow it to be
turned on or off from the node console. The following commands were added to the command set:
remove sm
restore sm
22. The help screens were modified for the remove and restore commands in order to reflect
the addition of the remove/restore sm commands to the command set.
30.2 SLM Module
1. When an SLM module was installed in a CCM node, the off-line diagnostics failed. The
diagnostics worked correctly when the module was in an ECPU node. The problem has
been isolated and fixed.
30.3 LAN Protocol Module (LPM)
1. When executing the dmeas lpm dlci <mod> <port> <dlci> command on an out-of-service
dlci, sometimes garbage was printed out instead of the correct dlci number in the following
error message:
Measurements not available for module 37 port 1 dlci <garbage>
The problem has been fixed.
2. Inverse ARP support has been configured for a DLCI on an LPM, but if the remote IP
address learned from the remote endpoint is not on the same sub-network as the FR port
for this DLCI, the dstat lpm dlci report will show neterr in the RMT IP ADDR STATUS
field for this DLCI. The remote endpoint that the DLCI connects to must be on the same
sub-network as the DLCI.
3.
There was a problem that was occasionally seen when executing the diag lpm on ... and
choosing the ping option. If the physical connection was temporarily broken for any reason,
the PING statistics showed the correct number of packets received and transmitted, but an
incorrect percentage of packet loss. The problem has been fixed so that the percentage of
packet loss will now be correct.
4.
A problem was found internally with the reporting of LPM route status. A user had 3
routes set up on a FRMport on an LPM. These routes were correctly designated as "best" in
the output of the dstat lpm route <module> command. However, after that FRMport on the
LPM was removed from service, and the command was run again, only one of the routes
was correctly designated as "unavailable", and the other two were incorrectly shown to still
be "best". The problem has been fixed.
- 21 -
30.4 X.25P and X.75 Services
1.
An enhancement was made to the X.25P module which provides the opportunity for users
to configure an interframe delay of 0, 4, 8, or 12 characters at 64Kbps. This interframe delay
can be configured when entering an X.25P port. The new port-level prompt is called
MINIMUM INTERFRAME FLAGS. This enhancement was made at the request of a specific
customer.
2. When the init hard command was executed on a node with a large number of downloadable modules, the X.25 modules failed to come back into service. The following alarm message was displayed at the console for those modules:
**8073 MODADDR=<number> MODTYPE=X.25
REPORT ALARM: syncmaint: Module failed to respond during initialization
That alarm was followed by:
**8613 MODADDR=<number> MODTYPE=<number>
REPORT ALARM: config: Module removed
The problem has been fixed.
3.
There was a problem seen when changing multiple X.25P/X.75 ports, one after another.
Although the user was prompted each time for either extended or normal, after all ports
were changed and a verify X.25P port ... command was executed, whatever value was
chosen for the first port changed (normal or extended) was propagated to all the other ports
changed.
30.5 Frame Relay Module (FRM) and LAN Protocol Module (LPM)
1. When a user executed the dmeas frm dlci .... command for an out-of-service dlci on a FRM
or an LPM module, an informational message was displayed indicating that measurements
were not available. After that message, the following instruction was displayed:
Use the "VERIFY" command to determine out of service dlci’s.
The word VERIFY has been changed to lower case letters, verify, so that it is consistent
with other commands and with the convention that a command cannot be entered in upper
case letters.
2.
A previous fix to not print far end measurements for CHT1 FRM if loopback rec=no had
broken far end measurements printing for CHE1 at all. This was made so that far end headings and measurements do not print for T1 with loopback rec=no.
3. When the FRAT removes a DLCI from service, it needs to clear the ON_HOLD flag. This
change also applies to the LPM module.
4. The output of the dstat frm ... command was out of alignment for the following FAR END
fields: CODE VIO, ERRD SECS, SEVRE ERRD SECS, AND SEVRE ERRD FRAME SECS.
The problem has been fixed.
5.
A new requirement was added to section D.5.2 regarding non-receipt of a STATUS message
in a polling interval after transmission of a STATUS ENQUIRY: "if the unanswered
STATUS ENQUIRY requested Full Status, the user equipment shall again request Full
Status." The Frame Relay implementation was updated to meet this requirement.
6.
An incorrect termination of a loop for iop/frm caused some frames to be processed that
were supposed to be ignored. The problem has been resolved.
7. This was a fix for the sleeping DLCI problem. In a configuration with 2 FRMs using NNI,
data was sent from 1 FRM module to the second FRM module, but the second FRM module
did not send it to the router. To clear the problem, a remove/restore frm ... command was
executed. This problem was seen with both CHT1 and V.35 modules. This problem has
- 22 -
been fixed.
8.
After completion of the diagnose frm on-line <mod> link internal_port test, the CONTINUE TESTING [yes, no: +(yes)]: prompt appeared. However, if yes was selected, the
internal_port test was run again. What should have happened was that the list of available
tests for link diagnostics should have been displayed, giving the user the opportunity to
select another test. This problem has been isolated and fixed.
9.
A problem was found internally with the dmeas frm dlci ... command. The command was
executed on a receiving dlci, and the following error message was generated:
Measurement request for module <number> returned error; report will be incomplete.
Measurement request for module <number> port <number> dlci <number> returned
error; report will be incomplete.
The output for the command started to come out, and then the following error message was
displayed:
COMMAND FAILED: EXITED PREMATURELY: REASON 2
No data available for this section
The console remained in a hung state until the delete key was hit. The problem has been
fixed.
10. The output of the dmeas frm ... command was occasionally incorrect in the PEAK MAIN
UTILIZATION field for dlci’s. The problem occurred when the load decreased in the middle of a 5 minute interval to a load that was less than the last reported CURRENT UTILIZATION, but higher than the PEAK UTILIZATION. The problem has been fixed so that the
PEAK MAIN UTILIZATION is calculated correctly.
11.
A customer experienced problems with a channelized FRM. The FRM would not respond to
commands or to polls for measurements. If erroneous data came in over a port, the module
would hang. The problem has been fixed.
12.
A customer was losing link integrity on channelized FRM ports on an intermittant basis.
The only way to restore the link integrity was to remove and restore the ports. This problem was only seen with CHT1 modules. This problem has been isolated and fixed.
13. This was the memory pointer fix for the module reset problem. Frame Relay modules were
resetting while in buffer congestion. After the reset, the FRM modules were automatically
re-downloaded by the controller, and the PVCs were re-setup. This problem was seen with
both CHT1 and V.35 modules. This problem has been fixed.
14.
A user reported a problem when trying to delete a range of multicast dlci’s. The following
error message was generated:
COMMAND FAILED: EXITED PREMATURELY: REASON 9
All of the dlci’s were not deleted. The problem has been isolated and fixed so that when
deleting a range of multicast dlci’s, all the dlci’s specified get deleted.
15. When there were no DLCI’s configured for a Frame Relay Module or a Lan Protocol
Module (LPM), scheduled measurements failed to come out. This problem has been isolated
and fixed.
30.6 DKAP Module
1. When a range or list of dkap modules was changed, and the number of channels was different for them, there was a bug that allowed the change to be made. In addition, it changed
the value of the number of channels on all the modules to be that of the last module in the
list changed. The change should not have been allowed. The problem has been fixed.
- 23 -
2. When entering the channel sets for a DKAP module, an incorrect channel range was
displayed. If a module was configured for 100 channels, and the user executed the enter
dkap channelset .. command, the prompt for NUMBER OF CHANNELS PER CHANNEL
SET was incorrect. The prompt displayed the range of 1-507, even though only 100 channels
were configured for the module. The problem has been fixed so that the correct number of
channels will now be displayed.
3. The DKAP module was using an invalid default number of channel sets. If the module was
configured for 100 channels, the first time a user entered a channel set, the default for
number of channels per channel set was 100, which was correct. However, after 1 channel
was specified and the user entered another channel set, the default for the number of channels per channel set should have been 99, not 100. The problem has been fixed.
30.7 TSMT1 Module
1.
An enhancement has been made to the TSMT1 so that, if a port is configured to use GOS 5,
a new prompt will be issued giving the administrator the option of NOT stripping the CRC.
Since the CRC is not stripped on ingress nor regenerated on egress, if data corruption is
undetected for any reason, a good CRC will not then be inadvertently put on corrupted
data. Note that no change is made to the CRC handling of GOS 3 ports.
2.
A problem was reported after TSM8’s were replaced by TSM-T1’s or Frame Relay Modules.
The response of the TSM-T1 or the FRM to an unrelated network problem (data loss on
SWTs) caused the module to stop transmitting on the backplane to the other end of the call.
The fault was not in the interface to the attached equipment. In order to clear the problem,
the port had to be removed and restored to service. This problem has been isolated and
fixed.
31. BUILD 53 THROUGH BUILD 54 MODIFICATIONS
31.1 Control Computer
1. The kernel raw URP driver was trying to echo every packet. Although the unnecessary
echoes went out as NULLs, they caused extra overhead. The problem has been fixed.
2. The new disk used for Release 6.0 ECPU nodes, the ST51080N, could not be used to run the
diag cert command when used with Release 6.0 ECPU or with prior releases. A change has
been made so that the disk will now support execution of the diag cert command in Datakit
4.0, 5.0, and in BNS-2000 6.0.
3. During load testing, some processes aborted, and the following message was displayed on
the console:
Supervisory stack overflow or user meddling killed curproc - xxxxxx
A Usart interrupt caused the supervisory stack overflow, and the problem has been fixed.
4.
Strange output was occasionally observed when running the DIAG/DISK test and choosing the /f3DRIVE ACCESS DIAGNOSTIC / ALL OF THE ABOVE test for the Secondary
Tape Drive. The secondary tape drive existed, but had no tape in it. The DRIVE DATA
BUFFER ACCESS TEST would generate the following output:
Byte mode data mismatch for Secondary Tape
Data expected = 4, Data received = 52
Byte mode data mismatch for Secondary Tape
Data expected = 5, Data received = 43
The above error messages would continue for about a page, and then the DRIVE DATA
BUFFER ACCESS TEST would fail. The problem has been fixed.
5.
Internally, some problems were occasionally found with the backup tape ... command.
When a tape was write-protected, no error message came to the console advising the user
- 24 -
that the backup failed. After the user removed the write-protection, the backup tape .. and
init controller commands didn’t complete successfully without manual intervention.
Finally, in the above situation, the node had to be rebooted with the tape in the drive in
order for the backup tape command to execute successfully. These problems rarely
occurred, but they have been fixed.
6. The backup and save areas of the standby (secondary) disk became unreadable via the dstat
cc .. report when the power was removed from the disk by powering down a CCM node or
the CCM module, or by removing the standby disk in an ECPU system. The workaround
for the problem was to execute an init controller command, or to turn on the automatic
backup feature. The problem has been fixed.
7.
There was a problem with the dmeas ... output for the TSMT1, V.35 FRM, CHT1 FRM, and
the HSCPMML modules. The packet counts were sometimes incorrect because they were
not being zeroed out at the appropriate time. In addition, the list of modules that may
reside in a concentrator was incomplete. These problems have been fixed.
8.
A change was made to the output of the verify trunk ... command for T1 trunks. The output
of that command has been modified so that when trunk billing is enabled for a node, and
the verify trunk .. command is executed for a T1 trunk, the line that says: CONNECTTIME BILLING: OFF will not be displayed. The output of the verify trunk .. command for
T1 trunks will now be similar to that for PQ trunks in that respect.
9.
A problem was found when all the downloadable modules in a node requested a TEXT and
CONFIGURATION download at exactly the same time. This problem was seen on nodes
having a large number of downloadable modules, when they were upgraded to a new build
or a new release. Some modules failed to download. Occasionally, some nodes with a large
number of downloadable modules would hang during the upgrade. Now the nodes no
longer become hung in that situation.
10.
Alarm #8456 was incorrectly formatted. The problem has been fixed so that the alarm comes
out now with correct spacing.
11.
If a user tried to restore a non-existent module through StarKeeper, the following error
message was displayed:
Module address<module number> contains a(n) BS BS BS BS BS no module.
(<Module type> expected).
The BS above is a backspace character. On the console, the message would read:
Module address<module address> contains no module.
On StarKeeper or a printer, the backspace characters were displayed, and they did not perform the erase function that they were supposed to perform. The problem has been isolated
and fixed.
12. When a user executed the change node command, and LINE 1 BROADCAST MESSAGE
was displayed, only a truncated version of LINE 1 was displayed. This problem occurred
only in cases where all 3 lines of the broadcast message were very long. The problem has
been isolated and fixed.
13.
A customer reported a problem with the verify module <module #> command when it was
executed for an X.25P module. Partway through the output, the following error message
was displayed:
MESSAGE TOO LONG - FORCING BREAK: DATA LOST
After the error message, and the loss of some data, the output continued to completion. The
problem has been fixed.
- 25 -
31.2 Switched Bisync Interface Module (BSC)
1.
A user reported that the
dstat bsc3270 terminal <module> <port> <cu> 1-32 high
command only generated information for the first 16 terminals, instead of for all 32 terminals, as requested. Terminals 17-32 were listed in the output, but instead of the correct
information, only UA was printed after each one. After generation of output for the terminals, the command exited prematurely, and the following error message was displayed:
Cannot expand the storage space for transaction; report will be incomplete.
Insufficient storage space; report will be incomplete.
The problem has been fixed so that correct output for all 32 terminals will now be
displayed.
2.
A user reported that the Switched Bisync NULL WRITE feature no longer worked. Two
symptoms of the problem were that there was no response to any data that was sent, and
the user was unable to get the DESTINATION: prompt. The problem has been isolated and
fixed.
31.3 Synchronous/Asynchronous Multiplexer (SAM)
1. When all ports on a SAM were already entered, and the user tried to enter a port, the
wrong error message was displayed:
INPUT ERROR: Module <mod #/mod #> port <port #> is already entered.
The correct error message that should be displayed is:
All ports are entered for module <module #>.
The correct error message will now appear.
31.4 Frame Relay Module (FRM)
1.
A problem was found internally where the output of the dmeas frm dlci ... command did
not show extended measurements for a Frame Relay Module. The Module was a FRM (M1)
in a concentrator, and had the Extended DLCI Measurements enabled. StarKeeper received
the extended measurements fields, but dmeas was not reporting them. The problem has
been fixed.
2.
There was a performance problem with the X.25P and the FRM modules. If there were originate and receive channels and traffic was going in both directions, the module would
eventually hang. This problem only occurred at low speeds, such as 56K or 64K. The problem has been isolated and fixed.
3.
A change has been made to the DATA LINK CONNECTION IDENTIFIER prompt in the
verify frm dlci ... command. Previously, that prompt contained both pvc and multicasting
DLCIs specified in one range. Now, this prompt will have the PVC DLCIs (16-1022)
separated from the multicast DLCIs (1019-1022), and will appear as follows:
DATA LINK CONNECTION IDENTIFIER [16-1007, 1019-1022: +(16-1022)]:
4.
An enhancement was made to the FRM measurements output. The BYTES field in the output of the dmeas frm ... command has been expanded to 9 digits. The expanded column
width would provide room for the maximum number of bytes possible at T1 speed for an
hour. Prior to the enhancement, ***** would print for that field whenever the byte count
exceeded one billion.
- 26 -
5.
Some users were occasionally experiencing link resets. This occurred on channelized Frame
Relay Modules that were configured for full T1s. When the problem did occur, there was
usually heavy traffic, consisting of small frames. The problem has been fixed.
6.
A problem occurred when a user executed the following command with repetitions:
diag frm online facility jack out-of-band
There were cases when only the first repetition worked, and then the following message
was displayed:
Diagnose completed. Test failed: facility failure (rfa).
The problem has been fixed.
7.
A problem was found internally with FRM diagnostics. When executing the diag frm online facility payload qrs .. test, the user hit the delete key during the time the test was being
set up. That caused the module and the controller to get out of sync, causing one of a few
different error messages to be displayed. Two of the error messages seen were:
Diagnose completed - test failed;
Facility failure ()
and also
Diagnose not completed - module <module #> unknown error code: 0
The problem has been isolated and fixed.
8. When a user executed the diagnose frm on-line internal_port ... command, the following
information was displayed on the console:
INFO: Before continuing, remove all external equipment from port being tested.
If the user removed the external equipment, the internal_port test would fail. The problem
has been fixed.
31.5 Lan Protocol Module (LPM)
1.
A problem was found internally when a user was entering lpm routes. Occasionally, when
the user executed the verify lpm route ... command, previously entered routes failed to be
displayed. When the same command was executed at a later time, sometimes the previously entered routes were again displayed. The problem has been fixed.
31.6 X.25 and X.25P Services
1.
A customer occasionally encountered problems in bringing up the link on an X.25P module.
This occurred with the Black Box SME V.35. Although the modem eliminator was asserting
DCD, the X.25P module did not detect DCD on the port, and therefore, the link would not
come up. The problem has been isolated and fixed.
2.
There was a problem found internally with getting packet level restart to occur between an
X.25P module and a 5ESS TN82B board for the Billdats application. The problem has been
fixed.
3.
There was a problem that was occasionally seen with the X.25P module. It happened when
call user data was included in a CALL ACCEPT packet, and the packet size including the
user data was less than 128 bytes. Sometimes, under those circumstances, buffers were
stranded. After a while, buffer congestion would occur, there were not enough buffers to
set up new calls, and the module would have to be removed and restored. The problem has
been fixed.
4.
There was occasionally a problem with X.25P data transfer. The problem happened sometimes when a user was using D bits on data packets, which means that end to end acknowledgement of data packets was required. The customer would have sometimes seen a
- 27 -
delay in opening a session on their application. The session would open, however, after the
delay. The problem has been isolated and fixed.
5.
There was a problem found when executing the dstat x.25p .... command on an out of service RS232 port of an X.25P module. The output of the command showed that the expected
service state was "out of service", but showed the actual service state as being "in service",
and the operating state as "up". If a port is out of service, both the expected and the actual
service states should be "out of service", and the operating state should be "down". This
problem has been fixed.
6.
An enhancement was made to the X.25P module. Prior to the enhancement, it was only possible to change the destination of a PVC on an in-service port of an X.25P module on which
only PVC’s were configured. The call would come down and then be established to the
new destination. The enhancement allows a user to also change the X.3 profile of the PVC
on an in-service port. It works as before, in that the call will be taken down, and will then be
established again, this time using the new X.3 profile.
7.
A user had an X.25 PVC with a destination using 4 levels of addressing. The PVC did not
come up, and the orignating end remained in the auto-wait state. The problem has been
fixed, and destinations with 4 levels of addressing now work correctly.
31.7 Multispeed Module (MSM)
1.
A user tried to restore MSM ports in an MPC 7 that was out of service. The following error
message was displayed:
Restore failed; system too busy to process module <conc #/module #>
Try again later.
The module number referenced in the above error message was not the correct module
number. The problem has been fixed.
31.8 DKAP Module
1.
A customer reported a problem when trying to change a range of DKAP modules. The
modules were not configured identically, and after the change, the number of channels was
set to the same value for all the modules in the range, although it had been different for
each module before the change. The change should not have been allowed since the
modules were not configured identically. This problem has been fixed.
- 28 -
CONTENTS
1. DOWNLOADABLE MODULES VERSIONS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2. UPGRADE INSTRUCTIONS .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
3. YEAR 2000 SUPPORT .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4. DT-4000
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
5. UMI SUPPORT
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
6. BUILD 91 MODIFICATIONS
6.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
7. BUILD 90 MODIFICATIONS
7.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
8. BUILD 89 MODIFICATIONS
8.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
9. BUILD 88 MODIFICATIONS
9.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
10. BUILD 86/87 MODIFICATIONS
10.1 Control Computer
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
11. BUILD 85 MODIFICATIONS
11.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
12. BUILD 84 MODIFICATIONS
12.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
13. BUILD 83 MODIFICATIONS
. .
13.1 Control Computer
. . . .
13.2 X.25, X.25P and X.75 Services .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
14. BUILD 82 MODIFICATIONS
14.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
15. BUILD 80 MODIFICATIONS
. .
15.1 Control Computer
. . . .
15.2 X.25, X.25P and X.75 Services .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
16. BUILD 79 MODIFICATIONS
. .
16.1 Control Computer
. . . .
16.2 X.25, X.25P and X.75 Services .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
17. BUILD 78 MODIFICATIONS
17.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
18. BUILD 77 MODIFICATIONS
18.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
19. BUILD 76 MODIFICATIONS
. .
19.1 Control Computer
. . . .
19.2 X.25, X.25P and X.75 Services .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
20. BUILD 75 MODIFICATIONS
. .
20.1 Control Computer
. . . .
20.2 X.25, X.25P and X.75 Services .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
21. BUILD 74 MODIFICATIONS
21.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
.
.
.
.
.
.
.
-i-
21.2 X.25P Services .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
22. BUILD 73 MODIFICATIONS
22.1 Control Computer
. .
22.2 TSM8 Module . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
23. BUILD 72 MODIFICATIONS
. . . . . . . .
23.1 Control Computer
. . . . . . . . . .
23.2 MSM Module . . . . . . . . . . . .
23.3 TSM8 Module . . . . . . . . . . . .
23.4 Synchronous/Asynchronous Multiplexer (SAM)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
10
24. BUILD 71 MODIFICATIONS
24.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
25. BUILD 70 MODIFICATIONS
25.1 Control Computer
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
26. BUILD 67 THROUGH BUILD 69 MODIFICATIONS
26.1 Control Computer
. . . . . . . . .
26.2 X.25P Services . . . . . . . . . . .
26.3 Frame Relay Module (FRM) . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
10
27. BUILD 63 THROUGH BUILD 66 MODIFICATIONS .
27.1 Control Computer
. . . . . . . . . .
27.2 Frame Relay Module (FRM) . . . . . . .
27.3 MSM Module . . . . . . . . . . . .
27.4 LAN Protocol Module (LPM) . . . . . . .
27.5 X.25 and X.25P Modules
. . . . . . . .
27.6 Synchronous/Asynchronous Multiplexer (SAM)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
12
12
12
13
13
28. BUILD 61 THROUGH BUILD 62 MODIFICATIONS .
28.1 Control Computer
. . . . . . . . . .
28.2 SLM Module . . . . . . . . . . . .
28.3 Switched Bisync Module (BSC) . . . . . .
28.4 TSMT1 Module
. . . . . . . . . . .
28.5 DKAP Module . . . . . . . . . . . .
28.6 Frame Relay Module (FRM) and FRM-M2 Module
28.7 X.25P Services . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
14
14
14
14
14
15
29. BUILD 60 MODIFICATIONS
.
29.1 Control Computer
. . .
29.2 Frame Relay Module (FRM)
29.3 LAN Protocol Module (LPM)
29.4 X.25 and X.25P Services . .
29.5 DKAP and HSDKAP Modules
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
16
17
17
30. BUILD 55 THROUGH BUILD 59 MODIFICATIONS . . . . .
30.1 Control Computer
. . . . . . . . . . . . . .
30.2 SLM Module . . . . . . . . . . . . . . . .
30.3 LAN Protocol Module (LPM) . . . . . . . . . . .
30.4 X.25P and X.75 Services . . . . . . . . . . . . .
30.5 Frame Relay Module (FRM) and LAN Protocol Module (LPM)
30.6 DKAP Module . . . . . . . . . . . . . . . .
30.7 TSMT1 Module
. . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
20
20
21
21
22
23
31. BUILD 53 THROUGH BUILD 54 MODIFICATIONS .
31.1 Control Computer
. . . . . . . . . .
31.2 Switched Bisync Interface Module (BSC) . . .
31.3 Synchronous/Asynchronous Multiplexer (SAM)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
25
25
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- ii -
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31.4
31.5
31.6
31.7
31.8
Frame Relay Module (FRM)
Lan Protocol Module (LPM)
X.25 and X.25P Services . .
Multispeed Module (MSM)
DKAP Module . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
- iii -
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
26
27
27
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement