Consumer Access Solutions

LoopCare™ Test OSS

System Administration Guide

Revision Q
Release 2.15
December, 2006
040-0362
System Administration Guide

ELECTRONIC EMISSION NOTICE

Federal Communications Commission (FCC) Statement

Warning: The hardware provided with the LoopCare Testing System generates, uses, and can radiate radio
frequency energy and if not installed and used in accordance with the instruction manual, may cause interference to
radio communications. The hardware has been tested and found to comply with the limits for a Class A computing
device pursuant to Subpart J of Part 15 of FCC Rules. These rules are designed to provide reasonable protection
against such interference when the hardware is operated in a commercial environment. Operation of this equipment
in a residential area is likely to cause interference, in which case the users, at their own expense, will be required to
take whatever measures necessary to eliminate the interference.

NOTICE: Every effort has been made to ensure that the information in this manual is complete and accurate at the
time of printing. However, information is subject to change without notice.

LoopCare is a trademark of Tollgrade Communications, Inc.

DigiTest is a registered trademark of Tollgrade Communications, Inc.
EDGE is a trademark of Tollgrade Communications, Inc.

All other trademarks and copyrights are property of their respective owners.

All figures, screen images, results and diagrams contained in this manual are examples for reference purposes only.
Operational results may vary depending on the configuration of and conditions existing on your telecommunications
system.

This document contains proprietary information that shall be distributed or routed only within Tollgrade
Communications, Inc. and to its authorized clients, except with written permission of Tollgrade.

© 2006, Tollgrade Communications, Inc., All Rights Reserved

PROPRIETARY – TOLLGRADE AND AUTHORIZED CLIENTS ONLY

Tollgrade Communications, Inc. Phone: 412-820-1400 0

493 Nixon Road Fax: 412-820-1530 0
Cheswick, PA 15024 Technical Support: 800-777-5405 r
412-820-1498 8
Orders: 412-820-1305 5
Web Site: www.tollgrade.com c

Revision Q (p/n 040-0362) Release 2.15, December, 2006 ii

 System Administration Guide

About this Guide xi

• About this Guide xi

• Organization of This Guide xiii
• Related Documentation xv
• Ordering Documentation xvi

1 User Administration 1-1

• Introduction 1-2
• Setting Up User Terminals 1-4
• Setting Up Line Printers 1-7
• HP Jet Admin Printer Setup 1-13

2 LoopCare Administration 2-1

• Introduction 2-2
• Customizing System Files 2-3
• Updating the Priority Table 2-6
• Performing an NPA Split 2-11
• Batch ADSL Pre-Qualification Testing 2-24
• Calibrating a DLC Bypass Pair 2-52
• Calibrating a Switch for Loop Insertion Loss 2-53
• Wideband Testing Feature 2-55
• HUB Alarm Handler 2-58
• Calibrating HUB TMU MDF Trunks 2-60
• Calibrating the Siemens EWSD Switch with Integrated Testing 2-61

3 System Operation 3-1

• Introduction 3-2
• HP System Backup 3-3
• SUN System Backup 3-6

Revision Q (p/n 040-0362) Release 2.15, December, 2006 iii

System Administration Guide

• Database Backup and Recovery 3-17

• Database Recovery 3-23
• LoopCare Failover 3-33

4 Performance Monitoring 4-1

• Introduction 4-2
• Measuring DCN/LCN/LTCN Message Traffic 4-3
• Statistics Logging & Collection 4-4
• What TREAT Can Tell You 4-15
• Testing Activity Feature (TAF) 4-16
• LTE.ERR 4-39
• OPENSLOG.STAT 4-40
• LoopCare Activity Report Generator (LARGE) 4-41
• Testing Activity Report Enabler (TARE) 4-54
• Activation of the TARE Oracle Database Feature 4-59
• Customized Report Service 4-64
• VER 99 Improvement Feature 4-65
• The OE.STAT Report 4-68
• CPU Utilization and Related Statistics 4-70

5 Maintenance 5-1
• Overview 5-2
• Buffer and Module Tracing 5-3
• Save System Information for Diagnosing Hangs 5-5
• Trouble Clearing Strategy 5-6
• Hourly Reports 5-10
• Sizing a Standalone LTS 5-16
• Test Trunk Troubleshooting 5-19

6 ORACLE Database Architecture 6-1

iv Release 2.15, December, 2006 Revision Q (p/n 040-0362)

 System Administration Guide

• Oracle Architecture 6-3

• Database Backup Types Available 6-10
• Automated User Definable Backup 6-14
• Suggested Backup Strategies 6-21

7 Replication Administration 7-1

• Introduction 7-2
• Replication 7-3
• Creating a Replicated Environment 7-10
• Propagating Changes Between Replicas 7-18
• Resolving Out-of-Sync Databases 7-21
• Troubleshooting Replication 7-30
• Disabling OAM and MLT UIP Functionalities 7-43
• Warm Standby Server Configuration 7-44
• Hot Standby Server Configuration 7-51

8 End User GUI Verification, Configuration, and Customization 8-1

• Introduction 8-2
• HP-UX 10.20 Systems 8-3
• HP-UX 11.00 and HP-UX 11.11 Systems 8-6
• Sun Solaris Systems 8-8
• System Configuration for GUI 8-9
• Group Administration 8-12
• User Administration 8-14
• Introduction 8-15
• Customizing the GUI for Groups of Users 8-16
• Customizing the GUI for a User 8-18
• Modifying Logo GIF Files 8-20
• Customizing the Welcome to LoopCare Page 8-22
• Technical Support Page Customization 8-24
• Maintain Locally Managed VER Code and AID Files 8-25
• Modifying the Tip, Ring, and Ground Labels 8-26

Revision Q (p/n 040-0362) Release 2.15, December, 2006 v

System Administration Guide

9 Administering Batch Testing 9-1

• Introduction 9-2
• Batch Schema Activation 9-3
• Configuring MGRP.gdf Modules 9-5
• Specifying Report Retention 9-6
• Specifying VER Codes 9-7
• Authorizing Users 9-9
• Creating a Batch List 9-11

10 Administering IVR 10-1

• Introduction 10-2
• Verifying IVR Status 10-3
• Registry Settings 10-4
• Log Files 10-16
• Interruptions of IVR/LoopCare 10-20

11 Administering Software Downloads to Tollgrade Test Devices 11-1

• Introduction 11-2
• Software Download Configuration File 11-3
• Downloading an Alternate Software Version 11-8
• Tollgrade Software Download Files 11-9
• DMU, DMU+, DWU, Ethernet Option Card Download Process 11-11
• EDGE Download Process 11-16
• HUB Download Process 11-20
• Download Status Conditions 11-23

12 Entering a new LTE (Switch and RMU), RMU, RMU Offset, RMU-Tested
EAIU Group12-1

vi Release 2.15, December, 2006 Revision Q (p/n 040-0362)

 System Administration Guide

• Introduction 12-2
• Entering a new Switch-LTE 12-3
• Entering a new RMU 12-5
• Determining the RMU Offset 12-9
• Adding a new RMU-Tested EAIU Group 12-14

A Group Descriptor Files A-1

• Introduction to GDF Files A-1
• Group Descriptor File for the MLT Group A-5
• Group Descriptor File for the MDMN Group A-18
• Group Descriptor File for the MGRP Group A-30
• Group Descriptor File for the M2 Group A-77
• Group Descriptor File for the MPST Group A-87
• Group Descriptor File for the ISDN Group A-96
• Group Descriptor File for the CGRP Group A-103

B User-Definable Environmental Variables B-1

• System Environmental Variables and Paths B-1
• MLT.env B-4
• MDMN.env B-7
• MGRP.env B-18
• M2.env B-37
• MPST.env B-45
• ISDN.env B-46
• CGRP.env B-47

C NPADEF Template C-1

• NPADEF Template C-1

Revision Q (p/n 040-0362) Release 2.15, December, 2006 vii

System Administration Guide

D Setting Up Printers D-1

• Introduction D-1
• Required Software Changes for Adding a Printer D-2

E Additional Procedures for CORBA API E-1

• Introduction E-1
• Verify Test Requester API Features E-3
• Configure IOR Files Without Headers E-4
• Configure Servers for Fixed TCP Ports E-5
• Configure Servers for Fixed IP Address or Host Name E-7
• IOR Reference Files E-9
• Visibroker Variables E-10
• Modify the MGRP.env File E-12
• Modify the CGRP.env File E-13
• Verify Data Requester API Features E-15
• Administering Multiple NSDBs E-16

F The Customer Environment Screen F-1

• Introduction F-1
• Usage F-3
• Additional Customer Information Page F-9
• Make Your Changes Effective F-13

G Procedure to use after running basegen G-1

• Introduction G-1

viii Release 2.15, December, 2006 Revision Q (p/n 040-0362)

 System Administration Guide

H Using the mltctrl Script H-1

• Introduction H-1

I The cgiReportsClean.sh Script I-1

• Introduction I-1

J BASE Commands J-1

• Managing Groups J-1

K Additional Procedures for SOAP API K-1

• Introduction K-1
• LoopCare K-2
• Apache Tomcat K-3
• Deploying SOAP Tester Services K-4
• Testing the SOAP Installation K-5

L ASCII Text File and SOAP API for Test By TN Feature L-1
• Introduction L-1
• ASCII Text File L-2
• Deploy SOAP API for Test By TN L-3

Revision Q (p/n 040-0362) Release 2.15, December, 2006 ix

System Administration Guide

x Release 2.15, December, 2006 Revision Q (p/n 040-0362)

About this Guide 0

About this Guide

Overview This section describes the purpose and organization of this guide, the intended
audience, conventions used, and related documents.

Purpose The LoopCare™ Test OSS Test Operations Support System (LoopCare) System
Administration Guide provides instructions for administering users and user
terminals, modifying the LoopCare UNIX file system, performing backup and
recovery procedures, and for checking system performance and diagnosing
system problems that occur.

LoopCare is an automated test system that tests and analyzes POTS, DLC, and
ISDN telephone lines and equipment in support of loop maintenance operations.

Intended Audience This guide is intended for the following LoopCare audience:
• System administrators
• Database administrators
• Facility managers

Revision Q (p/n 040-0362) Release 2.15, December, 2006 xi

System Administration Guide

Required Skills LoopCare Administrators should have a working knowledge of:

• Basic Telephony and DSL service delivery
• The use of Personal Computers (PC) and PC software, including MS-
Microsoft Windows and applications for accessing the Internet, such as
web browsers.
• The UNIX system user interface.
• UNIX shell scripts.
• Local area networks, particularly administration concepts for IP networks.
• PC and LAN security concepts.
• Oracle database administration, backup and recovery, performance tuning,
and SQL.

xii Release 2.15, December, 2006 Revision Q (p/n 040-0362)

 System Administration Guide

Organization of This Guide

This guide is organized into eight chapters and six Appendices:

• About This Guide
Describes the purpose, intended audience, and organization of this guide.
• Chapter 1, User Administration
Contains instructions for administering users including adding and deleting
user Ids, and setting up user terminals and printers.
• Chapter 2, LoopCare Administration
Contains instructions for performing application-related tasks that involve
modifying system files including updating the priority table, performing an
NPA Split, and updating GDF files.
• Chapter 3, System Operation
Provides instructions for LoopCare system start and system shutdown;
backup and recovery procedures, setting up the failover feature. Includes
procedures for administering users and setting up terminals.
• Chapter 4, Performance Monitoring
Provides instructions generating reports with statistics that measure
system performance.
• Chapter 5, Maintenance
Contains procedures for diagnosing system problems, setting up the
tracing function, for administering trouble reports, and troubleshooting
problems in the test trunks and related equipment.
• Chapter 6, ORACLE Database Architecture
Provides information on the Oracle database structure and a glossary of
terms used in describing Oracle processes.
• Chapter 7, Replication Administration
This chapter provides instructions for the Oracle Database Administrator
(DBA) to monitor and maintain the Oracle Server capabilities to replicate
data between LoopCare front-ends.
• Chapter 8, End User GUI Verification, Configuration, and Customization
This chapter provides instructions on how to customize the appearance of
the End User GUI.
• Appendix A, Group Descriptor Files
Describes the GDF file structure, individual GDF files and options.
• Appendix B - Environmental Variables

Revision Q (p/n 040-0362) Release 2.15, December, 2006 xiii

System Administration Guide

Describes the LoopCare Environmental Variables and how to modify the

variables.
• Appendix C - NPADEF Template
Provides a template that can be used when performing the NPA Split
procedures in this guide.
• Appendix D - Setting Up Printers
Gives a step-by-step procedure for adding line printers to the LoopCare
configuration.
• Appendix E - Additional Procedures for CORBA API
Provides the procedures necessary if you intend to run the CORBA Test
requester API and Data Requester
• Appendix F - The Customer Environment Page
Provides information on the use of the Customer Environment page for
non-North American environments.

Conventions Used The Following special typeface conventions are used in this guide:
• Italic type is used to show emphasis and to reference chapters within this
guide or to related documents.
• Mono-spaced type is used to indicate information that appears on the
screen.
• Bold type is used to show emphasis.
• A note is used to indicate additional information, a reminder, or a
clarification.

NOTE:
This symbol indicates a note.

• A caution is used when precaution should be taken to avoid interrupting

proper operation of the system.

! CAUTION:
This symbol indicates a caution.

xiv Release 2.15, December, 2006 Revision Q (p/n 040-0362)

 System Administration Guide

Related Documentation

Overview The complete LoopCare Testing System documentation set is listed and
described in the Documentation Installation Guide.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 xv

System Administration Guide

Ordering Documentation

Overview For copies of the LoopCare documents, contact your LoopCare Customer
Support Representative.

xvi Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User Administration 1

Contents

• Introduction 1-2
• Setting Up User Terminals 1-4
• Setting Up Line Printers 1-7
• HP Jet Admin Printer Setup 1-13

Revision Q (p/n 040-0362) Release 2.15, December, 2006 1-1

System Administration Guide User Administration
Introduction

Introduction

Overview This chapter provides instructions for adding and deleting user Ids and for setting
up user terminals with VT100 emulation.

Create Group and The following procedures establish a group name for LoopCare administrative
Userid users, add/delete user ids, and set user permissions in the LoopCare user
environment.

Add Group Name This procedure uses the sam program add a group name.
1. Login as super user.
su - root
passwd:
2. Invoke the HP-UX’s System Administration Manager program.
sam
3. On the System Administration Manager menu, select Users and Groups.
4. Select Groups.
5. Press the Tab key to go to the menu bar.
6. On the Actions menu, select Add.
7. Enter the group name to be added:
8. Press the Tab key to select OK.
9. Press the Tab key to go to the menu bar.
10. Select Exit from the File menu.
11. Press the Tab key to select Exit SAM.

Add Userid Perform the following procedure to add users to the LoopCare UNIX environment.
Also use this procedure to modify or delete user Ids when necessary.
1. Login as super user.
su - root
passwd:
2. Invoke the HP-UX’s System Administration Manager program.

1-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User Administration System Administration Guide
Introduction

sam
3. On the System Administration Manager menu, select Users and Groups.
4. Select Users.
5. Press the Tab key to go to the menu bar.
6. On the Actions menu, select Add.
7. Enter user information for the userid:
8. Press the Tab key to select OK.
9. Press the Tab key to go to the menu bar.
10. Select Exit from the File menu.
11. Press the Tab key to select Exit SAM.
12. Set up the LoopCare environmental variables in the user .profile.
Refer to /mlt/exec/.profile.
13. Set the user permissions as necessary. Go to the next procedure.

Set User Privileges Use the mltlogin.ksh command in the /mlt/install directory to set user
privileges for the LoopCare ADEF and UIP applications:

Usage:

mltlogin.ksh {[-a][-u][-b]} [-l OAM userid] {[-p passwd]} [-s DBA Passwd]

-a is used to add an ADEF user and assign {update privilege}

-u is used to add a UIP user and assign {update privilege}

-b is used to add a BMDB user and assign {update privilege}

• If the password is not specified, the userid must be a valid UNIX user id.
• If the password is given, the OAM userid need not be a UNIX user id.
• The {update privilege} may be U=Update or Q=Query only.
• When the [-p] argument is not given, the UNIX passwd is assumed for an
OAM user.

Example

ksh /mlt/install/mltlogin.ksh -a u -u u -l mlt -s manager

Revision Q (p/n 040-0362) Release 2.15, December, 2006 1-3

System Administration Guide User Administration
Setting Up User Terminals

Setting Up User Terminals

Overview Customers will need to ensure that their terminal or terminal emulation software is
properly set up in order to access each of the areas under the LoopCare OAM.

Terminal Setup Besides the changes that are necessary to set up the communications on the
terminal hardware, the system administrator must verify that the appropriate
terminal information is entered in the termcap and terminfo files on the LoopCare
host machine. Specifically, there should already be included an entry for the
terminal type of VT100.

On the LoopCare host machine, the termcap information is located in the directory
/etc/termcap. The terminfo database can be located in the directory /usr/lib/
terminfo.

Currently, the only supported video display for the LoopCare OAM is the terminal
type of VT100. Whenever a new video display is supported for the OAM,
customers will be responsible to update the termcap and terminfo files on the
LoopCare host machine.

For example, if there were a large number of customers currently using an AT&T
5425 terminal that requires OAM to support this video display, then the following
briefly outlines the necessary activities to be performed by the customers.

Activities on the LoopCare host machine:

1. Add the new terminal information to /etc/termcap file.
2. Add the new terminal information under the directory structure /usr/lib/
terminfo.

Activities on the terminal:

1. Set the communications information under the terminal set up function.
2. Re-map the settings for function keys F1 through F12 under the terminal
set up function.

Activities prior to accessing OAM:

1. Set the correct terminal type during the login procedure.
2. Access the OAM using the command: oam.

1-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User Administration System Administration Guide
Setting Up User Terminals

Terminal Emulation Typically, users with personal computers will have software products installed
Setup which allows them to emulate various video displays. Again, the only supported
video display for the OAM is the terminal type of VT100. The activities performed
on computers that have software installed to emulate various video display’s are
similar to the activities outlined above. Specifically, users will need to correctly set
the communications settings and specify VT100 as the video display to be
emulated by the software product.

Whenever a new video display is supported for the OAM, customers will be
responsible to update the termcap and terminfo files on the LoopCare host
machine.

Terminal Keyboard Users with specific terminals or users with personal computer that can emulate
Setup various terminal displays will need to re-map the settings for each of the function
keys. As a result, an important requirement for any terminal or terminal emulation
package to work with the OAM is having this capability. More specifically, the
following list outlines the basic functionality’s required:
• ability to create a keyboard mapping file
• ability to edit a keyboard mapping file
• ability to display a keyboard mapping file
• ability to save a keyboard mapping file

The keyboard mapping file is either created or edited under the terminal set up
function. Users will need to save changes to the keyboard mapping file.
Afterwards, the user will need to specify this keyboard mapping file in order to be
used for each terminal session. This will allow users to bring up the OAM
application and have the ability to navigate through the various forms of the OAM.

In most cases, users will be required to make changes to terminal session to

either indicate the correct terminal video display or re-map the function key
settings. In the case of building a keyboard map file, users should be able to
display default keyboard mapping setting in order to compare the default settings
to the following required settings. Customer will be responsible to verify these
required function key settings and make what ever changes necessary.

KEY Character Representation

F1 <ESCAPE> [ 1 1 ~
F2 <ESCAPE> [ 1 2 ~
F3 <ESCAPE> [ 1 3 ~
F4 <ESCAPE> [ 1 4 ~

Revision Q (p/n 040-0362) Release 2.15, December, 2006 1-5

System Administration Guide User Administration
Setting Up User Terminals

KEY Character Representation

F5 <ESCAPE> [ 1 5 ~
F6 <ESCAPE> [ 1 7 ~
F7 <ESCAPE> [ 1 8 ~
F8 <ESCAPE> [ 1 9 ~
F9 <ESCAPE> [ 2 0 ~
F10 <ESCAPE> [ 2 1 ~
F11 <ESCAPE> [ 2 3 ~
F12 <ESCAPE> [ 2 4 ~
up arrow <ESCAPE> [ A
down arrow <ESCAPE> [ B
right arrow <ESCAPE> [ C
left arrow <ESCAPE> [ D

After users have successfully set the terminal displays for VT100, edited/created
the keyboard mapping file, saved changes to the keyboard mapping file, and
specified the keyboard mapping file, will be able to navigate through the OAM and
use the applicable keyboard commands.

Customer Support Customers who will be purchasing software should contact the LoopCare
Customer Support. This will be necessary in order to verify that the product
selected will properly interface with the OAM. Customers should provide enough
time in order to allow Customer Support to evaluate the product and to make a
determination whether or not the software package meets the OAM requirements.

1-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User Administration System Administration Guide
Setting Up Line Printers

Setting Up Line Printers

Overview The following information provides step-by-step procedures for adding additional
line printers to the configuration. Once the printer has been setup, it will accept
normal outputs (e.g., from the TV Mask) or can be used to send printer directed
printouts.

Setup Outline In order to completely setup a new line printer in the configuration, both hardware
and software changes must be made. The Printer Options Settings described
here pertain to the NCR 6417 Printer as setup via both the Control Panel Interface
and Options Menus. To setup hardware options on other types of printers, see the
manufacturer’s recommendations and user instruction.

The required software changes for BASE, described in this document will be the
same for any printer that is added to the environment.

The following is a checklist of all changes necessary to make a new printer

operational:
• Set up is recommended Printer Option Settings (hardware) via user
interface provided with the printer.
• BASE file changes: edit, compile, and load /base/ictables/gplt.src to add
the new printer
• LoopCare file changes: edit /mlt/exec/PRINTERS to add a new printer.

Recommended The Printer Options Settings listed below are the settings recommended for
Hardware Settings optimal printer performance in the configuration. For detailed instruction on
for the NCR 6417 making setting changes, see the "NCR 6417 Printer Setup Guide".
Printer

Revision Q (p/n 040-0362) Release 2.15, December, 2006 1-7

System Administration Guide User Administration
Setting Up Line Printers

Procedures for Setting Up Additional Line Printers

GROUP ITEM SETTING

Font Print Mode NLQ Sans Serif
Pitch 12 CPI
Style Normal
Size Single
General Control Emulation Mode Epson Fxe
Graphics Bi-directional
Paper Output Override No
Print Registration 0
Operator Panel Functions Full Operation
Print Suppress Effective Yes
Vertical Control Line Spacing 6 LPI
Form Tear-Off Off
Skip Over Perforation No
Auto LF No
Auto CR No
Auto Feed XT Invalid
Page Length 11”
Symbol Sets Character Set Set I
Language Set American
Zero Character Slashed
Serial /F Option Parity None
Serial Data 7 or 8 bits 8
Protocol X-ON/X-OFF
Diagnostic Test No
Busy Line SSD
Baud Rate 9600 BPS
DSR Signal Valid
DTR Signal Ready on Power Up
Busy Time 200 Milliseconds

1-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User Administration System Administration Guide
Setting Up Line Printers

Menu Items and The following are menu items, descriptions of that item, and suggested settings.
Recommended 1. Print Mode - this option is set to provide Near Letter Quality Sans Serif font
Settings print.
2. Pitch - this option is set to produce 12 characters per inch of type.
3. Style - this option is set to provide Normal (upright) characters.
4. Size - this options is set to provide Single width and height characters.
5. Emulation Mode - this option is set to provide the Epson FXe printer
command set.
6. Graphics - this option is set to provide bi-directional (faster) bit graphics.
7. Paper Out Override - this options is set to provide a detector which senses
when less than one inch of paper remains in the printer and stops printing
at that point.
8. Print Registration - this option is set to improve registration with bi-
directional bit graphics.
9. Operator Panel Functions - this option is set to provide full operation of all
control panel functions.
10. Pint Suppress Effective - this option is ON.
11. Line Spacing - this option is set to provide 6 lines of type per inch.
12. Forms Tear Off - this option is disabled.
13. Skip Over Perforation - this option is disabled to avoid interference with
software settings.
14. Auto LF - this option is disabled.
15. Auto CR - this option is disabled. It is for use only in the IBM emulation.
16. Auto Feed XT - this option is disabled.
17. Page Length - this option is set to handle 11 inch paper.
18. Character Set - this option is set to provide Character Set I.
19. Language Set - this option is set to provide American Language Set
symbols.
20. Purity - this option is disabled.
21. Serial Data 7 or 8 Bits - this option is set to provide 8 bit data format.
22. Protocol - this option is set to provide an X-ON/X-OFF interface protocol.
23. Diagnostic Test - this option is disabled.
24. Busy Line - this option selects a line used for Busy Signal.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 1-9

System Administration Guide User Administration
Setting Up Line Printers

25. Baud Rate - this option selected a data transmission speed.

26. DSR Signal - this option enables a Data Set Ready signal.
27. DTR Signal - this option enables a Data Terminal Ready signal on Power
up.

Required Software In order to print outputs, it is necessary to introduce the new line printer to the
Changes BASE and LoopCare software. The following procedure will step you through all of
the necessary changes to the relevant software files.
1. Select a free GIS port which will be used to connect the new printer and
determine that ports’ equivalent tty name.
2. Attach a null modem to the printer and connect the printer to the selected
GIS port.
3. From a standard login, become a superuser. Type:
su - root
4. Login to sysadm
5. Select the following options on the Open Systems Administrator menu:
System Hardware/Software Configuration
Peripheral Configuration
printer
add
6. Enter the following requested information and press <SAVE>.
Printer name
System name
Printer type
Similar printer used for default
Standard configuration (yes or no)
Network communications protocol
Standard port settings (yes or no)
Device or basic network address
7. Complete the Configure New Printer - Local Printer Subtask form if you did
not choose the standard configuration, then press <SAVE>.
8. Complete Printer Communication Subtask form if you did not want to use
the standard port settings, and press <SAVE>.

1-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User Administration System Administration Guide
Setting Up Line Printers

NOTE:
All files below /usr/spool/lp must be owned by "lp"; if any difficulty is
encountered in carrying out the "lp commands" check the ownership and
change it if necessary. Also, check permissions on the following files:

/usr/bin/enable (should be r_sr_xr_x)

/usr/lib/accept (should be r_xr_xr_x)
9. Now that the new printer has been introduced to the "lp" process, lpsched
may be turned back on. Turn on lpsched by executing the following
command:
/usr/lib/lpshed
10. Now that you have introduced the new printer to lpsched, you may
command the program to queue up print jobs that will be waiting when you
finally enable the new printer. If you would like to do that, execute the
following command:
/usr/lib/accept china
Exit root to carry out the next part of the procedure.
11. Next, add a new printer line to /base/ictables/gplt.src. You must first
su - base
vi the file and add a new line for the printer you are adding. Example:

pn ln dev lm
W020 1 1 01

12. When you have added a new line to glpt.src, the file must be compiled and
loaded via RTSadmin. Use the following commands:
RTSCOMPILE gplt.src
RTSLOAD gplt.src
13. Next, add the printer to /mlt/exec/PRINTERS. Login as mlt and vi the file.
Add a new line to the file, using the number id which was entered in gplt.src
in the "lm" field for the first position number. The rest of the line should be
identical to the line above it.
Example:
01 cat XX | lp -dchina -c >/dev/null 2>&1

NOTE:
No more than 512 characters will be processed by the specified command.

14. Next, enable the printer. First you must:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 1-11

System Administration Guide User Administration
Setting Up Line Printers

su - root
then execute the following command:
/usr/bin/enable china.
15. Now the installation is complete and the printer is ready for use. See the
"NCR 6417 Printer Setup Guide" for detailed instructions in putting the
printer on-line and preparing it to receive output.

1-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User Administration System Administration Guide
HP Jet Admin Printer Setup

HP Jet Admin Printer Setup

Procedure Use the following procedure to set up an HP Jet Admin printer:

1. Use a web browser to access the following URL:
http://www.hp.com
2. Click the drivers and download link.
The drivers and downloads page is displayed.
3. On the drivers and downloads page, enter hp jetadmin and click
the right arrow icon.
The search results are displayed.
4. Retrieve the latest HP JetAdmin product for the appropriate version of HP-
UX.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 1-13

System Administration Guide User Administration
HP Jet Admin Printer Setup

1-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration 2

Contents

• Introduction 2-2
• Customizing System Files 2-3
• Updating the Priority Table 2-6
• Performing an NPA Split 2-11
• Batch ADSL Pre-Qualification Testing 2-24
• Calibrating a DLC Bypass Pair 2-52
• Calibrating a Switch for Loop Insertion Loss 2-53
• Wideband Testing Feature 2-55
• HUB Alarm Handler 2-58
• Calibrating HUB TMU MDF Trunks 2-60
• Calibrating the Siemens EWSD Switch with Integrated Testing 2-61

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-1

System Administration Guide LoopCare Administration
Introduction

Introduction

Overview This chapter contains LoopCare administration procedures that require the user to
modify UNIX system files in order to customize the system.

2-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Customizing System Files

Customizing System Files

Overview The LoopCare application may be customized to suit customer testing needs.
This can be done by modifying Group Descriptor File (GDF) options.

Modifying The Group Descriptor File (GDF) file is a tool by which the LoopCare application
Customer GDF can be tailored to the particular characteristics of the customer’s configuration.
Files
The LoopCare application running on the Front End consists of eight software
groups (see Table 2-1), each comprising a set of software modules. Each group of
modules performs designated functions during the testing process. The GDF
defines the modules that are members of the group

The user may specify the options that each software module in the application will
run thereby affecting the way LoopCare testing is performed.

Refer to Appendix A in this guide for information on the Group Descriptor File
(GDF) options that may be set to customize LoopCare testing.

LoopCare Groups The following list defines the major function of the LoopCare software groups:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-3

System Administration Guide LoopCare Administration
Customizing System Files

Table 2-1. Group Descriptor Files (GDFs)

GROUP FUNCTION
MLT • The RDBMS which is involved in storing LoopCare data
bases and includes some LoopCare utilities.
• The communications and Mask interface processes.
• Error message handling and tracing functions.
• Brings up the MDMN group.
MDMN Controls all daemon functions on the LoopCare machine which
involve:
• Communications daemons for communications ports
connected to DCNs
• DMZ, or DZ daemons which control dial out or
asynchronous ports
• M1 daemon that communicates with LTF Controllers
Brings up the MGRP group
MGRP • Invokes the LoopCare testing interfaces (TV, TEST).
• Invokes the processes required to interact and send
information through those interfaces.
• Invokes testing and administrative processes for modules
such as sam and triger.
• Invokes training processes through the mtrain module.
• Brings up the M1, M2, MPST, ISDN, and SDV groups.
M1 Brings up the processes required to test through the LTF
Controllers.
M2 The M2 group brings up the processes required to test through the
RMU and CMU test equipment.
MPST The MPST group brings up the processes required to test
LoopCare through the PST interface.
ISDN The ISDN group brings up processes required to test ISDN lines.
CGRP The CGRP brings up processes that allow Common Object
Requester Broker Architecture/Application Program Interface
(CORBA/API).

2-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Customizing System Files

Modifying Since each LoopCare site has a highly unique configuration, the software must be
Customer Env Files sensitive to these individual site differences. The way LoopCare finds out the
many site-specific parameters is through environmental variables. These are shell
variables which may be set via the LoopCare User Interface Program (UIP). The
LoopCare software will use the values in these variables to change the functioning
of LoopCare.

! WARNING:
Do not use vi or any other means except UIP to modify these
environmental variables; an improperly formatted entry can cause major
system problems. UIP allows you to enter only user-settable values and
properly formats that data.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-5

System Administration Guide LoopCare Administration
Updating the Priority Table

Updating the Priority Table

Overview The priority table specifies which VER code to return when multiple faults are
found on the line under test. The table is supported by the VER 99 feature which
reduces the number of VER 99 codes that are generated.

The VER code condition 99 applies to cases where LoopCare can return more
than one VER code. This feature selects the hardest of the multiple faults and
provides the corresponding VER code as defined in the Priority Table.

A feature file update is necessary before this feature can be used.

Priority Table The first column of the Priority Table shown on the next page is called the Priority
Code. It is this code that is returned if two or more VER Codes in the adjacent row
are set.

The codes listed to the right of the first column are called combo codes. The
generation of any inclusive combination of the Priority Code and corresponding
combo codes will cause LoopCare to return the code specified in the Priority Code
column. Should a non-combo VER code be among the combo VER codes, a VER
99 will be returned.

If a subver code is needed, leave the second column blank. If no secondary code
is entered, as in the sample LoopCare Priority Table shown below, and a combo
VER code is encountered (consisting of D1 and any other VER code), D1 will be
returned.

NOTE:
The system searches the table from top to bottom and displays the first
VER code that is reached; it does not continue searching.

Changing The Priority Codes may be added, deleted or their combo codes may be modified. Just
Priority Table edit the Priority Code and Combo Codes that you want LoopCare to use instead
of the codes currently listed.
1. At the UNIX prompt on the system console, login as mlt.
Login:
passwd:
2. Change to the VER99 directory:

2-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Updating the Priority Table

cd /mlt/config

NOTE:
The LoopCare system will first attempt to use the priority table defined in
the /mlt/config/ver99 file. If this file does not exist, only then will the
LoopCare system use the default priority table defined in the /mlt/
config/ver99.def file.

Customers who wish to edit the default priority codes to suit their needs
must copy the /mlt/config/ver99.def file into /mlt/config/ver99
before any edits are made as outlined below.
After the /mlt/config/ver99 file is initially created, the MGRP must be
stopped and re-started in order for the test system to recognize this new
file. Once this is complete, the test system will utilize the Priority Table in
/mlt/config/ver99, instead of /mlt/config/ver99.def. All future
edits to /mlt/config/ver99 will be picked up by the test system,
without requiring a bounce of the MGRP.
3. Use vi to edit the priority table, ver99. For example:
vi ver99
4. When complete, save the file and exit.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-7

System Administration Guide LoopCare Administration
Updating the Priority Table

Table 2-2. Priority Table

# VER99 Priority table

# 1st vercode is the priority code, all following vercodes are combo codes

D1

D2

D3

DP

37

53

54

0 MT

0C MT

3 31 32 33 36 05 55 57 58 MT U5

11 12 31 32 33 36 41 42 05 55 56 57 58 C3 MT U5

14 31 32 33 36 05 55 56 57 58 93 95 MT U5

17 31 32 33 36 05 55 56 57 58 MT

18 31 32 33 36 05 55 56 57 58 93 95 MT

21 12 16 23 24 27 31 32 33 36 05 55 56 57 58 P1 MT

22 12 23 24 27 31 32 33 36 05 55 56 57 58 74 P1 MT

23 27 31 32 33 36 05 55 57 58 MT

24 27 31 32 33 36 05 55 57 58 MT U5

25 23 24 27 31 32 33 36 05 55 57 58 P1 MT

26 21 22 25 31 32 33 36 MT

27 05 55 57 58 MT

31 51 52 55 57 58 MT

32 51 52 55 57 58 MT

33 51 52 55 57 58 MT

35 31 32 33 34 36 MT

36 51 52 55 57 58 MT

41 14 27 31 32 33 36 05 55 57 58 MT U5 U6

42 14 27 31 32 33 36 05 55 57 58 MT U5 U6

43 14 27 31 32 33 36 05 55 57 58 MT U5 U6

45 14 27 31 32 33 36 05 55 57 58 MT U5 U6

46 14 27 31 32 33 36 05 55 57 58 MT U5 U6

47 14 27 31 32 33 36 05 55 57 58 MT U5 U6

71 31 32 33 36 MT U6

2-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Updating the Priority Table

75 31 32 33 36 MT

93 96 MT

95 31 32 33 36 05 55 57 58 MT

96 05 55 57 58 0D 0E MT

P1 23 24 27 31 32 33 36 05 55 57 58 MT

P2 23 24 27 31 32 33 36 05 55 57 58 MT

P3 31 32 33 36 MT

NOTE:
The VER codes in the first column are the priority codes, all following VER
codes are combo codes.

NOTE:
Tabs and non-printable characters are not allowed in this file. The priority
VER code and all sub VER codes must be delimited by a single space.
Entries with no sub VER codes will require a single space after the priority
VER code.

Reporting Each time multiple faults are detected, information about the faults is logged to the
file /mlt/reports/VER99.STAT. Data is displayed in the following format:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-9

System Administration Guide LoopCare Administration
Updating the Priority Table

Example

Resulting
Date Time Telephone # VER Code Other VER Codes

2-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Performing an NPA Split

Performing an NPA Split

Overview When an area code runs out of available telephone numbers, a new area code is
created. The new area code is assigned some of the NXXs from the old area
code. This provides the old area code with room for expansion.

This procedure ensures that the LoopCare system has the ability to test the
associated telephone numbers under each new NPA code.

Perform the following procedure when the regional NPA 3-digit code is split to
include a new NPA.

NOTE:
This procedure is a service-affecting procedure that may take some time to
complete.

The NPA split procedure was formerly done as part of an LMOS procedure but is
now a LoopCare utility. The LMOS database must also be updated with the new
NPAs to ensure compatibility with LoopCare.

NOTE:
If a problem occurs during this procedure, the program will quit and no
updates will be made to the LoopCare database. Troubleshoot the logs
based on the default level of tracing that is turned on. Call LoopCare
Technical Support.

Purging Deferred The npasplit command fails if it finds deferred transactions in the database.
Transactions Before performing an NPA split, execute the db_purgetrans shell script to
purge deferred transactions that have been successfully propagated to replication
sites.

Usage

db_purgetrans <password>

where <password> is the password for the system Oracle account.

Overview Description of Control Files, Shells and Utilities

The following files, shells, and utilities are used during the split procedure.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-11

System Administration Guide LoopCare Administration
Performing an NPA Split

• NPADEF
• nnxs.global
• exks.global
• NpaSplit

NPADEF A control file used by the LMOS NPASPLIT utility to set

the correct environmental variables required to perform
the split. This file must be reused by the LoopCare
NpaSplit utility to remain consistent with the LMOS
procedure (although only a few of the variables are
used by LoopCare). A blank template can be found in
/mlt/ubin called NPADEF.template.
By default, the NpaSplit utility searches for the NPADEF
file in /base/npasplit.Otherwise it searches in the
directory path specified by the -e option for NpaSplit.
nnxs.global Criteria file used by the LMOS NPASPLIT utility to
designate which NNXs are to be split. This file specifies
the NNXs to be split for the Old NPA listed in the proper
NPADEF file.
File has been reused by the LoopCare utility for
consistency with the LMOS procedure. The location of
this file is specified in the GLOBALNNXS variable within
he NPADEF criteria file.
exks.global Criteria file used by the LMOS NPASPLIT utility to
designate which EXKs are to be split. This EXK defines
the EXKs that should be split for the Old NPA in the
appropriate NPADEF file.
File has been reused by the LoopCare utility for
consistency with the LMOS procedure. The location of
this file is specified in the GLOBALEXKS variable within
the NPADEF control file.
Exchange keys are typically 6 digits. The values in this
file are only 3 digits. The exchange key is manufactured
by taking the OLD NPA (for example, 454) from the
NPADEF file and appending the value (for example,
555) found in the exks.global table. The result is a 6
digit EXK, 454555 in this example.
NpaSplit Main LoopCare utility for conducting NPA splits. It
resides in /mlt/ubin and is executed from the command
line. By default, the NPADEF used resides in /base/
npasplit.The user can specify another path for the
NPADEF file by using the -e option on NpaSplit utility

2-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Performing an NPA Split

Options The following options can be entered on the command line when executing the
NpaSplit utility:

-t [0-4] Turns on tracing and specifies the tracing level. The -t0
option turns off tracing. The default is 1.
The trace file, NpaSplit.trc, is located in the /mlt/trace
directory.
-e Specifies another environment file if NPADEF is not
used, as in multiple splits where you may have a
NPADEF201 for a 201 split, a NPADEF908 for the 908
split, etc.). The file must exist in a directory specified in
the PATH variable.
-p Requires a password. Used if the default Oracle
password has been changed.

Examples:
NpaSplit -t 4 -l <login> -p <password> or
NpaSplit -t 4 -e <filename> -l <login> -p <password>
(if other than NPADEF is used)

Pre-Split Activities 1. Login as mlt.

(Non-Service 2. Create a root NPA split directory (for example, /base/npasplit), if one does
Affecting) not already exist as a result of preliminary LMOS/NpaSplit activity on hybrid
machines.
3. Create a subdirectory for each NPA to be split under the root directory
created in Step 1 (for example, /base/npasplit/201, /base/npasplit/908).

NOTE:
If only one NPA is to be split, the creation of the subdirectories indicated
above is not required.

4. Copy in the appropriate NPADEF, exks.global and nnxs.global tables in

each of the directories created in Steps 2 and 3 above, as needed. A blank
NPADEF can be found in /mlt/ubin as NPADEF.template.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-13

System Administration Guide LoopCare Administration
Performing an NPA Split

NOTE:
The same NPADEF, exks.global, and nnx.global tables used by LMOS
should also be used by LoopCare.

5. Customize the NPADEF in each split subdirectory, making sure that the
following entries are set correctly:

OLDNPA Set this to the NPA that is being split (example:

OLDNPA=201)
NEWNPA Set this to the new NPA (example: NEWNPA=973)
NPAROOT (example: NPAROOT="/base/npasplit")
GLOBALEXKS (example: GLOBALEXKS="$NPAROOT/201/
exks.global")
GLOBALNNXS (example: GLOBALNNXS="$NPAROOT/201/
nnxs.global")

NOTE:
Refer to the sample NPADEF template in Appendix D while performing Step
5.

6. Update the callback security actmp file as required. Create the new stats
file using cbutil, (do not load at this time).
7. In a replication environment only, create a pre-split export file to be used in
a backout procedure if required:
/mlt/ubin/db_exp presplit.dmp mltdba repadminpw
You are done.
8. In a non-replication environment only, execute the following sequence of
UNIX commands:
su - mlt
cd /mlt/install
exp mltdba/mltdba file=presplit.dmp owner=mltdba

Performing the Split 1. Login as mlt.

(service affecting) 2. Stop LoopCare and verify that OAM is not running.
Execute the following command to verify that no OAM processes are
running.
ps -fu | grep oracle

2-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Performing an NPA Split

Kill all processes with oracle<ORACLE_SID> as the owner, where

ORACLE_SID is the variable name assigned to the Oracle database on the
machine. For example, if the ORACLE_SID is mlt58, the owner is
oraclemlt58.
3. Change to the directory in which the NPADEF file resides. This file will be
located wherever your PATH is established.
4. Execute the NpaSplit utility:
Example:
NpaSplit -t 4 -l <login> -p <password>
5. Once the NpaSplit Utility is finished running, the administrator needs to
change the affected records manually by using the OA&M utility. The user
must login to ADEF, query using the Remote Terminal - Wire Center utility
and change the NPA’s that have changed to the new NPA. For example,
after running NpaSplit to change some 908 NPAs to 973, use oam Remote
Terminal - Wire Center query to view all the NPAs with 908 and change the
appropriate records to 973.

NOTE:
The system may issue warnings that may require your immediate attention
or the NpaSplit utility will not function. Respond appropriately to the prompt.

When a split CMU is detected, the system displays the following prompt:

**WARNING**
qty CMU(s) found in dialgroup dialGrpId in the prefix_CMU table that
contains an nxx that is splitting off in the test head telephone number field
AND an nxx that is not splitting off in the backup test head telephone
number field (or visa versa). If you choose to continue, processing will
continue, but this dialgroup entry will be left untouched. It will be your
responsibility to update the dialgroup where necessary. If you do not
choose to continue, the NpaSplit will abort with no changes made to the
database. You can then review the split criteria before attempting the
NpaSplit again.

The test head id(s) is(are): thid...

Continue anyway?

When a split EMU is detected, the system displays the following prompt:

**WARNING**

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-15

System Administration Guide LoopCare Administration
Performing an NPA Split

qty EMU(s) found in dialgroup dialGrpId in the prefix_CMU table that

contains an nxx that is splitting off in one test head telephone number field
AND an nxx that is not splitting off in another test head telephone number
field.
If you choose to continue, processing will continue, but this dialgroup entry
will be left untouched. It will be your responsibility to update the dialgroup
where necessary. If you do not choose to continue, the NpaSplit will abort
with no changes made to the database. You can then review the split
criteria before attempting the NpaSplit again.

The test head id(s) is(are): thid...

Continue anyway?

When a split RTU is detected, the system displays the following prompt:
**WARNING**
qty RTU(s) found in dialgroup dialGrpId in the prefix_RTU table that
contains an nxx that is splitting off in the test head telephone number field
AND an nxx that is not splitting off in the backup test head telephone
number field (or visa versa). If you choose to continue, processing will
continue, but this dialgroup entry will be left untouched. It will be your
responsibility to update the dialgroup where necessary. If you do not
choose to continue, the NpaSplit will abort with no changes made to the
database. You can then review the split criteria before attempting the
NpaSplit again.
The test head id(s) is(are): thid...
Continue anyway?
If you choose to continue, you will have to make manual entries for the
NXXs in each dialgroup tables.

Environment Below is a table that contains LoopCare Environment Validation Error Messages.
Validation Error These error messages will be generated by LoopCare if there is a problem if the
Messages Environment Variables are incorrect while performing the NPA Split.

Error Messages Cause Action

Environment variable BASE must BASE not set Make sure BASE variable is set and
be set to process the environment exported
Environment variable MLT_CNF MLT_CNF not set Make sure MLT_CNF is set and
must be set to access the database exported

2-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Performing an NPA Split

WARNING: Environment variable MLT_TRC not set Make sure MLT_TRC is set and
MLT_TRC not set NpaSplit.trc file exported
will be written to the current
directory
Environment variable MLT_TBL MLT_TBL not set Make sure MLT_TBL is set and exported
must be set to create LTS database
The MLT group is up. It must be MLT Group is Up Make sure MLT group is not running
down during an NPA Split
Running OAM process id detected. OAM is running Find the OAM process and exit
No OAM activity allowed during an
NPA Split
Process id is connected to the Someone is connected Bring down the database process
database. No database activity to the database
allowed during an NPA Split
LTS file creator genxxx not found. genxxx not found Set MLT_UTL variable to location of
Check MLT_UTL path genxxx. (e.g., /mlt/ubin)
MLT_UTL is not set MLT_UTL not set Make sure MLT_UTL is set and exported
LTS file creator genxxx is not genxxx not executable Check permissions on the file
executable $MLT_UTL/genxxx
Database connect error could not connect to the Check that Oracle is up. Verify mltdba
database account password. If different from
default, use -p option on command line

Command Line The following table includes all error messages for Command Line Option
Option Validation Validation.
Error Messages

Error Messages Cause Action

Illegal tracing level value, only 0, 1, tracing value other than Change the tracing value to either 0, 1,
2, 3, or 4 allowed. 0, 1, 2, 3, or 4 2, 3, or 4 with -t option
***ERROR importing environment could not locate Check if the file exists in the $PATH or
file envFile. File not in PATH environment file check the permissions on that file
Environment file duplicated in -e the - e file list contains a Check the list for any duplicate file
option: envFile duplicate filename names

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-17

System Administration Guide LoopCare Administration
Performing an NPA Split

Environment The following table includes all error messages for Environment Validation. Check
Validation Error the list for any duplicate file names
Messages

Error Message Cause Action

*** ERROR: OLDNPA environment OLDNPA not in Check if OLDNPA is in the NPADEF file
variable not set *** environment
*** ERROR: OLDNPA oldnpa is not OLDNPA is not 3 digits Check OLDNPA variable, make sure the
3 digit numeric*** NPA is 3 digits
*** ERROR: NEWNPA NEWNPA not in Check if NEWNPA variable is in the
environment variable not set environment NPADEF file
*** ERROR: NEWNPA newnpa is NEWNPA is not 3 digits Check NEWNPA variable, make sure the
not 3 digits numeric NPA is 3 digits
**ERROR: OLDNPA is the same as OLDNPA and NEWNPA Check the variables and make sure the
NEWNPA*** variables are the same variables are different
***ERROR: Variable GLOBALEXKS not in Check the NPADEF file, make sure
GLOBALEXKS is not defined. This environment GLOBALEXKS is defined
shell variable, which is normally
defined in the NPADEF file,
contains the full path of the file
containing the list of all Exchange
Keys that are converting
***ERROR: File exkFile does not The file pointed to by Make sure the exkFile exists in the path
exist GLOBALEXKS does not
exist
***ERROR: File exkFile is not File exkFile pointed to by Check the permissions on the exkFile
readable GLOBALEXKS is not
readable
***ERROR: Can’t open exkFile The file pointed to by Check to make sure the file exkFile is in
errno errno GLOBALEXKS cannot the path and the permissions are set
be opened for reading correctly
***ERROR in file exkFile: exk is not The file pointed to by Check the exkFile has only 3 digit or
3 characters/digits GLOBALEXKS contains uppercase Alpha exchange keys, not
an exk that is not 3 digits lowercase alpha exchange keys
or uppercase alpha
***ERROR in file exkFile: exk The file pointed to by Check the exkFile, make sure there are
appears more than once GLOBALEXKS contains no duplicate exchange keys
an exk that is duplicated

2-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Performing an NPA Split

Error Message Cause Action

***ERROR: Variable GLOBALNNXS not in Check the NPADEF file, make sure
GLOBALNXXS is not defined. This environment GLOBALEXKS is defined
shell variable, which is normally
defined in the NPADEF file,
contains the full path of the file
containing the list of all NNXs that
are converting
***ERROR: File nxxFile does not The file pointed to by Check to make sure the nxxFile does
exist GLOBALNNXS does not exist
exist
***ERROR: File nxxFile is not The file pointed to by Check the permissions on the nxxFile
readable GLOBALNNXS is not
readable
***ERROR: Can’t open nxxFile The file pointed to by Check to make sure the file nxxFile is in
errno errno GLOBALNNXS cannot the path and the permissions are set
be opened for reading correctly
***ERROR in file nxxFile: nxx is not The file pointed to by Check if GLOBALNNXS file is in the path
3 digits numeric GLOBALNNXS contains
an nxx that is not 3 digits
***ERROR in file nxxFile: nxx The file pointed to by Check the GLOBALNNXS file, make
appears more than once GLOBALNNXS contains sure there are no duplicate nxx’s in the
an nxx that is duplicated file
Errors detected while attempting to Other errors exist. This Fix other errors
validate definition of envFile is a final warning before
NpaSplit exits.

Oracle Table The following is an error message that will print if an Oracle error occurs while
Update Error updating a table. This information will help debug the database error.
Messages *** ERROR Database error in function: tableName,
fieldName

If this error message occurs, contact LoopCare Technical Support.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-19

System Administration Guide LoopCare Administration
Performing an NPA Split

The following table includes messages that may print after the tables have been
updated.

Message Printed to
Condition Screen Action
successfully processed Environment file envFile None
environment file complete
successful commit of database Work committed None
successful genxx execution LTS database generated None
Must Build to complete
split NPA split successful
unsuccessful genxx execution Error errno generated Investigate why genxxx fails and fix the
dcn dcnid/LTS ltsid problem

Replication The following table includes trace messages for Replication Activities
Activities Trace
Messages

Message Printed to
Condition Screen Action
deftran table queried DEFTRAN table for This message should clear on its own, it
instance has number will be printed every 60 seconds until the
records in it transaction is complete on that instance.
This can take up to 1 hour to complete.
deferror table queried, after data DEFERROR table for Contact LoopCare Technical Support.
was updated instance has number
records in it

2-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Performing an NPA Split

The following table contains error messages for Replication Activities

Message Printed to
Condition Screen Action
records in deftran before NpaSplit DEFTRAN table for DEFTRAN table must be empty. Find out
starts instance has number why transactions are deferred and fix the
records in it. Fix if problem.
necessary or wait for
transactions to clear
records in deferror before NpaSplit DEFERROR table for DEFERROR table must be empty. Find
starts instance has number out why transactions are deferred and fix
records in it. Fix if the problem. Contacting your Database
necessary or wait for Administrator to remove any data in the
transactions to clear. file or contact LoopCare Technical
Support to aid in the problem.

Post-Split Activities 1. On the master machine, build all modified testheads (a list can be found in
(service affecting) /mlt/trace/NpaSplit.trc near the end of the file) for each DCN/LCN via the
MLTUIP:
option 2 - Database Administration
option 4 - Build
option 4 - LTS Database
Answer prompts as appropriate
2. On master machine, load new CB security stats file into /mlt/exec
3. Start LoopCare on all machines.
4. Create a new DEFEXK table and distribute to LMOS via UIP.
option 5 - Table Distribution to LMOS/BASE
option 3 - Create and Distribute DEFEXK
option 2 - copy DEFEXK to /lmos/exec on remote
HCFEs
Select appropriate LMOS Lms
5. Create and distribute swmor.src:
option 5 - Table Distribution to LMOS/BASE
option 6 - Create and Distribute swmor.src
option 2 - copy swmor.src to /lmos/ictables on
remote HCFEs
select appropriate LMOS LMs

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-21

System Administration Guide LoopCare Administration
Performing an NPA Split

6. On Master machine, create and distribute exk2nnx.src:

option 5 - Table Distribution to LMOS/BASE
option 10- Create and Distribute exk2nnx.src
option 3 - perform both local and remote copies
(options 1 & 2)
Select appropriate LoopCare LMs
7. Do the following as base on both LoopCare machines:
cd /base/ictables
RTSCOMPILE exk2nnx.src
RTSLOAD exk2nnx.src
8. Do the following as lmos on all LMOS machines:
cd /lmos/ictables
RTSCOMPILE swmor.src
RTSLOAD swmor.src
9. Execute the following commands for each LTS in the testhead list
built in Step 2:
a. DS (display status)
b. Trunk calibrations (TC -L)
The npasplit process is now complete.

Post-Process Add new CB prefix entries as needed (for LTSs/DCTUs, in which the NPAs have
Activities (non- been split. It may now be necessary to dial an NPA that was not previously
service affecting) required. The split utility does not have the ability to determine what may need to
be added, so this is left to the LoopCare administrator. An example of this follows:

If 215 is being split into 215 and 666, NNX 363 (LTS555), within 215, will be
moved to 666; NNX 454 (LTS444) will remain prior to the NPA split, and no CB
prefix entries are required for either LTS to dial the NPANXX combination (they
are all local seven-digit calls). After the split, LTS555 will need to dial 1215 to
complete a callback to the 215454 NPANXX; LTS444 will need to dial 1666363 to
complete a callback to the 666363 NPANXX. These two entries need to be added.
1. Review messages printed to the screen. See the subsection below,
NpaSplit Error Messages, for a list of error messages you are likely to
encounter; see also the logfile containing a record of your choices while
executing the utility.
2. In the event that errors have occurred, fix the errors until the NpaSplit runs
successfully.

2-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Performing an NPA Split

3. Access the file $MLT_TRC/NpaSplit.trc to review details of the utility.

4. Access the OA&M main menu and select UIP.
5. Start LoopCare by making the following menu selections:
System Administration.
System Start.
MLT Group.
The following prompt and message appear:
Cold or warm start? [c/w/q]
Select c (cold start).
MLT: STARTING MLT APPLICATION
6. Exit OAM.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-23

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

Batch ADSL Pre-Qualification Testing

Introduction The LoopCare Batch ADSL Pre-qualification feature allows the customer to
determine which lines on their switch are suitable to provide ADSL service. For
example, ADSL is capable of transmitting more than 6 Mbit/s to a subscriber, and
as much as 640 kbit/s more in both directions. The new DSL technologies expand
access capacity on the existing Plain Old Telephone Service (POTS) copper cable
by a factor of 30 or more.

Data rates on DSL services (and ISDN) are impacted by a number of factors such
as loop length, metallic faults, cable balance, load coils, bridge taps, idle channel
noise, impulse/wideband noise, and loop loss. On loops that have existing POTS
service, some of these factors can be measured by LoopCare.

LoopCare Batch ADSL Pre-qualification is accomplished by placing the telephone

numbers (TNs) of the lines to be tested in a batch input file (also sometimes
referred to as a list) that can be executed either directly from the Batch ADSL Pre-
qualification menu (adsl_menu) or through the UNIX cron utility. The LoopCare
Batch ADSL Pre-qualification feature is a locked feature.

Overview The Batch ADSL Pre-qualification feature runs a LoopCare metallic test on each
TN in up to twenty batch input file(s) with 500 TN entries in each file. The results
of these tests are stored in output files which provide the raw data used for report
generation. The reports present LoopCare’s classification of lines into one of the
following categories:
• Short lines where higher rate ADSL services can be provided
• Medium lines where lower rate ADSL services can be provided
• Out of limit lines where ADSL services are not recommended
• Lines that need to be pre-conditioned, e.g., remove load coils and MTUs
• Lines that need to be retested so they can be classified properly

The classification of lines as short, medium, or out of limits is based on the length
of loop measurement which is returned for most lines when they test OK
(LoopCare VER codes 0 and 0C). The measured loop length (displayed in feet) is
compared against user-settable thresholds to make the decision.

Lines can also be classified as out of limits if they

• exceed the threshold for medium lines, or
• tests return a VER 0 or VER 0C but a loop measurement was not made.

Lines can be classified into the retest category if they meet the following criteria:

2-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

• return a VER code other than VER 0 or OC

• exceed the longitudinal or capacitive balance threshold
• If a RMU or bypass pair is being detected in the DLC system
• If MTUs are present and need to be removed

Lines are classified into the pre-condition categories

• if they have load coils that need to be removed.

NOTE:
For more specific details about the setup and operation of the feature read
the following sections, in particular, the Special Information section.

Intended Users The Batch ADSL Pre-qualification Testing utility is intended for the following users:
• Data Center personnel
• Users who are authorized to use an mlt login ID on the LoopCare
processor

NOTE:
The Batch ADSL Pre-qualification Testing utility is not intended to be used
by field craft personnel.

Batch ADSL Pre- The Batch ADSL Pre-qualification Feature creates and/or uses files in the
qualification following directories:
Directory Structure /mlt/ubin

Directory /mlt/ubin contains the Batch ADSL Pre-qualification Utility software and
user interface menu. It allows the user to run scheduled tests from the Batch
ADSL Pre-qualification menu, control the LoopCare testing rate, and generate
summary and detailed reports of the test results.
/mlt/adsl/in

Directory /mlt/adsl/in contains the following:

• The batch input files created by users. These files have the naming
convention of filename.inp (ex. lts21.inp).
• A batch input file created by the adsl_menu report generator which is
named retest.inp.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-25

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

• Miscellaneous program file (packet.dat). DO NOT REMOVE THIS FILE!

/mlt/adsl/out

Directory /mlt/adsl/out contains the following:

The output files for each of the batch input files run by the Batch ADSL Pre-
qualification feature. Each input file will have a corresponding output file.

The naming convention of the output file is filename.inp.out (ex. lts21.inp.out).

/mlt/adsl/summary

Directory /mlt/adsl/summary contains files that are created new each time a
report is generated through the Batch ADSL Pre-qualification menu. These files
contain test results information and are overwritten each time a report is run. If
users want to keep selected report results, they should rename and save files
before the next report is run.
• sum.rpt - formatted report generated by Batch ADSL Pre-qualification
menu option 5
• sum.out - program output data file (DO NOT REMOVE)
• short.out - output file for all TNs classified as Short
• med.out - output file for all TNs classified as Medium
• over.out - output file for all TNs classified as Out of limits
• retest.out - output file for all TNs required to be retested
• lst - program file with a list of input files to be run (DO NOT REMOVE)
• precondition.out - output file for all lines that have load coils and MTUs
• short.unknown.out - output file for all TN’s which the presence of load coils
is undetermined.
• med.unknown.out - output file for all TN’s which the presence of load coils
is undetermined.

2-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Output File Process Below is a flow chart displaying the process of the output files.

START

Other
VER?

0, 0C

Bad
Cap. Bal.?

Good

Bad
Long. Bal.?

Good

R, B
retest.out DLC?

Over Short
over.out Length?

Medium

Y Y
MTU? MTU?

N N

N Y Y Y
med.out Load Coil? precondition.out Load Coil? short.out

U U

med.unknown.out short.unknown.out

Batch ADSL Pre- Read the following considerations before using the Batch ADSL Pre-qualification
qualification Setup Utility.
and Operational
Considerations

Login and Only the mlt and base logins can execute tests from the Batch ADSL Pre-
Permissions qualification Reports Menu. In order to ensure that the base user has the proper
path, /mlt/ubin should be added to the base user's PATH environment variable
in /base/exec/.profile.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-27

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

Using the Batch It is recommended that only one Batch ADSL Pre-qualification Reports Menu be
ADSL Pre- running at any one time. This will reduce any errors that could occur such as
qualification competition for ownership of threshold values, users cleaning up each other’s
Reports Menu output files, etc. It will also reduce the load on the LoopCare system.

Running ADSL Tests run through the Batch ADSL Pre-qualification feature have the same priority
Tests as normal LoopCare tests (TE/TR, TV, TEST, etc.). This means that Batch ADSL
Pre-qualification tests could interfere with regular test activity if large volumes of
Batch ADSL Pre-qualification tests are scheduled during peak hours. Use caution
when scheduling run times, number of lists, list sizes, and throttling level (how
many tests are sent by Batch ADSL Pre-qualification to LoopCare at once) to
minimize impacts on regular LoopCare testing.

UNIX at command The Batch ADSL Pre-qualification Reports Menu has options that schedule tests
through the UNIX at command. If local procedures have disabled this command,
then scheduling tests can only be done through the UNIX cron utility.

If the at command is available, have your UNIX administrator enable the mlt and
base logins to be able to run commands through at. Unless the mlt and base
logins can run at commands, certain scheduling options of the adsl_menu will
not be able to run.

The at command sends mail to users for things like job startups. Have your UNIX
administrator ensure that at can send mail to the mlt and base logins. Without
mail you may lose important information provided by the Batch ADSL Pre-
qualification utility. It should be used to schedule a run to execute at a later date
and time.

NOTE:
If the at command is not enabled, the minute and day option will not
function.

Creating the Input Input files (for example:. /mlt/adsl/in/lts21.inp) can be created by the user with the
Files for Batch standard UNIX editor (e.g., vi). The file consists of the TNs the user wants to have
ADSL Pre- tested.
qualification Testing

2-28 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Considerations Note the following considerations before creating input files for Batch ADSL Pre-
qualification Testing:
• To minimize LoopCare performance impact, the suggested maximum
number of TNs to include in an input file is 500 TNs.
• To optimize Batch ADSL Pre-qualification test throughput, it is
recommended that each input file contain TNs from the same switch or
from a single cable/pair range.
• Ensure that the input files are formatted correctly to prevent testing from
being interrupted. An improperly formatted TN or a blank line between
entries could stop a test list from running to completion. More than one
entry on a line could prevent TNs from being tested.
• The input filename must be unique and, preferably, appropriate to the site
where the file is generated. You can, for example, incorporate the name of
the local central office or cable name into the output filename. The
alternative is to delete the output file if you are going to re-use it.
• The input filename is used for the output filename,
• If an input file is re-tested, make certain that the corresponding output file
has been deleted, removed, or re-named.

Procedure 1. Create a batch file or files (must be *.inp) in the /mlt/adsl/in/ directory of the
TNs that are to be tested.
Input File Format
Each TN entry must be on a separate line. The format for the data entry is:

NPA-NXX-XXXX (field separator) Line Record Toggle

Where:
• NPA-NXX-XXXX is the TN to be tested. There MUST be dashes (-)
around the NNX entry. (ex. 305-655-1234).
• Field separator is between the TN (field 1) and the Line Record
Toggle (field 2). The field separator can be either a space or a tab.
• Line Record Toggle flag valid responses are Y (override line record)
or N (do not override line record). These have the same meaning as
Y or N on the LoopCare TV or TEST masks. The Line Record
Toggle can also have the six character EXK (Exchange Key) to be
used. This is a user provided exchange key and will override the
Line Record Exchange Key (LREXK) if the LREXK is available or
can be used in place of the default EXK if the LREXK is not
available.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-29

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

An example of an input file is shown below:

2. When the necessary input files are correctly formatted in the /mlt/adsl/in/
directory, use the procedures below to perform ADSL tests on the files
using the Batch ADSL Pre-qualification Reports Menu.

Error Messages Msg: Ignoring Duplicate TN: XXX-XXX-XXXX

When ADSL Testing is performed, LoopCare reads the TNs located in the .inp file
located in /mlt/adsl/in. This file contains a list of TNs that are to be used to perform
ADSL Testing. When the throttle rate is set to higher than "1" and there are
duplicate TNs in the input list, LoopCare will log the error message in the /mlt/
error/altbase_port_name/XXX.err file. Where XXX is the uniquely given file name.
For example if the input TN list contains 555 1234 and list entry number 1 and 555
1234 as list entry number 3 and the throttle rate is set to 3, LoopCare will return
the error message. When LoopCare begins ADSL testing it moves the 3 TNs to an
Active list and looks at the 3 TNs. If these 3 TNs are not unique, meaning there is
a duplicate entry, MTL will not perform the test request on the last duplicate TN,
but will log the error in the XXX.err file. Below is an example of the output error
message:
DATE 07/28/99 10:46:22
EMSGE CODE: 10 EMSG: MLT error (LM50)
Ignoring Duplicate TN: 555 1234

2-30 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Displaying and The Batch ADSL Pre-qualification Reports Menu allows the user to
Running the Batch • Change threshold values or redirect output reports
ADSL Pre-
qualification Menu • Change the test request to be executed
Utility • Schedule Batch ADSL Pre-qualification test execution
• Generate or display reports

To display the Batch ADSL Pre-qualification Reports Menu:

1. Login as mlt. The Batch ADSL Pre-qualification feature will only run
through the mlt login. You may be able to bring up the adsl_menu through
other logins but you will not be able to execute tests unless you are logged
in as mlt.
2. At the mlt prompt, enter:
adsl_menu

ADSL Pre-Qualification Reports Menu

1. Define Short/Medium Loop Length Threshold [4000] feet

2. Define Medium/Long Loop Length Threshold [18000] feet

3. Define Good Capacitive Balance Threshold [98] percent

4. Define Good Longitudinal Balance Threshold [60] dB

5. Define Test Request To Execute, l-loopx, d-dcoilx, q-qualx [l]

6. Define Output Report File [/mlt/adsl/summary/sum.rpt]

7. Schedule Pre-Qualification Run

8. Run Report Generator

9. Print Last Default Report [/mlt/adsl/summary/sum.rpt]

q/Q. Quit ADSL Reports Menu

Enter Option:

3. To make a selection, type the option number at the Enter Option: prompt
and press Enter.
If an invalid option is entered on the main menu, an error message
appears:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-31

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

Invalid Option, Try Again.

4. To exit the Batch ADSL Pre-qualification menu and return to the UNIX
prompt, type q or Q at the Enter Option: prompt and press Enter.

Option 1 - Define The “Short/Medium Loop Length Threshold” is defined as the threshold below
Short/Medium Loop which higher rate ADSL services could be provided. This option allows the user to
Length Threshold adjust the threshold to suit local conditions. The default threshold value is 4000
[4000] Feet feet.

The threshold changes take effect only for the duration that the user is logged into
the adsl_menu. The next time the user logs into the adsl_menu the default
thresholds will be used.

Procedure
1. On the Batch ADSL Pre-qualification Menu, select option 1 - Define Short/
Medium Loop Length Threshold; a prompt appears:
Input New Short/Medium Loop Length Threshold [4000]
feet: _
Where [4000] in this example is the currently defined default short loop
length.
2. Enter a valid threshold value or press Enter to accept the default value
shown in brackets.
• Main menu is returned with the new threshold value displayed in
brackets for option 1.
• Selecting the default value is confirmed with the message and
display of the main menu:
No entry, Threshold remains 4000

2-32 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Error Messages .

Table 2-3. Option 1 Error Messages

Step 2 If an invalid entry (e.g.,. alpha or special characters) is

made, the program treats it as no entry. The current
threshold is retained; the main menu along with the
following error message are displayed.
No entry, Threshold remains 4000
Step 2 If the Short/Medium Loop Length Threshold entered is
greater than or equal to the currently defined Medium/
Long Loop Length Threshold; the main menu along with
the following error message are displayed:
Short/Medium Loop Length Threshold
must be must be less than 18000,
Please try again.

Option 2 - Define The Medium/Long Loop Length Threshold is defined as the threshold at or below
Medium/Long Loop where lower rate ADSL services can be provided. Lines that have a loop length
Length Threshold longer than this threshold cannot be considered ADSL-capable. This option allows
[18000] Feet user to adjust the threshold to suit local conditions. The default threshold is 18000
feet.

The threshold changes take effect only for the duration that the user is logged into
the adsl_menu. The next time the user logs into the adsl_menu the default
thresholds are used.

Procedure
1. On the ADSL Menu, select option 2 - Define Medium/Long Loop Length
Threshold; a prompt appears:
Input New Medium/Long Loop Length Threshold [18000]
feet: _
Where [18000] in this example is the currently defined default Medium/
Long loop length.
2. Enter a valid threshold value or press Enter to accept the default value
shown in brackets.
• Main menu is returned with the new threshold value displayed in
brackets for option 2.
• Selecting the default value is confirmed with the following message
and display of the main menu:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-33

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

No entry, Threshold remains 18000

Error Messages .

Table 2-4. Option 2 Error Messages

Step 2 An invalid entry (e.g.,. alpha or special characters) is

made, the program treats it as no entry. The current
threshold is retained; the main menu along with the
following error message are displayed.
No entry, Threshold remains 18000
Step 2 If the Medium/Long Loop Length Threshold entered is
less than or equal to the currently defined Short/Medium
Loop Length Threshold; the main menu along with the
following error message are displayed:
Medium/Long Loop Length Threshold
must be greater than 4000, Please
try again.

Option 3 - Define Capacitive balance is the ratio of lengths of the tip and ring wires. A capacitive
Good Capacitive balance of 100% indicates a balanced loop.
Balance Threshold
ADSL service is more sensitive to capacitive balance than regular POTS service.
While a capacitive balance of 96%, for example, will not impact POTS service, it
may impact ADSL service.

Use this option to set the threshold for capacitive balance. The default is 98%.
Take note that this value will be used, along with the VER CODE, to determine
whether a line has tested OK. Entries for capacitive balance must be numeric,
with a maximum of three digits.

2-34 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Error Messages

Table 2-5. Option 3 Error Messages

Step 3 An invalid entry (e.g.,. alpha or special characters) is

made, the program treats it as no entry. The current
threshold is retained; the main menu along with the
following error message is displayed.
No entry, Threshold remains at
former value
Step 3 If the system was populated with no response just a
hard return, the system will prompt with the following
error message:
No entry, Threshold remains at
former value.
Step 3 If the system was populated with anything other than
decimal digits, the system will prompt with the following
error message:
Entry was not all digits, Threshold
remains at former value.
Step 3 If the system was populated with a value greater than
100, the system will prompt with the following error
message:
Entry has a value greater than 100,
Threshold remains at former value.

Option 4 - Define The longitudinal balance provides a measure of the line’s susceptibility to noise
Good Longitudinal from inductive sources, especially power lines. It is the ratio of applied signal
Balance Threshold strength to the induced noise, and is measured in decibels (dB). A line with a
higher longitudinal balance is less susceptible to noise than a line with a lower
longitudinal balance.

Use this option to set the threshold for longitudinal balance. The default is 60dB.
Take note that this value will be used, along with the VER CODE, to determine
whether a line has tested OK. Entries for longitudinal balance must be numeric,
with a maximum of two digits.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-35

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

Error Messages .

Table 2-6. Option 4 Error Messages

Step 4 An invalid entry (e.g.,. alpha or special characters) is

made, the program treats it as no entry. The current
threshold is retained; the main menu along with the
following error message are displayed.
No entry, Threshold remains at
former value

Option 5 - Define This option allows the user to select the type of test to run on a line, LOOPX,
Test Request To QUALX or DCOILX.
Execute, l-loopx, d-
dcoilx, q-qualx The LOOPX request will run a series of tests on metallic lines and return results
on the specified telephone numbers. Select the LOOPX test if the Load Coil
feature is inactive or a test head capable of load coil testing is not available for the
target telephone number.

The DCOILX request shall be run to capture loop and load coil results. If the
DCOILX request is selected and cannot be run for the telephone number under
test, then the system will run the LOOPX request. The DCOILX test request can
only be implemented if the Load Coil feature is active and a test head capable of
load coil testing is available for the target telephone number. The testheads
capable of testing for load coils is the Expert Measurement Unit (EMU). The user
can select the type of request on an individual file basis.

The QUALX test performs an on-demand loop qualification test, then drops
access to the telephone line. QUALX provides input to 2 new fields on the ADSL
Prequal output:
• ADSL Down Speed
• Length Measurement Method

To get valid data for these fields, the following features must be enabled:
• SPDBIN - Speed Binning Feature
• LENIMP - Loop Length Accuracy Enhancement Feature

Procedure
1. On the ADSL Menu, select option 5 - Define Test Request To Execute, l-
loopx, d-dcoilx; a prompt appears:

2-36 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Select Test Request l-loopx, d-dcoilx, q-qualx

[l]:
2. Enter a valid letter or press Enter to accept the default value shown in
brackets.
• Main menu is returned with the new threshold value displayed in
brackets for option 5.

Error Messages

Table 2-7. Option 5 Error Messages

Ver Code Displayed Problem/Solution

VER XR - INVALID An invalid entry is made, the Load Coil Feature may be
TEST REQUEST toggled off and cannot run the DCOILX Request. Check
to make sure the feature is on.
REQUEST MUST BE If an invalid selection was entered, the system returns
"L", "D", or "Q", this message. Where X is either the “l” or “d”, depending
REQUEST REMAINS X on the last value set.

Option 6 - Define This option allows the user to select a different file name for the Batch ADSL Pre-
Output Report File qualification output report. The default output filename is sum.rpt in /mlt/adsl/
[/mlt/adsl/summary/ summary. This allows the user to save several output results from Batch ADSL
sum.rpt] Pre-qualification runs.

Procedure
1. On the ADSL Menu, select option 6 - Define Output Report File [/mlt/adsl/
summary/sum.rpt]; a prompt appears:
Input Output Report File [/mlt/adsl/summary/
sum.rpt]:_
2. Enter a valid summary report name (UNIX file name) or press ENTER to
accept the current output filename shown in brackets.
There are no confirmation messages; the new output filename appears in
the main menu text of Option 6.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-37

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

Error Messages .

Table 2-8. Option 6 Error Messages

Step 2 If you enter sum.out as a new output file the program

will return the following error message:
Filename “sum.out” is reserved, using file name
“sum.rpt” on new line. Use option 6 to change.

Option 7 - Schedule Use this option to schedule the Batch ADSL Pre-qualification tests at any one of
Pre-Qualification the following times:
Run 1. at a specified date and time (used for long range scheduling), or
2. any number of minutes from the current time (used for short range
scheduling or for running tests almost immediately with m=1).

NOTE:
These options will not work unless the at command has been enabled.

Considerations

Note the following considerations before running/scheduling Batch ADSL Pre-

qualification Tests:
• If you have more than 20 input files in the /mlt/adsl/in directory when you
schedule an Batch ADSL Pre-qualification run, only 20 lists will be tested.
Confirmation messages will identify which lists were successfully
scheduled and which were not. NOTE: An entire directory, not just
individual files, must be scheduled at one time.
• If the execution of any Batch ADSL Pre-qualification test list or lists is in
progress, ensure that all of these lists complete before you execute any
further tests. If you do execute a second set of Batch ADSL Pre-
qualification lists (set 2) while a previous set (set 1) is running, there is a
risk that you may lose all or some of the test results from set 2.

Batch ADSL Pre- The Throttling Level determines the rate at which tests are sent from the Batch
qualification ADSL Pre-qualification to LoopCare and therefore the speed that lists finish
Throttling Level testing and also the load placed on the system. The main menu allows the user to
select the rate at which tests are sent to LoopCare. The valid throttling rates range
from 1 (one at a time) to 4 (4 simultaneous tests sent) for each input file in the in
directory.

2-38 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

The current throttle level is either the default level (1) or the level that was set on
the last run of the utility.

Option 7a - Run 1. On the ADSL Menu, select option 7 - Schedule Pre-Qualification Run; a
ADSL Test at prompt appears:
Specified Date/Time Specify to run at a given date/time [D/d] or minutes
from now [M/m]? _
2. Enter d or D (date/time); a prompt appears
Enter time (currently 13:49:17) to run ADSL [hh:mm]
(hh=00-23): 10:30:45
where 10:30:45 is the current time.
3. Enter the scheduled time (hh:mm) in 24 hour format, 2-digit hour:2 digit
minutes, e.g., 13:45; a prompt appears:
Enter date (mm/dd) to run ADSL [02/08]: _
where [02/08] is today’s date (default).
4. Enter the scheduled date in the mm/dd format, e.g., 02/08 (or press Enter
to accept the default date shown in brackets); a prompt appears:
Using Today’s date (appears for default date only)
Simultaneous Test Throttling Level (1-4) [1] _
where (1-4) is range of valid entries; [1] is the previous entry.
5. Enter the desired throttling level, or press Enter to keep the current level
shown in brackets); a prompt appears:
Running ‘ADSL -n2 -r1’ at <13;45> on <02/08>, OK [Y/
n]?:
6. Enter Y or press Enter to run the ADSL test at the specified date and time;
test execution confirmation appears:
Generating at 18:40 02/08 < /mlt/ubin/ADSL -n1 -r1 job 12345.a at Fri Feb
8 18:40:00 1998
7. Use ADSL menu option 8 Run Report Generator to run a report of the test
results, and/or view the output files in directory /mlt/adsl/summary.
Refer to ADSL Results and Output Files in this section.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-39

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

Error Messages

Table 2-9. Option 7a Error Messages.

Step 1 If an invalid input (numbers, alpha other than D/d or M/

m, etc.) the menu will query you for a valid input with the
following message:

You Must enter ‘D’ ‘d’ ‘M’ or ‘m’

Further invalid entry at this point returns user to the

main menu.
Step 3 If an invalid entry is made for Time, the user will be
prompted again to enter a valid format:

Please enter a valid time [hh:mm]:

If the user fails to enter a valid time at this prompt the

program exits back to the main menu with the following
error message:

Numerous failures, quitting

Step 4 If an invalid entry is made for Date, the program defaults
to the current date to schedule the ADSL test and the
following message appears:

Invalid date format, Using today’s date

Step 5 An invalid entry (e.g., 0, > 4, alpha, etc.) results in the
default or current throttle level being set and the
following error message:

Invalid (or no) input, throttling level set to

X
where X is either the default or current throttle rate (in
range of 1-4).

2-40 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Table 2-9. Option 7a Error Messages.

Step 6 If the date and time entered is earlier than the current
date and time the test will not be run and the program
will return the following error message before returning
to the main menu:
Generating at 01;00 02/05 < /mlt/ubin/ADSL -n2
command too late
Step 6 If an invalid entry is made to the Run confirmation,
prompt the program assumes an N/n entry and stops
execution of the list.
Step 6 If a Y was entered but an output file exists for one or
more of the input files the following messages appears:

Output file for filename.inp exists! Did you

already run ADSL on it?? Filename.inp not

processed

Option 7b - Run 1. On the ADSL Menu, select option 7 - Schedule Pre-Qualification Run; a
ADSL Test at prompt appears:
Specified Minutes Specify to run at a given date/time [D/d] or minutes
From Current Time from now [M/m]? _
2. Enter M or m (minutes); a prompt appears:
Run ADSL in how many minutes from now [1]? 15
where [1] is the default.
3. Enter the number of minutes (0-99). A prompt appears:
Simultaneous Test Throttling Level (1-4) [1] 3
where (1-4) is range of valid entries; [1] is the previous entry.
4. Enter the desired Throttling Level, or press Enter to keep the current level
shown in brackets.
Running ‘ADSL -n2 -rl’ in 15 minutes, OK [Y/n]?:
5. Enter Y or press Enter to run the ADSL tests at the specified date and time,
(n to cancel); for test execution, confirmation appears:
Generating at now + 15 minutes < /mlt/ubin/ADSL -n2 -r1
-rdjob 12346.a at Fri Feb 8 18:45:00 1998

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-41

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

6. Use ADSL menu option 8 - Run Report Generator to run a report of the
test results, and/or view the output files in directory /mlt/adsl/summary.
Refer to ADSL Results and Output Files in this section.

Error Messages .

Table 2-10. Option 7b Error Messages

Step 3 An invalid entry for minutes (alpha, special characters,

return no entry) will display the following error:

Please Enter a Number:

If the user fails to enter a valid time at this prompt, the

program exits back to the main menu with the following
error message:
Numerous failures, quitting

Option 8 - Run This option allows the user to generate a report on the output data currently found
Report Generator in the /mlt/adsl/out directory. The report is usually run after a test is completed.
The summary report generated is contained in the file sum.rpt (default filename) in
/mlt/adsl/summary (sum.rpt may be changed by Option 5 if desired).
1. On the ADSL Menu, select option 8 - Run Report Generator; a prompt
appears:
Processing messages appear followed by the output report, for example:
processing /mlt/adsl/out/test.inp.out
processing /mlt/adsl/out/test2.inp.out

2-42 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Sample Report

Error Messages

Table 2-11. Option 8 Error Messages.

Step 1 If option 8 is selected and there are no output files in the

/mlt/adsl/out directory, no report will be generated, and
the following error message will be displayed:
/mlt/adsl/out/*inp.out not found

Option 9 - Print Use this procedure to display the default output report (sum.rpt) without having to
Last Default Report generate a new report. You may want to do this if you are using default files only.
[/mlt/adsl/summary/
sum.rpt] For example, if two Batch ADSL Pre-qualification test runs have been made and a
report has been generated on the first one but not the second, you will lose the
report summary on the first run if you choose Batch ADSL Pre-qualification menu
option 8 (Run a Report Generator). With option 9, you can look at the previous
report data stored as sum.rpt. Option 9 only looks for a file named sum.rpt. It does
not display the last report file if it is stored under any other name.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-43

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

One way to save this data is to change the filename of the output report to a new
name. Then sum.rpt will not be overwritten.
1. Select option 9 - Print Last Default Report [/mlt/adsl/summary/sum.rpt].
Processing begins and the report is generated (sample shown below):
Sample Report

Error Messages .

Table 2-12. Option 9 Error Message

Step 1 If there is no file sum.rpt in /mlt/adsl/summary, the

following error message is displayed:
/mlt/adsl/summary/sum.rpt: No such file
or directory

2-44 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Running the Batch The Batch ADSL Pre-qualification test could be run from the UNIX cron utility as
ADSL Pre- well as from adsl_menu. It is assumed that the user knows how to set up and run
qualification a cron job.
Program From a
cron File NOTE:
If the execution of any ADSL Pre-qualification test list or lists is in progress,
make certain that all of these lists complete before you execute any further
lists.

Note also that since cron will run tests at scheduled intervals, the user must
always make sure that output files are cleaned up or stored properly.

The command line entry that could be used in the cron file to run an Batch ADSL
Pre-qualification test is shown below:
/mlt/ubin/ADSL -nX - rY

Where X is a value 1-4 to indicated throttling rate of tests sent by ADSL to

LoopCare and Y is either ‘l’ for LOOPX or ’d’ for DCOILX.

Error Messages If the following error message appears:

sh[116]: ulimit: The specified value exceeds the user’s

allowable limit.

The user needs to make an entry in the .proto file. This file is located in the
/var/adm/cron directory. The user should log into the system as root and
enter the following commands:
(12:33)bdmlt53-283: cd /var/adm/cron
(12:33)bdmlt53-284: cat .proto

Use the vi editor to modify the .proto file by replacing the line
ulimit $l

with the following lines:

NOTE:
In the following lines, the $l value contains a lower-case letter L, and not a
numeric one (1).

if [ $l -eq 4194304 ]
then

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-45

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

ulimit unlimited
else
limit $l
fi

By doing this, the system will not return the error message and will proceed with
cron processing.

You may verify that the correct environment settings are called into a scheduled
at job by viewing the associated environment at job posted under the following
directory:
/var/spool/cron/atjobs.

Knowing When When the Batch ADSL Pre-qualification program has completed testing all
Batch ADSL Pre- numbers of an input file, a message is written to a trace file in the /mlt/trace
qualification Testing directory. The trace file follows the naming convention adslX.trc, where X is the
is Completed base port associated with each input file when it is scheduled or executed. The
PORT name is displayed to the user by the Batch ADSL Pre-qualification
program.

Viewing Detailed To see more detailed test results than is provided by the Batch ADSL Pre-
Batch ADSL Pre- qualification summary reports, look at the applicable output files in directory /mlt/
qualification Test adsl/out. This directory contains the output files for each test run (e.g.,.
Results lts21.inp.out or retest.inp.out) or the /mlt/adsl/summary/ files like short.out,
med.out, over.out, retest.out, recondition.out, short.unknown.out,
med.unknown.out.

When the Speed Binning feature is turned on, the Batch Pre-Qualification output
file has two additional columns:
• ADSL Down Speed Kbps
• Length Accuracy

The data format for all output files in directory /mlt/adsl/out is shown below:

2-46 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

NOTE:
The headings in the following table do not appear in the file. They are
presented here only for identification purposes.

Length
Telephone DLC Cap Long Length Load ADSL Down Measurement Insertion
Date Time Number VER Length Indicator .Bal .Bal Origination Coils EQPT Speed Kbps Method Loss (dB)

02/16/1998 15:59 305-555-1111 0 13500 B 99 65 C U N 2400 E 45

02/17/1998 16:00 305-555-1112 0C 3999 R 100 62 R Y N U S 19

02/16/1998 15:59 305-555-2111 0 3500 R 100 64 R Y N 8500 E 17

02/17/1998 16:00 305-555-2112 41 NA R ? ? C U N 3500-3700 S NA

02/16/1998 15:59 305-555-3111 0 3500 N 99 65 C 2 N 8500 E 59

02/17/1998 16:00 305-555-3112 0 3999 N 100 65 C 3 N U S 65

02/16/1998 15:59 305-555-4111 0 23500 B 100 65 C U N 425-500 E NA

02/17/1998 16:00 305-555-4112 0 3999 R 94 65 R Y N 8500 E 40

02/16/1998 15:59 305-555-5111 0 3500 B 100 65 R N N 8500 E NA

02/15/1998 11:01 305-555-3111 75 3600 N 100 65 R N N 0-0 E 45

ADSL2+ READSL
Down Down
Speed Kbps Speed Kbps

U U

U U

U U

U U

U U

U U

U U

U U

U U

U U

Where:
• Date of test is presented in standard UNIX time stamp. For example: 02/07/
1998.
• Time of test is presented in 24-hour format. For example: 14:04.
• TN is the 10 digit customer TN that was tested.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-47

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

• VER Code is the standard 2-character VER code returned with LoopCare
tests.
• Loop Length is the measured value, in feet, of the loop length returned by
LoopCare. If no loop length was measured this field will contain NA.
• For DLC Indicator the following codes are valid.

NOTE:
Identification of DLC by DC signature is only possible if the DLC Testing
feature is active.

— B= Uncalibrated Bypass: This indicates that the DLC system is

tested using a Bypass Pair
— C= This indicates a ByPass Pair that is Calibrated.
— N=Central Office. This indicates that there is no DLC system.
— R=RMU. This indicates that the DLC system is testing using an
RMU (Remote Measurement Unit)
— Y=DLC. Digital Loop Carrier (DLC) is present but it is not known
whether an RMU (Remote Measurement Unit) is present or whether
a by-pass pair is used.
— NA=Not Available. Test failure, equipment busy, or timeout.
• Capacitive Balance is a measurement, expressed as a percentage, of the
ratio of the tip and ring conductor lengths for this loop. If no balance was
measured, this field displays NA.
• Longitudinal Balance is a measurement, in decibels, of how susceptible the
line is to induced noise. If no balance was measured, this field displays NA.
• For Length Origination the following codes are valid:
— C-=Central Office: This indicates that the loop length reported is the
distance from the Central Office.
— R=Remote Terminal. This indicates that the loop length reported is
the distance from the Remote Terminal. This is the case if testing
was performed using an RMU or if the loop length was calibrated
using the DLC Loop Calibration feature.
• For Load Coils the following codes are valid:
— N=No Load Coils: Indicates that there were no load coils detected.
— U=Unknown. This indicates that the load coil test was not done. This
may be because LOOPX was requested, the Load Coil feature was
off, or the target switch did not have a load coil capable test head.
The DMU-C and DMU-R Test Heads are the only test heads
currently that can detect load coils.

2-48 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

— Y=Load Coils Detected. This indicates that load coils were detected.
However, the test head did not return a count of the number of load
coils.
— 1 - 4 - Number of Load Coils Detected. This indicates the number of
load coils that were detected.
• The following are valid values for EQPT:
— A = ATU-C Maintenance Signature.
— B = bPON
— I = ISDN NT1
— K = Key System
— M = MTU
— N = None
— P = PBX
• ADSL Down Speed Kbps - If the speed binning feature is on, the speed bin
data rate for the associated telephone number is displayed for the QUAL
request; otherwise, a “U” is displayed for “Unknown.” The U value is
obtained when the results from QUALX do not match the necessary
conditions required to provide data rate predictions. For additional
information, see the Test Request User Guide.
The data displayed can be either a range, a high value or a low value,
depending on the setting of the DATARATE_DISPLAY variable in
MGRP.env.
A data rate of 0 (zero) is displayed as "0 - 0".
Up to 2 ADSL Down Speed Kbps values may be displayed depending on
the DSL types selected on the FEATURES/QUAL/QUAL DSL TYPES form.
These appear after the Insertion Loss column.
• Length Measurement Method. The method of measuring length. Valid
values:
— E - Enhanced Length Accuracy - Displayed if the loop length
accuracy improvement feature is on and the TR capacitive length is
used.
— S - Standard Length Accuracy - Displayed if the loop length
accuracy improvement is not on or the loop length accuracy
improvement feature is on but the TG capacitive loop length is still
used.
• Insertion Loss (dB). The Loop Insertion Loss in dB.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-49

System Administration Guide LoopCare Administration
Batch ADSL Pre-Qualification Testing

Considerations • An output file is generated for each input file tested.

• It is expected that these output files will be saved or removed after they
have been examined. Failure to clean up output files could result in
problems running tests from this feature.
• If you try to re-run a specific input file but have not removed its associated
output file the Batch ADSL Pre-qualification program will not execute the
test. This may be a particular problem if Batch ADSL Pre-qualification tests
are scheduled through cron. Since cron will run tests at scheduled
intervals, the user must ensure that the output files are cleaned up or
stored properly. An error message will be displayed output files are not
periodically removed.

Error, Trace, and The Batch ADSL Pre-qualification feature provides the following additional
Mail Files for the information files:
User • /mlt/error/adslX.err - where X is the base port associated with each input
file scheduled or executed. The X name is displayed to user by the ADSL
program. The error files contain messages describing problems
encountered during the run such as errors processing TNs in an input file.
• /mlt/trace/adslX.trc - where X is the base port associated with each input
file scheduled or executed. The X name is displayed to user by the ADSL
program. The ADSL program will write a message to the trace file for each
list when that list has completed testing. This is one way to identify when a
list is done.
• mail to mlt login - when ADSL tests are sent through the at command or
cron utility, the user will receive mail indicating that the job has been sent.
For the at command (used by the D and M test scheduling options), any
information written to standard out by the ADSL program will be mailed to
mlt.

wrapperadmin The wrapperadmin utility enables administrators start/stop batch testing through
Utility the Wrapper and monitor testing through generated reports which summarize
overall or daily testing results. There is an additional report that summarizes the
verification codes reported from the testing, This summary allows the
administrator to gauge the usefulness of the data being collected and determine
whether there are resource issues that need to be addressed.

When you run wrapperadmin from a UNIX command line the following screen is
displayed:

2-50 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Batch ADSL Pre-Qualification Testing

Select option 1 to start or stop or view current testing or option 2 to view reports.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-51

System Administration Guide LoopCare Administration
Calibrating a DLC Bypass Pair

Calibrating a DLC Bypass Pair

Overview In order to perform loop qualification with both TG/RG and TR length data, the
following procedure must be used to calibrate trunk groups and bypass pairs.

Procedure Use the following procedure to calibrate a DLC bypass pair:

1. Do a CO Trunk Calibration on all trunks in the CO that can be used to test
lines in the DLC whose bypass pair is being calibrated.
2. Choose a telephone number that is open at the RT site or the RT reference
point.
3. Run a REF1 test on this number from the Test GUI or TV Mask and record
the Calibration Distance and the T-R Calibration Distance that are reported
in the test results.
4. Have a craft at the RT site place a T-R short across the line and repeat the
REF1 test and record the Calibration Resistance. If the bypass pair is
known to use a Tollgrade Metallic Channel Unit (MCU), this step may be
skipped and the default value of 1275 Ohms may be used as the
Calibration Resistance. For a more accurate resistance calibration, this
step should be done even with an MCU present.
5. Go to the oam / ADEF / RT WIRE CENTER screen for the RT being
calibrated and enter the data in the following fields:
• Calibration Distance in the Distance field
• T-R Calibration Distance in the TR Distance field
• Calibration Resistance data in the Resistance field
6. Save and Submit the changes.
7. Activate the changes in UIP.

2-52 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Calibrating a Switch for Loop Insertion Loss

Calibrating a Switch for Loop Insertion

Loss

Overview In order to perform loop insertion loss qualification with the DMU+L test head for
loops accessed via a Switch, the following procedure must be executed to
calibrate the switch. The switch type determines whether single loop insertion loss
calibration or multiple insertion loss calibration is required.

Procedure with Use the following procedure to calibrate a switch for loop insertion loss
Single Calibration qualification measurements when a single calibration value is sufficient for the
Value switch:
1. On the Switch-OE ADEF form, add an a entry where the OE range = "-" to
"-", signifying that the REF0 test request performs a single calibration for
the switch.
2. Choose a telephone number (TN) to use for the calibration.
3. On the MDF, remove the heat coil associated with this TN and replace it
with the Loop Insertion loss Calibration Module (LCM). When properly
installed the RED led is lit.
4. Run a REF0X test on this TN from the Test GUI or TV Mask.
If the test successfully performs calibration and stores the results in the
database, the message displayed in the test results is “Calibration Data
Loaded in Database". In this case, the "Loss Calib" field is checked on the
ADEF Switch-OE form associated with the OE.
If the calibration fails, the test results message is "Calibration Failed".
5. Remove the LCM from the MDF and replace it with a heat coil for this TN.

Procedure with Use the following procedure to calibrate a switch for loop insertion loss
Multiple qualification measurements when a multiple calibration values are required for the
Calibration Values switch. OE retrieval is used to identify each grouping of lines served by a Line Unit
on the switch.
1. On the Switch-OE form, add an OE range for each group of lines served by
a Line Unit (LU) on the switch. OE retrieval maps the telephone numbers
associated with this line to an OE in this range.
2. For each OE range, choose a telephone number (TN) within that range to
use for the calibration.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-53

System Administration Guide LoopCare Administration
Calibrating a Switch for Loop Insertion Loss

3. On the MDF, remove the heat coil associated with this TN and replace it
with the Loop insertion loss Calibration Module (LCM). When properly
installed the RED led is lit.
4. Run a REF0X test on this TN from the Test GUI or TV Mask. OE retrieval
should map this TN to the associate OE range entered on the Switch-OE
form.
If the test successfully performs calibration and stores the results in the
database, the message displayed in the test results is “Calibration Data
Loaded in Database". In this case, the "Loss Calib" field is checked on the
ADEF Switch-OE form associated with the OE.
If the calibration fails, the test results message is "Calibration Failed".
5. Remove the LCM from the MDF and replace it with a heat coil for this TN.
6. Repeat this for each OE range entered in the Switch-OE table.

NOTE:
A "-" OE entry can be used to calibrate TN's that are not mapped to any
other OE range.

2-54 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Wideband Testing Feature

Wideband Testing Feature

Overview The LoopCare Wideband Testing feature extends LoopCare analysis and flow-
through support to xDSL lines accessible by either a Tollgrade TelAccord MTAU,
DAU 1000, Lucent Stinger DSLAM or Lucent AnyMedia Shelf. In addition to the
standard complement of voiceband tests used to determine the condition of a
POTS line, LoopCare wideband testing adds additional tests to detect, measure
and quantify loop conditions outside of the voiceband range. These conditions,
such as the presence of load coils, bridged taps and wideband noise, can have a
substantial impact on actual data throughput achieved on a xDSL circuit.

The Wideband testing feature has been designed in a manner to allow for
customer tuning of wideband test parameters, error thresholds and analysis
modes on a per LoopCare system basis. In particular, through the implementation
of gdf options and modifications to a central control table, it is possible to modify
the following test and analysis characteristics:
1. Detailed wideband test input parameters
2. Critical noise margin threshold
3. Fault analysis mode
4. Data rate prediction thresholds

This section will detail the steps required to properly configure the LoopCare
system for wideband testing.

System The following steps are required to configure the LoopCare system for wideband
Configuration testing:
1. Install a new mlt.feature file to enable the Wideband testing feature.
2. Determine the value for the MLTSERVER environmental variable. This
value should be the fully qualified domain name (that is,
'mymachine.mydomain.mycompany.com' versus simply 'mymachine') for
the given machine. The MLT_SERVER variable is required to allow cross-
machine testing (that is, a test is initiated on one machine but actually
performed on another).
3. Using the UIP, set the environmental variable determined above as follows:
• Select option 3, System Administration from the main menu.
• Select option 4, Set Environment.
• Select option 5, MLT group (MGRP).
• Set the MLTSERVER variable as determined above.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-55

System Administration Guide LoopCare Administration
Wideband Testing Feature

Exit the MLTUIP.

4. Add the following wideband gdf options:

Group Module Option

MGRP $MLT_BIN/m2r -w
M2 $MLT_BIN/tserc -F

NOTE:
While the above options are not absolutely required to enable wideband
testing, they allow for future tuning of input parameters and analysis
thresholds at a later time without requiring a bounce of the LoopCare
application.

5. Copy the wideband control table to its active name as follows:

cd $SRCNODE/adsl
cp .WBdata WBdata
6. Bounce the MGRP application.

Customization Analysis Mode:

Two analysis modes are provided within the Wideband testing features:
• Data Rate Prediction Mode
• Critical Noise Margin Mode

Data Rate Prediction Mode

Data Rate Prediction mode is the default analysis mode. It attempts to estimate
the data rate supported on the given loop through analysis of the loop topology,
calculated loop signal strength and measured noise. Analysis is performed for
both 24 gauge and 26 gauge cable.

Data rate prediction can be optimized for two modem types, ASAM Speedtouch
and Stinger Cellpipe.

Optimization of data rate prediction for ASAM Speedtouch

1. Add XDSL_MODEM=SPEEDTOUCH to the M2.env file.
2. In OAM, use the FEATURES => WIDEBAND => MODEM PARAMETERS
=> ADSL path to access the ADSL MODEM PARAMETERS form.

2-56 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
Wideband Testing Feature

3. Set the following fields to the indicated values:

Minimum Bits Per Tone = 2
Maximum Bits Per Tone = 14
Channel Width = 3800
Margin = 0
Receiver Adjustment = 3

Optimization of data rate prediction for Stinger Cellpipe

1. Add XDSL_MODEM=CELLPIPE to the M2.env file.
2. In OAM, use the FEATURES => WIDEBAND => MODEM PARAMETERS
=> ADSL path to access the ADSL MODEM PARAMETERS form.
3. Set the following fields to the indicated values:
Minimum Bits Per Tone = 2
Maximum Bits Per Tone = 10
Channel Width = 3800
Margin = 0
Receiver Adjustment = 0

Critical Noise Margin Mode

Critical Noise Margin mode can be activated in place of Data Rate Prediction
mode by adding the '-n' gdf option to the tserc startup line in M2.gdf. It simply
reports the first frequency band at which the measured noise level is within the
defined critical noise margin (described below) of the calculated loop signal
strength. This analysis is also performed for both 24 gauge and 26 gauge cable.

Optimization Mode:

Using the Data Rate Optimization feature in conjunction with Data Rate Prediction
analysis, one can determine the most appropriate remedial actions that will result
in a data rate improvement, or optimization.

LoopCare makes noise and TDR measurements on the loop and constructs a
computer model, predicting the maximum data rate the loop can handle. Any
significant bridged taps or noise disturbers that can be identified on the loop and
which can be modeled, are subtracted from the model to predict the resulting data
rate. From the results of this exercise, the Data Rate Optimization feature
provides a recommendation for removal of the most common sources of data rate
degradation from the loop.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-57

System Administration Guide LoopCare Administration
HUB Alarm Handler

HUB Alarm Handler

Overview Each LoopCare server with the HUB feature has a HUB alarm handler subsystem
which processes alarms from HUB test heads. You can configure the services
provided by the alarm handler by editing the HubAlarmServer.properties file. The
configuration parameters are documented in the properties file.The Installation
Guide outlines the procedure for installing this file. The System Description
provides an overview of HUB alarm functionality.

The hasadm utility starts and stops the alarm handler.

Configuring HUB Table 2-13 on page 2-58 summarizes the alarm handler services and their
Alarm Handler parameters. The HubAlarmServer.properties file provides detailed documentation
Services on parameter names and values.

Table 2-13. Parameters for Hub Alarm Server Properties File

Service Parameters
Log alarms into a text file, by Enable/Disable logging to a text
default, /mlt/reports/HubAlarm.txt file
Path name of log file.
Alarm filter
Log alarms into the hubalarmlog Enable/Disable logging to a text
Oracle database. file
Alarm filter
Send email notifications. Enable/Disable logging to a text
file
Alarm filter
List of email addresses
Subject line
Format

To change the service configuration, edit your local properties file, /mlt/apps/has/
HubAlarmServer.properties.local, and bounce MRGP.

The MLT mltclean.sh module cleans up the HubAlarm.txt file.

2-58 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration System Administration Guide
HUB Alarm Handler

Starting and The /mlt/ubin/hasadm utility is used to start or stop the hub alarm handler and to
Stopping the Alarm display its status.
Handler
Usage
hubalarm[start|stop|status]

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-59

System Administration Guide LoopCare Administration
Calibrating HUB TMU MDF Trunks

Calibrating HUB TMU MDF Trunks

Background The offsets on the TAP data page associated with the HUB Slot Equipage ADEF
form specify the length and resistance that is subtracted from the actual test
measurements. These offsets are calibration values that remove the effect of the
TMU tap from the results displayed to the tester.

The Delta Length field on the MDF Trunk screen and the Delta Res (resistance)
field on the MTG screen are thresholds used to determine whether or not a fault
condition is in or out of a particular loop location, for example, the central office.

Procedure 1. Set the TAP length and resistance fields on the TAP data screen to 0.
2. SAVE and SUBMIT the ADEF changes.
3. Set the Delta Res (resistance) field on the MDF trunk screen to 0.
4. Set the Delta Length field on the MTG screen to 0.
5. SAVE and SUBMIT the ADEF changes.
6. ACTIVATE the database.
7. BUILD the test head.
8. Open the pair at the Main Distributing Frame.
9. Run the LOOP(X) test to determine the TAP length.
10. Short the pair at the Main Distributing Frame.
11. Run the LOOP(X) test to determine the TAP resistance.
12. Set the TAP length and resistance fields on the TAP data screen to the
values determined in steps 9 and 11.
13. SAVE and SUBMIT the ADEF changes.
14. Set the Delta Res (resistance) field on the MDF trunk screen to its original
value.
15. SAVE and SUBMIT the ADEF changes.
16. Set the Delta Length field on the MTG screen to its original value.
17. SAVE and SUBMIT the ADEF changes.
18. ACTIVATE the database.
19. BUILD the test head.

2-60 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

LoopCare Administration
Calibrating the Siemens EWSD Switch with Integrated System Administration Guide
Testing

Calibrating the Siemens EWSD Switch

with Integrated Testing

Background To calibrate EWSD switches that utilize internal testing resources for metallic
testing, it is necessary to perform a one time manual calibration and enter the
results on the ADEF Switch Integrated Testing form for the EWSD switch.

Procedure 1. Set the TAP Res and TAP Len fields on the Switch Integrated Testing
screen to 0.
2. SAVE and SUBMIT these changes.
3. Select a line that is open at the MDF and represents the average electrical
distance from all DLUs in the office to the MDF. Assign it's TN to the CAL
TN field on the Switch Integrated Testing screen.
4. Place a Tip-Ring (T-R) short on this line at the MDF and run a LOOP test.
Record the T-R resistance.
5. Open the line at the MDF and run a LOOP test. Record the loop length.
6. Set the TAP Res field on the Switch Integrated Testing screen to the T-R
resistance recorded in step 4.
7. Set the TAP Len field on the Switch Integrated Testing screen to the loop
length recorded in step 5.
8. Set the Delta Len field on the Switch Integrated Testing screen to the
length LoopCare uses to classify an open as inside the exchange or in the
loop.
9. SAVE and SUBMIT these changes.
10. ACTIVATE the database.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 2-61

System Administration Guide LoopCare Administration
Calibrating the Siemens EWSD Switch with Integrated

2-62 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation 3

Contents

• Introduction 3-2
• HP System Backup 3-3
• SUN System Backup 3-6
• Database Backup and Recovery 3-17
• Database Recovery 3-23
• LoopCare Failover 3-33

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-1

System Administration Guide System Operation
Introduction

Introduction

Overview This chapter provides instructions for performing the following system
administrative tasks:
• System Backup
• Database Backup and Recovery
• LoopCare HCFE Failover

3-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
HP System Backup

HP System Backup

Overview The LoopCare administrator should perform a periodic system backup of all files
on the HP machine including LoopCare system files, other application files, and
UNIX files. This ensures that all LoopCare application and working files in the
directory /mlt are protected in the event of a disk or power failure. Two methods
for system backup are available as shown below.

NOTE:
Perform the system backup procedure at a time when few or no users are
logged into LoopCare.

Full Backup The full backup is the safest and recommended system backup procedure. It
backs up all application and UNIX files on the HP machine. The procedure kills all
current processes (except root) and warns current users to log off prior to the
backup.
1. Login as root:
su - root
passwd:
2. Enter the following command to go into single user mode and shutdown the
system:
shutdown -y 60

This command initiates a message that gives users 60 seconds to logoff before
the system is shutdown.
1. To backup all LoopCare system files; enter the following commands:
mount -a
fbackup -0 -f <tape/disk device> /mlt
2. You can also back up BASE, as required, depending on your environment:
fbackup -0 -f <tape/disk device> /base

This will backup all LoopCare system files to the specified disk/tape device.
1. To reboot the system, enter:
reboot

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-3

System Administration Guide System Operation
HP System Backup

System Backup This procedure will backup LoopCare system files and files of current users into a
special LoopCare file. Note that the procedure stops and backs up only LoopCare
processes.
1. Login as base.
su - base
passwd:
2. Run base.
3. Stop all LoopCare processes; enter the command:
stop mlt
The following message is displayed:
stopping mlt
4. Enter the following command
quit
5. Display special files that will be used as a backup area for current users:
vgdisplay -v | grep mlt

This will display the two special files (sample format below):
/dev/vg00/mlt
/dev/vg00/rmlt
6. Place current user files into one of the special files.
7. Determine if the special file is not in use:
fuser -u </dev/vg00/mlt> <special file>
where </dev/vg00/mlt> is the special file. If the file is not in use, the desired
output is:
empty
8. Backup the system; enter:
fbackup -0 -f <tape/disk device> /mlt

NOTE:
The backup process will skip files currently in use.

9. When the backup is completed, login as mlt.

10. Access the OA&M main menu and select UIP.
11. To start LoopCare, make the following menu selections:
System Administration
Start

3-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
HP System Backup

MLT Application
12. To respond to the prompt,
Cold or Warm start? [c/w/q]:
13. Type c (cold start) and press Enter.
STARTING MLT APPLICATION
14. Press <CR> to return to the System Administration menu, and exit UIP.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-5

System Administration Guide System Operation
SUN System Backup

SUN System Backup

Overview The LoopCare administrator should perform a periodic system backup of all files
on the SUN machine including LoopCare system files, other application files, and
UNIX files. This ensures that all LoopCare application and working files in the
/base and /mlt directories are protected in the event of a disk or power failure. It is
also recommended to backup the ORACLE database (see Database Backup and
Recovery: page 3-17).

The full backup is the safest and recommended system backup procedure. It
backs up all application and UNIX files on the SUN machine. The procedure kills
all current processes (except root) and warns current users to log off prior to the
backup.

You will need approximately 5 gigabytes of space to back up all the directories,
FTP these files to a safe repository. The files are listed below to provide data on
storage requirements.
-rw------- 1 root other 998703104 Dec 30 11:45 mltdump
-rw------- 1 root other 60588032 Dec 30 11:46 basedump
-rw------- 1 root other 1015808 Dec 30 11:47 db1dump
-rw------- 1 root other 1015808 Dec 30 11:48 db2dump
-rw------- 1 root other 1015808 Dec 30 11:49 db3dump
-rw------- 1 root other 1015808 Dec 30 11:50 db4dump
-rw------- 1 root other 2998763520 Dec 30 12:03 oracledump
-rw------- 1 root other 24313856 Dec 30 12:58 apachedump
-rw------- 1 root other 5242880 Dec 30 12:58 tomcatdump
-rw------- 1 root other 11960320 Dec 30 13:17 snmpdump
-rw------- 1 root other 15368192 Dec 30 13:17 inprise

Procedure 1. Login as root. If you are logging in from a telnet window, do not su to root.
2. Stop all LoopCare applications:

/etc/init.d/loopcare stop
/etc/init.d/oracle stop
/etc/init.d/apache stop
/etc/init.d/syslog stop

3-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
SUN System Backup

3. Determine where the LoopCare file system was installed, in this example,
it is under /export/spare. In some cases, it can be /export/home or /
LoopCare: # df -k /loopcare.
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t0d0s7 32016550 16044508 15651877 51% /export/spare
4. Verify that there is no activity on the target file system, /export/spare.
Un-mounting and mounting the file system with no errors ensures that
there no activity on the target file system before backups are performed.
umount /export/spare
mount /export/spare
5. 5. Determine the location of the directory structures that you want to back
up. The following is an example of the directories under LoopCare to be
backed up.

NOTE:
Your LoopCare system may be saved under a different directory structure.
You may also have additional Oracle directories which will have to be
saved as well.

cd /export/spare/loopcare
ls -lt
total 16
drwxrwxr-x 26 mlt baseadm 512 Jun 13 10:12 mlt
drwxr-xr-x 2 oracle dba 512 May 15 13:48 db3
drwxr-xr-x 2 oracle dba 512 May 15 13:48 db1
drwxr-xr-x 2 oracle dba 512 May 15 13:47 db2
drwxr-xr-x 3 oracle dba 512 May 15 13:05 oracle
drwxr-xr-x 2 oracle dba 512 May 15 13:03 db4
drwxrwxr-x 19 base baseadm 512 May 7 2002 base

Backing up Apache, It is also recommended that you back up the apache, tomcat, inprise,
Tomcat, inprise, snmp, etc. directories. The following is an example of finding the location of
snmp the apache and tomcat directories.

NOTE:
Your apache, tomcat, inprise and snmp directories may be saved under a
different directory structure. The examples below assume the following
directory structure

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-7

System Administration Guide System Operation
SUN System Backup

6. Enter the following commands:

cd /opt
ls -lt
drwxrwxr-x 15 root sys 512 Dec 4 12:01 apache2
drwxrwxr-x 12 base baseadm 512 Dec 4 12:01 tomcat
drwxrwxr-x 3 root bin 512 Nov 12 19:29 inprise
drwxr-xr-x 3 root sys 512 Nov 12 14:41 snmp

Backup Command The basic command for backing up a directory structure is:
ufsdump 0f /export/spare/mltdump.0714 /export/spare/
loopcare/mlt

NOTE:
0f is zero f.

Examples of The following are examples of each directory backup.

Directory Backups ufsdump 0f /export/spare/mltdump.0714 /export/spare/loopcare/mlt

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Mon Jul 14 16:01:25 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (hannibal:/export/spare) to
/export/spare/mltdump.0714
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 1382688 blocks (675.14MB).
DUMP: Dumping (Pass III) [directories]
DUMP: 1382654 blocks (675.12MB) on 1 volume at 5172 KB/sec
DUMP: DUMP IS DONE

3-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
SUN System Backup

ufsdump 0f /export/spare/basedump.0714 /export/spare/loopcare/

base

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Mon Jul 14 16:12:14 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (hannibal:/export/spare) to
/export/spare/basedump.0714
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 113278 blocks (55.31MB)
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 112894 blocks (55.12MB) on 1 volume at 4415 KB/sec
DUMP: DUMP IS DONE
ufsdump 0f /export/spare/db1dump.0714 /export/spare/loopcare/db1
DUMP: Writing 32 Kilobyte records
DUMP: Date of this level 0 dump: Tue Jul 15 09:07:25 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (hannibal:/export/spare) to
/export/spare/db1dump.0714
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 485606 blocks (237.11MB)
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 485566 blocks (237.09MB) on 1 volume at 6308 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/db2dump.0714 /export/spare/loopcare/db2

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Tue Jul 15 09:09:06 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (hannibal:/export/spare) to
/export/spare/db2dump.0714
DUMP: Mapping (Pass I) [regular files]

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-9

System Administration Guide System Operation
SUN System Backup

DUMP: Mapping (Pass II) [directories]

DUMP: Estimated 526646 blocks (257.15MB)
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 526590 blocks (257.12MB) on 1 volume at 6665 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/db3dump.0714 /export/spare/loopcare/db3

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Tue Jul 15 09:10:50 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (hannibal:/export/spare) to
/export/spare/db3dump.0714
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 844714 blocks (412.46MB)
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 844670 blocks (412.44MB) on 1 volume at 6411 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/db4dump.0714 /export/spare/loopcare/db4

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Tue Jul 15 09:53:01 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (hannibal:/export/spare) to
/export/spare/db4dump.0714
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 2006 blocks (1003KB)
DUMP: Dumping (Pass III) [directories]

3-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
SUN System Backup

DUMP: Dumping (Pass IV) [regular files]

DUMP: 1982 blocks (991KB) on 1 volume at 3303 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/oracledump.0714 /export/spare/loopcare/oracle

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Tue Jul 15 09:54:42 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s7 (hannibal:/export/spare) to
/export/spare/oracledump.0714
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 3358240 blocks (1639.77MB)
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 3351358 blocks (1636.41MB) on 1 volume at 5128 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/apachedump.0714 /opt/apache2

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Tue Jul 15 11:20:11 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s6 (hannibal:/opt) to /export/
spare/apachedump.0714.DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 47200 blocks (23.05MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 47166 blocks (23.03MB) on 1 volume at 4855 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/tomcatdump.0714 /opt/tomcat

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-11

System Administration Guide System Operation
SUN System Backup

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Tue Jul 15 11:22:58 2003
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s6 (hannibal:/opt) to /export/
spare/tomcatdump.0714
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 10102 blocks (4.93MB)
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 10046 blocks (4.91MB) on 1 volume at 3131 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/snmpdump /opt/snmp

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Thu Dec 30 13:16:57 2004
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s0 (hannibal:/) to /export/spare/snmp
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 23368 blocks (11.41MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 23358 blocks (11.41MB) on 1 volume at 4214 KB/sec
DUMP: DUMP IS DONE

ufsdump 0f /export/spare/inprise /opt/inprise

DUMP: Writing 32 Kilobyte records

DUMP: Date of this level 0 dump: Thu Dec 30 13:17:33 2004
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s0 (hannibal:/) to /export/spare/inprise
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]

3-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
SUN System Backup

DUMP: Estimated 30060 blocks (14.68MB).

DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 30014 blocks (14.66MB) on 1 volume at 5667 KB/sec
DUMP: DUMP IS DONE

Directory Restore Restoration of directories should be done only as a last resort after a disaster
such as disk corruption.

Directory Restore The basic command for restoring a directory structure is:
Command ufsrestore xf /saved_file_location/saved_filename

Examples of The following are examples of each directory restore. The specifics of these
Directory Restores commands depend on where you saved your backups.
ufsrestore xf /export/spare/mltdump.0714

Warning: ./loopcare: File exists

Warning: ./loopcare/mlt: File exists
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should
start with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/basedump.0714

Warning: ./loopcare: File exists

Warning: ./loopcare/base: File exists
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should
start

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-13

System Administration Guide System Operation
SUN System Backup

with the last volume and work towards the first.

Specify next volume #: 1
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/db1dump.0714

Warning: ./loopcare: File exists

Warning: ./loopcare/db1: File exists
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should
start
with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/db2dump.0714

Warning: ./loopcare: File exists

Warning: ./loopcare/db2: File exists
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should
start with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/db3dump.0714

Warning: ./loopcare: File exists

Warning: ./loopcare/db3: File exists
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should
start with the last volume and work towards the first.

3-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
SUN System Backup

Specify next volume #: 1

set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/db4dump.0714

Warning: ./loopcare: File exists

Warning: ./loopcare/db4: File exists
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/basedump.0714
Warning: ./loopcare: File exists
Warning: ./loopcare/base: File exists

You have not read any volumes yet.

Unless you know which volume your file(s) are on you should
startwith the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/oracledump.0714

Warning: ./loopcare: File exists

Warning: ./loopcare/oracle: File exists
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should
start with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

ufsrestore xf /export/spare/apachedump.0714
You have not read any volumes yet.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-15

System Administration Guide System Operation
SUN System Backup

Unless you know which volume your file(s) are on you should
start with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y

ufsrestore xf /export/spare/tomcatdump.0714

Warning: ./local: File exists

You have not read any volumes yet.
Unless you know which volume your file(s) are on you should
start with the last volume and work towards the first
Specify next volume #: 1
set owner/mode for '.'? [yn] y
Directories already exist, set modes anyway? [yn] y

Start All LoopCare /etc/init.d/syslog start

Applications /etc/init.d/oracle start
/etc/init.d/apache start
/etc/init.d/loopcare start

3-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Backup and Recovery

Database Backup and Recovery

Overview The following procedures allow the administrator to backup and recover the
LoopCare Oracle database in the event of a possible media or power failure.

NOTE:
The backup and recovery procedures in this chapter may require the
assistance of an experienced Oracle database administrator.

Backup Database backup procedures ensure the integrity of LoopCare data and provides
minimal data loss exposure of the databases. Backups can be categorized into
physical and logical backups.

In a physical backup, the actual data files are copied from one location to another
(usually from disk to tape). A logical backup uses export and import functions to
capture and restore a database in its logical form (it does not save uncommitted
transactions). LoopCare uses a physical backup method. Refer to Chapter 6,
Oracle Database Architecture, for detailed information on the Oracle RDBMS and
a glossary of terms.

The LoopCare installation of the Oracle RDBMS places an automated backup

mechanism into a directory tree along with the necessary files and executables.
This provides the LoopCare system with two backup methods:
• Cold Backup - Database is off-line and unavailable. This involves shutting
down the Oracle database, backing up all required Oracle database files,
then starting up Oracle in Normal mode.
• Hot Backup - Database remains on-line and available. The Oracle
database is open and operating in ARCHIVELOG mode.

Before running any database backup procedures for the first time after installing a
new software generic, certain shell programs must be installed. This is done only
once per release. After that, the Cold Backup and Hot Backup procedures can be
used as needed.

Backup Procedure 1. Verify that the following line is found in the /mlt/config/oraclevars file. If the
Installation line does not exist, add it.
TOOLS=$ORACLE_HOME/tools; export TOOLS
2. For existing customers, remove the prevailing backup directory structure
before installing the new one.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-17

System Administration Guide System Operation
Database Backup and Recovery

Login as oracle
. /mlt/config/oraclevars
cd $ORACLE_HOME
rm -r tools
rm -r $ORACLE_SID
3. As oracle user, create all required sub-directories and install the backup/
recovery utilities.
/mlt/install/installbackup
4. Verify that the shell ${ORACLE_HOME}/${ORACLE_SID}/tools/
${ORACLE_SID}_backup_admin.sh has the BACKUPDIR, ARC and
EXPORTDIR environment variables defined for your environment. Ensure
that the directories specified for the environmental variables exist with
appropriate permissions, owner and group.
The directories $BACKUPDIR/datafiles, $BACKUPDIR/control and
$BACKUPDIR/parameters must also exist with appropriate permissions,
owner and group.
For example, in ${ORACLE_SID}_backup_admin.sh the environmental
variables are set as follows:
BACKUPDIR=/db4; export BACKUPDIR
EXPORTDIR=/db4; export EXPORTDIR
ARC=/db4/archive_mlt50; export ARC

NOTE:
Increase the amount of space currently allocated for the redo log directory,
for example, /db4, to 1500M to accommodate the BMDB database and
usage.

The permissions, owner and group are:

ls -ld /db4
drwxrwxr-x 9 oracle dba 1024 Feb 3 17:40 /db4
ls -ld /db4/parameters /db4/datafiles /db4/control
drwxrwxr-x 2 oracle dba 96 Dec 4 16:45 /db4/parameters
drwxrwxr-x 2 oracle dba 1024 Dec 4 16:45 /db4/datafiles
drwxrwxr-x 2 oracle dba 96 Dec 4 16:45 /db4/control
Remember, this procedure is done only once, not each time a backup is
done.

Cold Backup Cold backup is a conventional file system backup which copies files to a database
backup location where they can then be copied to tape. This is the preferred

3-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Backup and Recovery

method for backup. Note that the database is unavailable for the time it takes to
copy the files.

A typical cold backup might include a seven day rotation beginning with a cold
backup on the first day followed by six days of archive redo log backups.

Perform the following to schedule a cold backup:

1. Perform LoopCare Shutdown.
2. As oracle user, setup the environment.
. /mlt/config/oraclevars

NOTE:
The space between the "." and the "/" is required.

3. Verify $ORACLE_SID, $ORACLE_HOME and $TOOLS environment

variables are set properly.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $TOOLS
In the dbbackup_sched.dat file, in the $TOOLS/db_mgmt/backup directory,
enter the day of the week that the cold backup will run.
This file calls appropriate shells to execute the tasks defined by user input.
The format of the file is shown below:
<ORACLE_SID> <day-of-the-week> <hot|cold|nobackup>
<export|noexport>
<special script>
where the parameters are defined as follows:

ORACLE_SID name of the database

day-of-the-week weekday of the scheduled backup
hot|cold|nobackup physical backup type
export|noexport logical backup procedure
special script optional shell script to perform

additional administrative tasks such as deleting certain files.

Sample modified dbbackup_sched.dat file:
mlt51 Sun cold export
4. In the crontab.dat file, in the $TOOLS/system directory, set the following
backup parameters:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-19

System Administration Guide System Operation
Database Backup and Recovery

backup driver dbbackup

frequency with which dbredo_backup is to be run
backup to tape
The following sample crontab.dat file entries run the backup on Sunday
nights at 3am, copy the redo every half-hour, and backup to tape every
hour.
0 3 * * 0 ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
dbbackup
$ORACLE_SID manager <passwd> >> /dev/null
0,30 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
dbredo_backup
$DB4 $BACKUPDIR >> /dev/null

0 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
dbtapebackup
<tape device> >> /dev/null

NOTE:
<tape device> should be replaced with either tape0 or tape1 depending
upon your configuration. Tape0 represents /dev/rmt/0m and tape1
represents /dev/rmt/1m. The <passwd> should be the system passwd.

The dbbackup script should be run with two parameters; database instance name
and the system DBA password. These two are required parameters. It is okay to
specify the DBA password in the crontab.dat file because it is protected against
read and write. Also note that "manager" is the default password for System DBA.
If this password is changed then the this file should also be updated. If not the
nightly job would fail.

Hot Backup Hot backup places information from each tablespace into backup mode and
immediately copies the data files to tape or auxiliary disk. The database must be
in Archive mode this mode is enabled for LoopCare. Although the database is
available during hot backup, the system operation may be slow during backup
activity.

A typical hot backup might consist of a seven day rotation beginning with a hot
backup on the first day, followed by six days of archive redo log backups.
1. Perform the following to schedule a hot backup:
As oracle user, setup the environment.

3-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Backup and Recovery

. /mlt/config/oraclevars
Note: The space between the "." and the '"/" is required.
2. Verify $ORACLE_SID, $ORACLE_HOME and $TOOLS environment
variables are set properly.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $TOOLS
3. In the dbbackup_sched.dat file, enter the day of the week that the hot
backup will run.
This file calls appropriate shells to execute the tasks defined by user input.
The format of the file is shown below:
<ORACLE_SID> <day-of-the-week> <hot|cold|nobackup>
<export|noexport>
<special script>
where the parameters are defined as follows:

ORACLE_SID name of the database

day-of-the-week weekday of the scheduled backup
hot|cold|nobackup physical backup type
export|noexport logical backup procedure
special script optional shell script to perform

additional administrative tasks such as

deleting certain files.
Sample modified dbbackup_sched.dat file:
mlt51 Sun hot export
4. Using the crontab -e command, set the following backup parameters in the
crontab file, in the $TOOLS/system directory:

NOTE:
The variables shown in the sample entries below should be replaced with
their actual values when editing the crontab file.

backup driver dbbackup

frequency with which dbredo_backup is to be run
backup to tape
The following sample crontab.dat file entries run the backup on Sunday
nights at 3am, copy the redo every half-hour, and backup to tape every
hour.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-21

System Administration Guide System Operation
Database Backup and Recovery

0 3 * * 0 ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
dbbackup $ORACLE_SID manager >> /dev/null

0,30 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/

dbredo_backup $DB4 $BACKUPDIR >> /dev/null

0 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
dbtapebackup <tape device> >> /dev/null

NOTE:
<tape device> should be replaced with either tape0 or tape1 depending
upon your configuration. Tape0 represents /dev/rmt/0m and tape1
represents /dev/rmt/1m. The <passwd> should be the system password.

The dbbackup script should be run with two parameters; database instance name
and the system DBA password. These two are required parameters. It is okay to
specify the DBA password in the crontab.dat file because it is protected against
read and write. Also note that "manager" is the default password for System DBA.
If this password is changed then the this file should also be updated. If not the
nightly job would fail.

3-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Recovery

Database Recovery

Overview The preceding pages outline procedures to provide the means to address a media
failure. Oracle, as installed, provides automatic recovery from corruption’s to the
processes in memory or from a power failure. If recovery becomes necessary due
to media failure, the target machine could be out of service for a good portion of
the day. A new drive must be installed, the effected file systems recreated, and
data files restored to the original locations. After that, recovery choices are
influenced by what backup method was used.

If a cold backup was performed, and if the system was not running in ARCHIVE
mode, you can only restart the database and accept the loss of data from the
backup time to the point of failure.

There are three kinds of recovery available:

Recovery Method Procedure

Database Recovery Restore from the backup media, mount the database in
restricted mode (i.e. prohibit user logins while recovery
is active), issue the recover database command using
SQLDBA or SVRMGR. Oracle will automatically post all
of the stored transactions in the redo log files.
Tablespace Recovery Restore the Tablespace data files from the backup
media, open the database but take the tablespace off-
line (i.e. user objects such as tables can not be
accessed), issue the recover tablespace command
using SQLDBA or SVRMGR. Please note that the
SYSTEM tablespace which contains the data dictionary,
is NOT recoverable since it can not be taken off-line.
Data File Recovery Restore the data file(s) from the backup media, mount
the database in restricted mode, issue the recover
datafile command using SQLDBA or SVRMGR.

NOTE:
Unless performed by a trained DBA, Tablespace and Data File Recovery
are not viable for LoopCare. A decision to use either implies that the
problem has been localized and that it is acceptable to have a portion of the
database available.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-23

System Administration Guide System Operation
Database Recovery

Database Recovery This section contains instructions for recovering the database after any of the
Procedures following failures have occurred:
• Disk Crash
• Multiple Disk Crashes

Disk Crash

If there is a database disk crash, the database must be restored from tape.

The following procedure provides a complete recovery of the failed database to

the point of failure; the Replication process should then bring the database up to
the current time (all updates made at other sites while the failed database was
down and being restored, will be propagated to the failed database).

Perform the following to recover from a disk crash:

1. Stop the database Listener process (to stop SQL*Net to the failed
database).
. /mlt/config/oraclevars
$ORACLE_HOME/bin/lsnrctl stop
2. Restore from tape to $BACKUPDIR
3. Copy the data, log, and control files to their original locations:
cp $BACKUPDIR/ctrl1mlt.ctl ${DB1}
cp $BACKUPDIR/${ORACLE_SID}_log1.dbf ${DB1}
cp $BACKUPDIR/${ORACLE_SID}_mlttbl.dbf ${DB1}
cp $BACKUPDIR/ctrl2mlt.ctl ${DB2}
cp $BACKUPDIR/${ORACLE_SID}_log2.dbf ${DB2}
cp $BACKUPDIR/${ORACLE_SID}_mltinx.dbf ${DB2}
cp $BACKUPDIR/ctrl3mlt.ctl ${DB3}
cp $BACKUPDIR/${ORACLE_SID}_log3.dbf ${DB3}
cp $BACKUPDIR/${ORACLE_SID}_rbs.dbf ${DB3}
cp $BACKUPDIR/${ORACLE_SID}_system.dbf ${DB3}
cp $BACKUPDIR/${ORACLE_SID}_temp.dbf ${DB3}
4. To recover the database, enter the following (when ORACLE prompts for
the location of the redo logs, enter $BACKUPDIR):
. /mlt/config/oraclevars
SQLDBA lmode=y<<!
connect internal
startup mount
recover database until cancel;

3-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Recovery

Alter database open Resetlogs;

Shutdown
Startup
!

Multiple Disk Crashes

If a database disk crashes, causing the loss of archived redo logs, a complete
recovery will not be possible. The failed database must be removed from the
replication environment, recreated, then added back into the environment. This
will propagate all data from the replicated environment to the newly added
database.

The following two procedures in this section must be performed to recover from
multiple disk crashes:
• Remove Master Site from the Existing Replicated Environment.
• Add a Master Site to the Existing Replicated Environment

Remove Master Site from the Existing Replicated Environment

1. Generate scripts for replication configuration
This procedure creates the SQL scripts used to drop database links and
the master site(s) from the replication environment. It is not necessary to
reconfigure SQL*Net when you remove master site(s) from your replicated
environment.
Later, If you decide to re-add the same master site(s) to your replicated
environment, you can skip the SQL*Net configuration steps when re-
adding a master site.
a. Login to the master definition site server as user mlt and dot
execute the oraclevars file.
su - mlt
. /mlt/config/oraclevars
b. Run cfgrep to create the SQL replication scripts.
/mlt/install/cfgrep -p <passwd> -s <sys-passwd> -r
<remotesys-passwd>
where <passwd> is the repadmin user account password.
<sys-passwd> is the SYS DBA password
<remotesys-passwd> is the remotesys user account password.

The following prompts appear during the execution of cfgrep.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-25

System Administration Guide System Operation
Database Recovery

NOTE:
In the example below, the user wants to remove mlt53 on saturn as a
master site from the existing replicated environment. Note that 111 is the
process id of cfgrep in the example.

Validating password for repadmin...

validating password for remotesys...
validating SYS DBA password...
Please note that this program assumes that the passwords are the same in
all the sites that are involved in replication.
CURRENT REPLICATED ENVIRONMENT:
master definition site: mlt50
master site(s): LoopCare51 mlt52 mlt53
ENTER ‘q’ to QUIT OR TO SPECIFY NO MORE ENTRIES
Do you want to add or remove a master site? (‘a’ or
‘r’): r
Enter oracle SID for master site to remove: mlt53
Enter oracle SID for master site to remove: q
Generated scripts:
/mlt/install/dblog/drlinks111
/mlt/install/dblog/drrep111
2. Re-configure Replicated Environment
This is a continuation of the previous example of removing mlt53 on saturn
as a master site.
a. Run drrep111 to re-configure the replicated environment by
removing the master site(s) specified in the previous procedure.
This script should only be run once (it can be run on any site) as it
will use SQL*Net to get the appropriate database(s). This script is
created with the default passwords.
b. Edit the script as appropriate if you changed the passwords on the
created databases. The drrep111 script could take a very long time
to run.
c. Check the log file, /mlt/install/dblog/drrep111.log, for errors and
correct as appropriate.
/mlt/install/dblog/drrep111
Run drlinks111 to drop the database links between all the
database(s) in the entire replicated environment to the master
site(s) to be removed.

3-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Recovery

This script should only be run once on any site as it will use
SQL*Net to get the appropriate database(s). This script is created
with the default passwords.
d. Edit the script as appropriate if you changed the passwords on the
created databases.
e. Check the log file, /mlt/install/dblog/drlinks111.log, for errors and
correct as appropriate.
/mlt/install/dblog/drlinks111
3. Recreate the Database
a. Recreate the database (this assumes that new disks/files systems
have been created to replace those that failed, and the contents of /
DB1, /DB2, /DB3, and /DB4, have been purged)
. /mlt/config/oraclevars
/mlt/install/crdb
/mlt/install/crschema -p <mltdba-passwd> -b <bmdb-
passwd> -B <batch-passwd> -s <system-passwd>
where:
<mltdba-passwd> is the initial password for MLTDBA user account
<bmdb-passwd> is the initial password for bmdb user account
<batch-passwd> is the initial password for batch user account
<system-passwd> is the password for SYSTEM DBA user.

Add a Master Site to an Existing Replicated Environment

1. Setup New Database(s) for Replication
a. Login to the new master site server as user mlt and dot execute the
oraclevars file.
su - mlt
. /mlt/config/oraclevars
b. Check the log file, /mlt/install/dblog/setuprep_SID.log, for errors and
correct as appropriate.
c. Run setuprep to create the replication accounts and replication
packages and procedures needed to support LoopCare replication.
This script should be run on ALL NEW sites to be added to the
existing replicated environment.
/mlt/install/setuprep -S <system-passwd> -s <sys-
passwd> -R <repadmin-passwd> -r <remotesys-passwd>
where:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-27

System Administration Guide System Operation
Database Recovery

<system-passwd> is the password for SYSTEM DBA user.

<sys-passwd> is the password for SYS DBA user.
<repadmin-passwd> is the password for REPADMIN user.
<remotesys-passwd> is the password for REMOTESYS user.
In this example, the user wants to add mlt52 on yorktown and mlt53
on saturn as new master sites to an existing replicated environment
of mlt50 on jupiter as the master definition site and mlt51 on
saratoga as the master site
rlogin yorktown -l mlt
. /mlt/config/oraclevars
/mlt/install/setuprep -S <system-passwd> -s <sys-
passwd> -R <repadmin-passwd> -r <remotesys-passwd>

exit
rlogin saturn -l mlt
. /mlt/config/oraclevars
/mlt/install/setuprep -S <system-passwd> -s <sys-
passwd> -R <repadmin-passwd> -r <remotesys-passwd>
exit
2. Generate Files and Scripts for SQL*Net and Replication Configuration
This procedure is run to create the SQL*Net configuration files and the
SQL scripts used to create database links and the replication environment.
a. Login to the existing master definition site server and dot execute
the oraclevars file.
rlogin jupiter -l mlt
. /mlt/config/oraclevars
b. Run cfgrep to create the SQL*Net configuration files and to the
replication scripts. This script should only be run on the master
definition site machine.
/mlt/install/cfgrep -p <passwd> -s <sys-passwd> -r
<remotesys-passwd>
where <passwd> is the repadmin user account password.
<sys-passwd> is the SYS DBA password
<remotesys-passwd> is the remotesys user account password.
The following prompts appear during the execution of cfgrep.

(Continued on next page)

3-28 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Recovery

NOTE:
In the example below, the user wants to remove mlt53 on saturn as a
master site from the existing replicated environment. Note that 111 is the
process id of cfgrep in the example.

Validating password for repadmin...

validating password for remotesys...
validating SYS DBA password...
Please note that this program assumes that the passwords are the
same in all the sites that are involved in replication.
CURRENT REPLICATED ENVIRONMENT:
master definition site:mlt50
master site(s):mlt51
ENTER ’q’ to QUIT OR TO SPECIFY NO MORE ENTRIES
Do you want to add or remove a master site? (’a’ or
’r’): a
Enter oracle SID for new master site: mlt52
Enter host machine name for new master site:
yorktown
Enter host port number for new master site [1521]:
1521
Enter oracle SID for new master site: mlt53
Enter host machine name for new master site:
saturn
Enter host port number for new master site [1521]:
1521
Enter oracle SID for new master site: q
Generated scripts:
/mlt/install/dblog/tnsnames111.ora
/mlt/install/dblog/listener111.ora.<host>
/mlt/install/dblog/crlinks111
/mlt/install/dblog/crrep111
3. Configure SQL*Net for replicated environment
This procedure is run to setup SQL*Net. SQL*Net allows the user to
connect to any database from any site as if the database were on the same
machine. It also allows the databases to communicate to each other. The
following steps are a continuation of the previous example.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-29

System Administration Guide System Operation
Database Recovery

a. Append the tnsnames111.ora file to the existing tnsnames.ora file

from the existing master definition site and distribute it to ALL the
sites in the newly formed replicated environment, that is, the existing
master definition site, the existing master site(s), and the new
master site(s).
rlogin jupiter -l oracle
. /mlt/config/oraclevars
cat /mlt/install/dblog/tnsnames111.ora >>
/oracle/app./oracle/product/8.1.7/network/admin/
tnsnames.ora
rcp /oracle/app./oracle/product/8.1.7/network/
admin/tnsnames.ora \
saratoga:/oracle/app./oracle/product/8.1.7/
network/admin/tnsnames.ora
rcp /oracle/app./oracle/product/8.1.7/network/
admin/tnsnames.ora \
yorktown:/oracle/app./oracle/product/8.1.7/
network/admin/tnsnames.ora
rcp /oracle/app./oracle/product/8.1.7/network/
admin/tnsnames.ora \
saturn:/oracle/app./oracle/product/8.1.7/network/
admin/tnsnames.ora
b. Copy the listener111.ora to all the NEW master sites and startup the
listener process.
rcp /mlt/install/dblog/listener111.ora.yorktown \
yorktown:/oracle/app./oracle/product/8.1.7/
network/admin/listener.ora
rlogin yorktown -l oracle
lsnrctl start
exit
rcp /mlt/install/dblog/listener111.ora.saturn \
saturn:/oracle/app./oracle/product/8.1.7/network/
admin/listener.ora
rlogin saturn -l oracle
lsnrctl start
exit
c. Add the listener startup command to the /etc/rc file for the automatic
startup of the SQL*Net listener process on the new master site.
rlogin yorktown -l root

3-30 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
Database Recovery

print "/bin/su - oracle - c /oracle/app./oracle/

product/8.1.7/bin/lsnrctl start" >> /etc/rc
exit
d. Add the listener startup command to the /etc/rc file for the automatic
startup of the SQL*Net listener process on all new master sites.
rlogin saturn -l root
print "/bin/su - oracle - c /oracle/app./oracle/
product/8.1.7/bin/lsnrctl
start" >> /etc/rc
exit
e. Verify that the database(s) and SQL*Net listener processes are
running by trying to connect to all database(s) from each machine.
Do not proceed until there are no errors.
rlogin jupiter -l oracle
/mlt/install/oraclevars
sqlplus repadmin/<repadmin-password>@mlt50
SQL> connect repadmin/<repadmin-password>@mlt51
SQL> connect repadmin/<repadmin-password>@mlt52
SQL> connect repadmin/<repadmin-password>@mlt53
SQL> exit
exit
rlogin saratoga -l oracle
. /mlt/install/oraclevars
sqlplus repadmin/<repadmin-password>@mlt50
SQL> connect repadmin/<repadmin-password>@mlt51
SQL> connect repadmin/<repadmin-password>@mlt52
SQL> connect repadmin/<repadmin-password>@mlt53
SQL> exit
exit
rlogin yorktown -l oracle
. /mlt/install/oraclevars
sqlplus repadmin/<repadmin-password>@mlt50
SQL> connect repadmin/<repadmin-password>@mlt51
SQL> connect repadmin/<repadmin-password>@mlt52
SQL> connect repadmin/<repadmin-password>@mlt53
SQL> exit
exit
rlogin saturn -l oracle

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-31

System Administration Guide System Operation
Database Recovery

. /mlt/install/oraclevars
sqlplus repadmin/<repadmin-password>@mlt50
SQL> connect repadmin/<repadmin-password>@mlt51
SQL> connect repadmin/<repadmin-password>@mlt52
SQL> connect repadmin/<repadmin-password>@mlt53
SQL> exit
exit
4. Re-configure replicated environment
This is a continuation of the previous example where the user is adding
mlt52 on yorktown and mlt53 on saturn as new master sites.
a. Run crlinks111 to create database links between the database(s) in
the new replicated environment.
This script should only be once (it can be run on any site) as it will
use SQL*Net to get the appropriate database(s). This script is
created with the default passwords.
b. Edit it as appropriate if you changed the passwords on the created
databases. Check the log file, /mlt/install/dblog/crlinks111.log, for
errors and correct as appropriate.
/mlt/install/dblog/crlinks111
c. Run crrep111 to setup up replication between all the database(s) in
the new replicated environment.
This script should only be once on any site as it will use SQL*Net to
get the appropriate database(s). This script is created with the
default passwords.
d. Edit the script as appropriate if you changed the passwords on the
created databases. Note that the crrep111 script can take a very
long time to run.
e. Check the log file, /mlt/install/dblog/crrep111.log, for errors and
correct as appropriate.
/mlt/install/dblog/crrep111

3-32 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
LoopCare Failover

LoopCare Failover

Overview The LoopCare system employs several methods to route transactions from a
failed primary to a backup Front End machine.
• ANS Failover - both primary Front Ends and secondary machines are
designated in the dbmap table and when the primary fails, transactions are
automatically routed to the designated backup Front End machine. This
includes both TV and test transactions.
• Manual Switchover - the UIP System Administration option Backup is
selected and transactions are routed from the failed primary to the
designated backup Front End machine. This is necessary to route SAM
transactions to the backup.
• DCN Links Failover - provides automatic failover capability based on
machine IPB addresses that are specified in the P_PHID and B_PHID
environmental variables. If the DCN loses communications with the primary
machine to which it is connected, automatic switchover to the designated
backup machine will occur.

Set Up for Failover With LoopCare, (the ANS Phase 2A environment), DKAPs can route transactions
to either a primary or secondary Front End machine. When both primary Front
Ends and secondary machines are designated in the dbmap table, "transaction
routing failover" can be applied. Automatic "transaction routing failover" occurs
when the primary LoopCare Front End goes down or becomes unavailable and
the request is automatically re-routed to the secondary LoopCare Front End.

NOTE:
For automatic failover to occur, the application must have been up
previously. That is, transactions will not failover to the backup LoopCare
Front End if LoopCare has not been started since BASE was started.

Setting up the ANS In the ANS Phase 2 environment, ANS administrators must populate the ANS
Data Base Map Data Base Map table with data that specifies the relationships among LMOS data
Table for Failover bases, external data base IDs, LMOS Logical Machines, and LoopCare Front End
LMIDs.

To set up Failover for LoopCare, both a primary and backup LoopCare Logical
Machine Identifiers (LMID) must be specified in the dbmap table. This information
is entered in the LoopCare LMIDs field. This field contains two columns. The entry
in the left column specifies the Logical Machine ID assigned to a stand-alone

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-33

System Administration Guide System Operation
LoopCare Failover

LoopCare Front End or to the hybrid LMOS/LoopCare Front End machine that will
serve as the "primary" LoopCare testing machine for users assigned to the
designated Front End data base. The entry in the right column specifies the
Logical Machine ID assigned to a stand-alone LoopCare Front End or to the
hybrid LMOS/LoopCare Front End machine that will serve as the "backup"
LoopCare testing machine for users assigned to the designated Front End data
base.

The backup LoopCare machine will have LoopCare transactions routed to it

automatically during a "transaction routing failover" (i.e., when a primary Front
End machine goes down or becomes unavailable). Automatic "transaction routing
failover" occurs when the CRTmgr (on CRT DKAPs) receives a 'send failure'
message from the primary LoopCare Front End.

For details about entering the appropriate data in the LoopCare LMIDs field, refer
to the ANS document, 490.config_dbmap.

For details about setting up LoopCare line printers as a replacement for ANS, see
Appendix E of the LoopCare System Administration Guide.

Setting Up for The LoopCare database identifies the System Administration and Maintenance
Failover (SAM) regions, the LoopCare machines and printers used for SAM transactions
and a file of system constants to be applied for the region in place of the default
values.

The concept of a region is used to divide the maintenance and administration of

the LoopCare system into segments based on geographical area, work load,
similarity of task or other criteria peculiar to a particular installation. At least one
(1) region must be specified. Further divisions are optional. Each region must
have one LoopCare machine (LoopCare Front End designated to handle all SAM
requests for the region and a printer attached to that machine to receive all
spontaneous output (error messages, etc.) directed to the System Administrator
by the LoopCare system. A second LoopCare machine and printer may be
assigned to the region as a backup when the primary machine is down.

The primary machine is specified via the Region DEF entries (see the ADEF
Administrator’s Guide). Information entered includes the logical machine ID for
the LoopCare processor assigned to perform administration for this region. Each
region must have one, and only one, primary processor to handle SAM
transactions. Other information includes the primary printer name. A backup Front
End must be designated to use the failover option. A backup printer can also be
designated but is not required.

3-34 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
LoopCare Failover

Rules for Assigning • A Front End may be assigned both as a primary LoopCare machine for one
Machines for region and a secondary for another.
Regions • A LoopCare machine may not be assigned as secondary for two regions
with different primaries.
• The secondary machine cannot be assigned, (via the UIP option Backup
under System Administration), to administer the region as long as the
primary machine is running.
• Once a primary LoopCare machine assumes control for a region, it
maintains control unless its MGRP fails. When this occurs, utilizing the
System Administration Backup option allows the primary LoopCare Front
End administrative responsibilities to be assumed by a backup LoopCare
Front End.

When the primary machine comes up again it will automatically re-assume

control.

Editing the MLT.gdf The group description file for the MLT group (MLT.gdf) must be edited to utilize the
File for Failover watch group feature for failover. This will force LoopCare failover in the event that
a "core" MLT group goes down after being active. Details about how to set up this
feature in the MLT.gdf file follow.

ModulePort(s)

F:$MLT_BIN/wgrp wgrp

The purpose for the wgrp module is to watch a "core" MLT group and to determine
if it is running. You must edit MLT.gdf file to remove the # from the beginning of the
wgrp line to activate this feature. The default group that wgrp watches is MGRP.
Wgrp serves two functions.
1. wgrp is the trigger for LoopCare failover in the ANS interface if the core
group is seen as active and then not active. wgrp will send messages to
the console after every interval that the core group is inactive. At the end
of a fixed amount of time, wgrp will fatal itself thereby stopping the base
MLT group which in turn halts the xlate process. When the xlate process
is halted, ANS is informed that LoopCare is not active. ANS in turn
switches to its backup LoopCare processor.
2. wgrp is a warning mechanism if the core MLT group is never brought up.
When the optional -w argument is used, wgrp begins to issue warning
messages to the console that the core MLT group is not up after a fixed
amount of time.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-35

System Administration Guide System Operation
LoopCare Failover

Option Description
-g Set the core MLT group. The default value is MGRP.
-h Set the time to halt wgrp. The default time is 10
minutes.
The minimum time setting is 5 minutes.
-I Set the interval period in seconds between wgrp's
query. The default interval is 30 seconds and the
minimum interval allowed is 15 seconds.
a. query of the core group's activation
b. message to the console if the core group is not
up with -w option.
-w Set the wait time in minutes to see the Core Group
group, is active before issuing warning messages. The
default is 10 minutes and the minimum time setting
permitted is 5 minutes. The MGRP will usually take up
to 5 minutes to start.

Setting Up For The ADEF CMU Test Head DEF is used to identify the primary and backup Front
CMU Failover End machines associated with CMU testing. CMUs are not directly linked to the
Front End but instead are access through dial out modems. The code that
controls the testing performed by the CMU resides on the Front End.

This defines the association between a CMU group and the Front End that has the
code which controls its testing. When a test request is made on a CMU, LoopCare
goes to the database, notes which CMU group it belongs to, and identifies the
primary Front End that controls its testing. The test request is then routed to that
Front End for processing.

If the primary Front End is not available, the request will be sent to the backup
Front End which will direct testing. Results will then be sent to the requesting user.

LoopCare provides four types of failover that allow operation to switch from the
primary to the backup machine:

Setting Up DCN DCN Links failover provides automatic failover capability based on machine IPB
Links Failover addresses. If the DCN loses communications with the primary machine to which it
is connected, switchover to the designated backup machine will occur.

The administrator must set the following environmental variables using the UIP
System Administration option Set Environment:

3-36 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

System Operation System Administration Guide
LoopCare Failover

P_PHID - the primary PHID for this logical machine

B_PHID - the switchover PHID for this logical machine

Revision Q (p/n 040-0362) Release 2.15, December, 2006 3-37

System Administration Guide System Operation
LoopCare Failover

3-38 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring 4

Contents

• Introduction 4-2
• Measuring DCN/LCN/LTCN Message Traffic 4-3
• Statistics Logging & Collection 4-4
• What TREAT Can Tell You 4-15
• Testing Activity Feature (TAF) 4-16
• LTE.ERR 4-39
• OPENSLOG.STAT 4-40
• LoopCare Activity Report Generator (LARGE) 4-41
• Testing Activity Report Enabler (TARE) 4-54
• Activation of the TARE Oracle Database Feature 4-59
• Customized Report Service 4-64
• VER 99 Improvement Feature 4-65
• The OE.STAT Report 4-68
• CPU Utilization and Related Statistics 4-70

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-1

System Administration Guide Performance Monitoring
Introduction

Introduction

Overview This chapter provides information and procedures on using LoopCare utilities to
measure system performance. It describes how to generate activity logs and
usage statistics about transactions between the LoopCare Front End, the testing
equipment, and communications link.

4-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Measuring DCN/LCN/LTCN Message Traffic

Measuring DCN/LCN/LTCN Message

Traffic

Overview This section describes the contents of the file $MLT_TMP/commmsgcnt.out,

which is produced by the LoopCare process kmsmsgcnt. This process provides
information on message traffic into DCN's, and is initiated when the MDMN group
is started. Data is generated on an interval basis, with the default interval being 60
minutes.

NOTE:
A message is defined as a transmission by any LoopCare module being
written to the DCN. One test request consists of a number of messages.

To get smaller or larger snapshots, the default interval can be changed by adding
a -t,n option to the commmsgcnt command line in /base/config/MDMN.gdf, where
n is the time interval in minutes, with a minimum of 5.

A typical example of a report on DCN message traffic is shown below:

00:27 01/31 - commmsgcnt started, iterations are 60
minutes counts are messages written into DCNs
10:33 06/04, iteration: 1, total minutes: 2

total_msgs total/min ter_msgs ter/min state of port

dcn1 30 15.0 0 0.0
dev0 30 15.0 0 0.0
port2 30 15.0 0 0.0 dcn1 OPEN
dcn4 29 14.5 0 0.0
BONNIE83C 26 13.0 0 0.0 OPEN
DEVDKAPC1 0 0.0 0 0.0 CLOSED
MLTDKAPCONT1 3 1.5 0 0.0 OPEN
dcn8 23 11.5 0 0.0
BONNIE81C 23 11.5 0 0.0 OPEN

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-3

System Administration Guide Performance Monitoring
Statistics Logging & Collection

Statistics Logging & Collection

Transaction This program provides Data Center personnel with a means to process High
Statistics Capacity Front End (LoopCare Front End) log data to generate reports on
LoopCare transaction traffic. The information recorded in the disk logging area
comes from the LoopCare system running on that particular Front End.
Transactions executed on other Front Ends are not logged on this Front End.
LoopCare transaction statistics can be used to analyze system load and to
discover equipment failures, shortages, and excesses. It should be run:
• When new software, firmware, or hardware is installed. These early
reports should be saved and compared with later reports that are run when
troubles are suspected or new software or hardware is added.
• Regularly to make sure that the system is running smoothly. The
recommended interval is once every month or two. These periodic
"snapshots" of the system can also be used to compare with later reports.
• When the user complains of slow response time, excessive system errors,
or inaccurate test results (OPEN INs, for example).

The log area from which this information is taken is currently sized to log
approximately one week of LoopCare transaction data before being overwritten.
Remember that LoopCare transaction data is "always" being logged (this is an
LMOS requirement). The FacMan initiates and terminates the LoopCare logs with
the LOG request on the SAM mask.

Note that DCTUs are not logged except in the Request Distribution Report,
therefore LOG -S (Start) and LOG -E (End) are invalid LOG transactions for
DCTUs on SAM. A line 24 message to that effect INVALID REQUEST FOR
DCTUS will appear if a log request is made for a DCTU. For a list of valid, invalid
and changed SAM requests for DCTUs, see the SAM Usage Guide.

Generating a 1. To start the statistics program, enter:

Statistics Report mltst.sh
The program prompts the user as shown in the example below:

NOTE:
The program accepts either lower or upper case alphabetic entry. A
carriage return follows the response to each prompt.

*** WELCOME TO MLT STATISTICS PROGRAM ***

Enter MLT1 or MLT2:

4-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Statistics Logging & Collection

2. Type the LoopCare version and press Enter. (This example illustrates an
MLT2 statistics report).
* * * MLT2 STATISTICS PROGRAM * * *
****FOR ADMINISTRATIVE FRONT END****
****SET DCN and LTS NUMBER FOR LTS EQUIPMENT REPORT****
ENTER DCN (1-15):
3. Type the DCN number and press Enter.
ENTER LTS NUMBER [1-768] FOR DCN 1:
4. Type the LTS number corresponding to the DCN number entered in step 2
and press Enter.
ENTER SYSTEM TYPE <ANS, CAS, ATRM or ALL>: ans
5. Type in the type of system for which transactions are to be reported and
press Enter. For ANS or CAS selection, go to step 4a or 4b; otherwise go
the step 6.
a. If ANS is selected, the following prompts appear:
You entered < ans > is this correct? (y or n) y
Do you want to specify Data Kit NODE, MODULE and
CHANNEL?
ENTER (y or n): y
If you respond yes, additional prompts appear:
**** SET DATA KIT NODE, MODULE and CHANNEL ****
*** FOR MLT2 TRANSACTION TRACKING ****
ENTER < DATA KIT NODE >? capone
You entered < capone > is this correct (y or n)? y
ENTER MODULE (1-128) or ALL: 1
You entered < 1 > is this correct (y or n)? y
ENTER CHANNEL (5-130) or ALL: 5
You entered < 5 > is this correct (y or n)? y
Transaction activity will be reported on all ANS
terminals on NODE capone on MODULE 1 CHANNEL 5
b. If CAS, or ATRM is selected, the user is asked whether they want to
specify a Line and Device.
If the user responds yes, additional prompts request the following:
A line number (1-99) or ALL. If a line number is
specified, the user is prompted for:
A device number (1-99) or ALL.
6. Respond to the additional information on the report as requested below
(sample responses shown with the prompts):

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-5

System Administration Guide Performance Monitoring
Statistics Logging & Collection

ENTER START TIME (HHMMA/P) : 0700a

ENTER START DATE (MM/DD/YY) : 11/10/89
ENTER END TIME (HHMMA/P) : 0900p
ENTER END DATE (MM/DD/YY) : 11/23/89
ENTER TAPE DRIVE NUMBER (0 or 1 or q): 0
PROCESSING TAPE
This tape was created on MLT FE 53
Do you want to continue? ( y or n ): y
**** END OF TAPE ****
**** TIME OF LAST MLT-2 RECORD READ: 111627A ****
IS THERE ANOTHER LOG TAPE FOR THIS INTERVAL? (y/n) n
0 LTS_RESET requests processed
STATISTICS REPORT FILE: /mlt/tmp/M2LOGout.7099
mlt:
The program will then run, with the output sent to a file whose name is
displayed at the user's terminal.
Note that the requested start date/time cannot be greater than the current
(system) date/time. Also note that the report start and end dates must be
within the same year.

NOTE:
If the program MLT2LOG encounters an unknown request code on the log
tape, it issues a message on the user's terminal after reading the tape. For
example:

sam request 201 not found

2 occurrences
This message is for informational purposes only, and does not require any
user action.

The Output When you specify the LTS frame on the LoopCare Statistics Program interface,
the transaction logging and the early reports of the output will include all MLT-2
type transactions going through the LoopCare machine. The equipment logging
reports will be restricted to the frame specified.

If you specify lines and devices on the interface, the transaction logging reports
will contain only transactions spawned by those terminals.

4-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Statistics Logging & Collection

All of the reports have the general heading "LoopCare Transaction Report," along
with the LoopCare Front End identification, start time and date, and end time and
date. The following reports are given.

Request This report, which spans three pages, shows the total number of transactions
Distribution processed between the start time and the end time for the specified lines and
devices. These cover TV, TEST, and SAM requests and TE and PST
transactions. (Note that only the cases where the above requests were
processed by an LTS, RMU/CMU or DCTU are included in these reports. When
both LTF and LTS-type testing are available, only SAM and TV requests are
processed by the LTS equipment. The others are normally routed to the LTF
hardware).

The first page of this report shows the distribution of each TV request over time.
The horizontal axis is composed of twelve equal length time intervals between the
start time and the end time. Each interval is identified by its start time (10:00 for
the 10:00-11:00 interval, for example). The size of the interval depends on the
amount of time between the specified start and end times. To get one-hour
intervals the user should have at least a twelve-hour range. The last column gives
the total number of requests across the entire time period.

Example Output Following is an example of this output. Some portions of this sample report were
removed to include it here.

Figure 4-1. Requests Distribution Report.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-7

System Administration Guide Performance Monitoring
Statistics Logging & Collection

The second page of this report provides the same information for SAM requests;
the third page reports TEST requests, TE transactions and PST transactions.

Note that only transactions using the LTS are logged. TV requests that involve an
LoopCare Front End data base only (LAM requests, for example) are neither
logged nor reported.

As shown in this example, this report tells the FacMan which requests are being
run and when. The FacMan can note, for example, that very few QUICK requests
are being made. And because this request uses fewer system resources than a
FULL request, the FacMan or Headquarters Staff might recommend that the
QUICK request be used more. The FacMan might also notice an abundance of
MDF requests. This would influence trunk sizing plans or perhaps indicate that the
MAs are using MDF trunks when they could be using No-Test trunks. Again, MC
management should be informed of such a trend.

This report also gives the FacMan an idea of when the system is busiest.
Comparing the columns would indicate when the greatest number of requests are
being made. The FacMan could use these periods to see how well the system is
handling its heaviest load. The FacMan can also tell the MC managers when to
expect some processing delays.

Another use of this information is in scheduling PST runs. These tests should be
run when the system load is lightest, which in indicated on the first page of the
report.

The last page, which shows the PST statistics, indicates whether these tests are
actually running and finishing in the scheduled time period.

If the line and device options are used, this report indicates which requests are
being requested by each MC position. The FacMan or Headquarters Staff can
examine the difference in LTS-type usage between screeners and dispatchers, for
example. One would indeed expect to find differences in this study, with screeners
using primarily the FULL, LOOP, and MDF requests, while the dispatchers use the
interactive requests like TONE, LOOK, LOCATE, and QUICK.

Elapsed Time This report, which also spans three pages, indicates how long the LTS hardware
was used for each request. This measure, called the "elapsed time," is defined as
either the actual time the transaction used or the maximum time it was allowed
plus 0 to 30 seconds. (If a transaction needs more time than it is allowed by the
software it is deleted and the maximum time allowed is shown on the report. The
addition of up to 30 seconds is due to the fact that time-outs are in 30-second
intervals.) The elapsed times for long-term accesses, such as TONE, is the time it
took to process the request, not how long the access was up (how long the tone
was on the line, for example).

4-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Statistics Logging & Collection

The first page displays the elapsed time distribution for TV requests. The
horizontal axis is composed of twelve time intervals of 10 seconds each. Each
interval is identified by its upper bound (i.e., 20 for the 10 to 20 second time
interval). The time interval >110 contains anything above 110 seconds. The last
area gives the average elapsed time. The vertical axis lists the different requests.

The second page displays the elapsed time distribution for the SAM requests.
• The SAM entry DLOAD is reported as an LTS-RESET and involves two
passes through the software. The reported elapsed time covers only the
second pass. All LTS-RESETs are reported to the FacPrinter, whether they
are initiated by a DLOAD request or generated by the hardware. Because
only those initiated by DLOAD are shown on this report, the number of
spurious LTS-RESETs (those generated by the hardware) can be
determined by subtracting the number of LTS-RESETs reported here from
those reported on the FacPrinter.
• When a TC request is made on the SAM mask, the LTS will continue to try
to access a trunk if it is busy. These retries are reflected in the elapsed
time. Thus, the elapsed time for this request can exhibit wide variability.
Thus, this measurement is really only useful to monitor extraordinary
changes in TC request processing.

Following is an example of one of these reports. As before, some information is

excluded to display the report here.

Figure 4-2. Elapsed Time Report.

The third page displays the elapsed time distribution of the TEST, TE, and PST
transactions. If users report slow response time, the FacMan should check this
report to see if the delays are attributable to the LTS hardware. The best way to do
this is to compare a recent report with one that was run when there were no
complaints. Such a report will be available if the FacMan gathers MLT STAT
reports routinely.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-9

System Administration Guide Performance Monitoring
Statistics Logging & Collection

The FacMan should remember that the time it takes for a request to run depends
to a large extent on the condition of the pair that is tested. A TEST OK will take
longer than a SHORT, because all of the tests in the LoopCare algorithm are
made. When a fault condition exists, LoopCare stops testing because the later
tests would be inaccurate. The elapsed time report is most useful when it
represents many requests, because over time a large cross-section of conditions
occur.

VER Code This report displays the VER Codes reported by all of the requests that return
Distribution VER Codes (FULL, for example). The horizontal axis lists these requests
followed by columns for the sums. The vertical axis lists the VER Codes that were
encountered in the log data for these test requests.

Following is an example of this report. Some requests (LOOPIN, for example)

that return VER Codes are omitted to include the example here.

Figure 4-3. VER Code Distribution Report.

In a combined LTF and LTS environment, this report is the only one that shows
which VER Codes are being returned by the LTS equipment. TREAT reports
reflect VER Codes returned by the TE/TR transaction. In a combined
environment, these transactions are almost always routed to the LTFs. See the
Facilities Manager Guide module entitled Which System Did the Testing
(fac.which). The TREAT reports refer to LTF testing, NOT the LTS-type testing.
However, in an environment without LTFs, both TREAT and VER Code
Distribution reports can be used.

The most frequent use of this report is to see if MC reports of excessive results of
one type are actually occurring. A common problem is that LoopCare is incorrectly
identifying OPEN IN or OPEN OUT conditions. This report can tell the FacMan if
there seems to be an excess of either one. Other factors to look for include

4-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Statistics Logging & Collection

• Many TEST OKs, which may mean that unnecessary testing is occurring
• Certain requests returning too many system error VER Codes (B0, for
example). This could indicate a serious hardware problem.

Equipment Report The equipment report summarizes the information collected and saved at the LTS
level. For each LTS enabled from the SAM mask, this information is sent every 10
minutes to the LoopCare administrative FE. Note that there can be up to 10 LTSs
enabled at one time. The report is particularly useful for checking and monitoring
the sizing of the equipment for the LTS. Because the information is logged every
10 minutes, reports covering short periods of time (< 30 minutes) are distorted.

Each LTS has its own report spanning a few pages. The heading on each page
gives the name of the report and the LTS ID. The next three lines specify the
LoopCare Front End number, the start time and date, and the end time and date.
This is followed by the list of the exchanges covered by the LTS.

For each LTS, the first page reports on the usage of the following LTS devices: +
PMU
• Multifrequency dialer (MFD)
• Dial pulse dialer (DPD)
• Busy detector (BYD)
• Touch-Tone DDD dialer (TDDD)
• Pulse DDD dialer (PDDD)
• Ringing supply distributor (RING).

For each one of these devices the following is reported:

• The number available
• The number of requests made
• The number of requests granted
• The total delay time in seconds
• The average delay time in seconds
• The total hold time in seconds
• The average hold time in seconds

Finally, the number of times that a certain number of the devices was available; for
example, how many times 0 BYDs were available, or 1 BYD was available, or 2
BYDs were available, etc.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-11

System Administration Guide Performance Monitoring
Statistics Logging & Collection

The next pages report the same usage data for each trunk group served by the
LTS.

The following is an example of a portion of this report.

Figure 4-4. Equipment Report (Example 1).

Note that because there is only one busy detector, Touch-Tone DDD dialer, pulse
DDD dialer, and ringing distributor in this LTS, the number of times that two such
devices were available is reported as ( - ). The same is true for trunk groups
shown below.

Figure 4-5. Equipment Report (Example 2).

4-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Statistics Logging & Collection

Usage Counts These reports are particularly valuable for evaluating equipment sizing decisions.
The LTS counts every attempt to use a device as a REQUEST. This includes
times when it had to make a second or third try because the device was not
available on the first try. It counts all successful attempts as a GRANT.

If the REQUEST and GRANT counts are very different for a particular device,
there could be a hardware problem because the LTS can't access that device
consistently. A more likely reason is that the device is not available. The easiest
way to verify this is to determine how often a device was requested and if none
were available. This is given in the OCCUR 0 LIKE AVAIL line for each device.

If the count is high the LTS is receiving requests for that device but not able to
grant that request. This is true of the busy detector (BSY_DET) in the above
example. The LTS received 39 requests for a busy detector that it could not
immediately grant. When this happens the LTS makes a second try to use the
device and in fact keeps trying until it is successful or until 20 seconds elapse.

Delay Time The time is takes to finally get a device on subsequent attempts is shown in the
DELAY TIME row. The value given is the total delay for all successful requests.
To obtain an average delay time, divide this figure by the number of OCCUR0
LIKE AVAIL. If the average delay time is high, sizing decisions should be
reevaluated. In the example above, the delay time for the busy detector was 390
seconds, which averages out to 10 seconds -- a long time to wait for a busy
detector. A second one should be added to the LTS.

Conversely, if large numbers of a certain device are always available, the system
may be oversized. In the trunks example above, trunk group 3 (TK_GP3) had
three trunks available for all 19 requests made of that group. This may indicate
that three trunks are not necessary.

Trunk access problems are evidenced by long average delay times. The average
delay should not be more than 20 seconds, because the LTS stops trying to
access a trunk after that interval.

Hold Time Another important statistic in this report is HOLD TIME. Once again, the LTS
reports the total hold time for each device type. To get the average, the total hold
time, should be divided by the number of GRANTS. This average should be low
for most of the equipment reported on the first page of this report. The PMU
should be the highest, reflecting the number of measurements it makes on a line.
As mentioned earlier, this figure depends on the condition of the line as well as the

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-13

System Administration Guide Performance Monitoring
Statistics Logging & Collection

condition of the hardware. It will take longer for TEST OKs than for fault
conditions.

In the above example the average hold time for the PMU is 20 seconds. The
average hold times for the other devices should be close to those shown in the
example: 2.7 seconds for MF dialers, 7.2 seconds for DP dialers, 1.7 for busy
detectors, and 2.0 seconds for TT DDD dialers. The average hold time for rotary
DDD dialers and the ringing distributor, which were not used in the above
example, should be approximately 8 seconds and 1 second, respectively.

For LTS-type testing, the average hold times for test trunks can be very important.
Unlike the LTF, trunks are not dropped after a request is completed. The LTS
keeps access until told to drop it by the MA. The average hold time can tell the
FacMan how long the MAs are keeping access to these trunks.

In the example above, the trunks in trunk group 1 were held for an average of 6
minutes, those in trunk group 2 for an average of 42 minutes, and those in group 3
for an average of about 8 minutes. Because most of these accesses reflect
interactive testing activity, the 6 and 8 minute times are not a problem. The 42-
minute average is high, but this might be caused by one particularly long access
(a TONE, for example), since there were only four grants for this trunk group. If
these times are abnormally high the FacMan should inform MC management,
especially if there are also sizing problems associated with the trunk group.

NOTE:
The values shown in the above examples were taken from a real LoopCare
system with LTS testing. That does not mean that they will match the norm
for every LoopCare system. Each FacMan should find those norms by
running LoopCare STAT at installation and at routine intervals. The results
can be used as a benchmark for the system. The safest way to verify any
equipment problems is to compare recent values with those received when
the system is performing well.

4-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
What TREAT Can Tell You

What TREAT Can Tell You

Overview The FacMan should be familiar with TREAT and use it to monitor the LoopCare
system. The facility manager must be aware, however, that TREAT analyzes the
results from TE/TR transactions only. It does not look at the results of TEST or TV
requests. In a combined LTF/LTS environment, TE/TR transactions are routed
primarily to the LTF As such, TREAT tells the FacMan very little about LTS
performance in that case. It can, of course, be quite useful in LTS stand-alone
environments.

The most valuable TREAT report is the VER code by disposition matrix. This
matrix can help the FacMan discover or verify cases where the system reported
inaccurate results. A weekly review of this report is recommended. Problem
trends can be further examined with the TREAT detailed lists which allow the user
to sort specific VER codes by whatever information they wish.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-15

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

Testing Activity Feature (TAF)

Overview The Testing Activity Feature (TAF) provides a history of all test transactions
performed by the LoopCare test heads. This information can be used to identify
defective ports, trunks, RMUs, etc., and to help solve sizing and blockage
problems by determining the source and amount of test traffic that passes through
each test head.

TAF logs one line of information for each test request sent to a test head. Only
initial entry data for long-term accesses are logged. An additional log file records
transactions that were returned by LoopCare prior to the actual running of a test.

To set up TAF the tafman module must be running. See the MGRP.gdf section in
Appendix B.

Users can create shell scripts to gather particular data that they might need to
solve a problem. For example, a sort on a specific test head could be performed
to determine if a persistent blockage condition is caused by heavier than expected
test requests.

Managing the TAF Use the OA&M to manage the behavior of the TAF feature. The TAF Request
Feature option allows you to determine which report files are generated. See the
Operations, Administration and Maintenance (OA&M) Guide.

The ADEF TAF Requests screen replaces the tafreq.src and taf.src files used in
LoopCare releases before Release 1.5.

Test Activity Logs The Test Activity logs are /mlt/reports/TAF.STAT, /mlt/reports/
HUB.LTE.STAT, /mlt/reports/UNTESTED.STAT, /mlt/reports/
TAF.ROH.STAT, and /mlt/reports/LTE.STAT. If the Break-Through CPE
Detection feature is enabled and the TAF.STAT file is generated, the
TAF.CPE.STAT log records all occurences of the AC test associated with this
feature. If the BSU VOIP feature is enabled, the VOIP.STAT log is generated. See
the System Description for more information.

TAF.STAT Log There are 14 data items captured for each log entry. If the NEWTAFFORMAT
variable set to Y/y, the DCN, MLT and PORT columns do not appear and the
LOOP field is expanded to accomodate 5 digits.

4-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

• DCN ID (D) - A single character identity of the DCN (or LCN or LTCN)
associated with the MLT2 test head. This column will be blank if no DCN is
associated with the test.
• MLT Testhead ID (MLT) - Identifies the testhead used for the test. The
choices are: HUB, DCTU, LTS, CMU, LTF, EMU, RTU, SLIM and EWSD
with internal testing. For the first four, the letters H, D, L and C are used
followed by an ID number. For the LTF, the letter F is followed by three
digits that represent the LTF ID (1 digit) and the 11/34 controller ID (2
digits). For the EMU, the letter E is followed an ID number. For the last
three, R, S, and d are used. If an RMU (RTU) testhead is used together
with a HUB, DCTU, LTS, CMU, or EMU, it will be identified in the LOOP
Type field.
• Port ID (PRT) - Identifies the port or trunk (LTF) or trunk group (LTS) ID
used. The value is 2 digits in length. For MDF trunks accessed via a HUB
XMU this field contains the slot number of the XMU. For MDF trunks
accessed via a HUB TMU, this field contains the odd TAP number.
• Exchange Key (EXK) - Identifies the trunk group and the switch.
• Switch Type (SW) - Identifies the type of switch. See Table 4-1 on page
4-17.

Table 4-1. Swtich Types

Type Code Name

1 XBAR
2 SXS
3 RSS
4 PANEL
5 XBAR-5
6 XBAR-1
7 ESS-5
8 ESS-5D
9 ESS-1
10 ESS-2
11 ESS-3
13 ESS-1R
14 ESS-2R

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-17

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

Type Code Name

16 DMS-10
17 DMS100
20 D100AC
21 S-EWSD
22 FET150
23 AXE-10
24 SC-DCO
25 GTD-5
26 NEAX
27 UNKWN
28 UNKWN
29 UNKWN
30 UNKWN
31 ESS-5S
32 ESS-5A
33 ESS-5DA
34 TELACCORD
35 HARRIS
36 METASW3500
37 LTSC

• Source of Request (SRC) - Identifies where the request came from (TV
mask, TEST mask, Predictor, PST, Craft Access System, TE/TR).

Table 4-2. Source of Test Request

Source Abbreviation
TV TV
TEST TST
PREDICTOR PRE
CRAFT ACCESS CAS
SYSTEM

4-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

Source Abbreviation
TE/TR TE
MSCR MSC
DISP DIS
RETEST RET
TRFULL TRF
TRCALLED TRC
ADSL BATCH XDL
PDA PDA user
BAT Batch GUI
ICM ICMS on demand
PST ICMS batch
GUI End User GUI
IVR IVR user

NOTE:
The abbreviation "PRE" used for Predictor transactions, is a special case
use of the TEST mask. A TEST mask transaction using Employee Code
(EC) 999 is assumed by LoopCare to be a Predictor Test mask request.
Any system/user that executes a TEST mask request and enters the EC of
999 is logged with SRC=PRE.

NOTE:
For customer- created interface systems identifying themselves in the
REQTYPE packet field, the first three letters of this packet field will be
placed in the SRC field in TAF. See Test Request Abbreviations.

NOTE:
When, in the GCM environment, an RMU testhead ID does not correspond
to the Central Office (CO) testhead ID, an atypical output will appear in the
TAF.STAT log file: asterisks appear in the RMU ID field and the actual RMU
ID appears at the end of the line, together with the DCN and testhead ID,

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-19

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

lengthening the line and causing it to wrap. Sample typical and atypical
lines are shown below:

• Request (RQ) - Identifies the type of test request entered (i.e., FULL,
LOOP, CO, etc.).
• VER Code (VC) - Identifies the VER Code reported to the user.
• Loop Type (LOOP) - The type of loop is identified in this field as well as the
RMU ID (where applicable).
"M" defines metallic loop, in the format "Mxxx," where xxx is the RMU
Number (1 to 768)
"I" defines Integrated DLC
"U" defines Universal DLC.
"D" defines DSL off a DSLAM or DLC.
"B" identifies a bPON line.
"T" identifies an MTAU line.
If an RMU is associated with either a UDLC or IDLC, it will have an RMU ID
attached to the "U" or "I."

NOTE:
See the MGRP.env NEWTAFFORMAT variable in Appendix B for more
detail on the contents of this field.

• Directory Number (TN) - Identifies the directory number tested.

• Office Equipment (OE) - Identifies the subscriber office equipment (16
characters max).
• Date (DATE) - The date of the transaction (mmdd).
• Time (TIME) - The time of day the transaction started (hhmmss).
• Holding Time in Seconds (SEC) - The holding time of the initial test is
given in seconds.

NOTE:
Test Request The X, XTONE, and XCB test requests are logged in TAF.STAT and
Abbreviations LTE.STAT only if the MGRP.env variable, tafx, is set to Y/y.

4-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

Test Request Abbreviation

ATMLB AL
ATMLBOUT AO
ATMLBOUTX AOX
ATMLBX ALX
ATMRSP AR
ATMRSPX ARX
BENCH B
BENCHX BX
BT BT
BTX BTX
CALL CLL
CALLRD CRD
CCOL CC
CCOLX CCX
CHANNEL CHN
CHOME CH
CO CO
COIN CN
COINX CNX
COX COX
CRET CR
CRETX CRX
CSET CS
CSETX CSX
DCOILX DCX
DIAL DIA
DIG DIG
DSLDIG DDG
DTOUT DT
DTOUTX DTX

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-21

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

FTTPDIG FDG
FULL F
FULLX FX
GRM GRM
HOWLER HWR
HTPUT HP
HTPUTX HPX
HTTP HT
HTTPX HTX
INFO INF
ISDN_TE OER
ISPINFO IIN
ISPSYNC ISP
KEEP KP
LCOILX LCX
LDX LDX
LIN LIN
LINESP LSP
LINX LNX
LLOOP LL
LLOOPX LLX
LOC1 LO1
LOC2 LO2
LOCATE LOC
LOCATOR LO
LOCGP LGP
LOOK LK
LOOKIN LKI
LOOP L
LOOPX LX
LPBX LPB

4-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

LRM LRM
LRMX LMX
MDF MDF
MDFGRP MGP
MDFNUM MNM
MEASTONE MTN
MEASTONEX MNX
MET MET
METX MTX
MON MON
NFULL NF
NFULLX NFX
OPEN OPN
PER PER
PING PN
PINGX PNX
PKT PKT
PML1 PM1
PML2 PM2
PML3 PM3
PSR PSR
QIN QI
QINX QIX
QUALX QLX
QUICK Q
QUICKX QX
REF0 R0
REF0X R0X
REF1 R1
REF1X R1X
REF2 R2

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-23

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

REF2X R2X
RESPOND RSP
RESTORE RST
REV REV
RING RNG
RING+ R+
RINGER RGR
RINGERX RRX
RINGIN RIN
RINGIN+ RN+
SENDTONE STN
SOAK SOK
SOAKX SKX
SSA SSA
STATUS STS
SYNC SY
SYNCOUT SO
SYNCOUTX SOX
SYNCX SYX
TAKE TKE
TALK TLK
TALKIN TKI
TAP2 TP2
TDR TDR
TDRX TRX
TONE TN
TONE+ TN+
TONECA TCA
TONEIN TNI
TPUT TP
TPUTX TPX

4-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

TRACE TR
TRACEX TRX
TT TT
WNOISE WN
WNOISEX WNX
X X
XCB XCB
XTONE XTN

Sample TAF.STAT Below are 2 TAF.STAT files with and without the NEWTAFFORMAT variable set to
Log File Y/y, respectively.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-25

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

TAF.CPE.STAT This log records all occurrences of the AC test included in the Break-Through
Log CPE Detection feature. It contains most of the data fields in the TAF.STAT log plus
additional AC test measurements.

There are 16 data items captured for each log entry. They are:
• DCN ID (D) - A single character identity of the DCN (or LCN or LTCN)
associated with the MLT2 test head. This column will be blank if no DCN is
associated with the test.
• MLT Testhead ID (MLT) - Identifies the testhead used for the test. The
choices are: DCTU, LTS, CMU, LTF, and EMU. For the first three, the
letters D, L and C are used followed by a 4-digit ID number. For the LTF,
the letter F is followed by three digits that represent the LTF ID (1 digit) and
the 11/34 controller ID (2 digits). For the EMU, the letter E is followed by a
3-digit ID number. If an RMU (RTU) testhead is used together with a
DCTU, LTS, CMU, or EMU, it will be identified in the LOOP Type field.
• Port ID (PT) - Identifies the port or trunk (LTF) or trunk group (LTS) ID
used. The value is 2 digits in length.
• Exchange Key (EXK) - Identifies the trunk group and the switch.
• Switch Type (SW) - Identifies the type of switch. See Table 4-1 on page
4-17.

4-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

• Source of Request (SRC) - Identifies where the request came from (TV
mask, TEST mask, Predictor, PST, Craft Access System, TE/TR). See
lengthening the line and causing it to wrap. Request (RQ) - Identifies the
type of test request entered (i.e., FULL, LOOP, CO, etc.).
• VER Code (VC) - Identifies the VER Code reported to the user.
• LOOP Type (LOOP) - The type of loop is identified in this field as well as
the RMU ID (where applicable).
"M" defines metallic loop, in the format "Mxxx," where xxx is the RMU
Number (1 to 768)
"I" defines Integrated DLC
"U" defines Universal DLC.
If an RMU is associated with either a UDLC or IDLC, it will have an RMU ID
of up to 3 digits attached to the "U" or "I." "B" identifies a bPON line.
• Directory Number (TN) - Identifies the directory number tested.
• Date (DATE) - The date of the transaction (mmdd).
• Time (TIME) - The time of day the transaction started (hhmmss).
• Holding Time in Seconds (SEC) - The holding time of the initial test is
given in seconds.
• AC Tip-Ring (ACTR) - AC resistance measurement for the Tip-Ring side of
the line.
• AC Tip-Ground (ACTG) - AC resistance measurement for the Tip-Ground
side of the line.
• AC Ring-Ground (ACRG) - AC resistance measurement for the Ring-
Ground side of the line.
• Test Sequence (SEQ) - Identifies the LoopCare test sequences used to
determine the presence or absence of CPE terminations on the loop. It is
intended for internal use only .
• DC Fault (DCF) - Indicates whether or not there is a DC fault on the line. Y
= yes; N = no.

Sample
TAF.CPE.STAT Log
File

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-27

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

UNTESTED.STAT UNTESTED.STAT contains transactions that were bounced by LoopCare prior to

Log running a test (i.e., VER E7 - NPANNX NOT IN DATABASE, VER NT - NOT MLT
TESTABLE, etc.). These problems indicate either database inconsistencies or
user errors and thus information required to troubleshoot these occurrences is
much different from the data required to troubleshoot testhead problems.

There are 12 data items (column heads) that are captured by UNTESTED.STAT.
They are:
• EXK - Line Record EXK or EXK from DEFEXK
• TN - TN tested
• VC - Resultant VER Code
• LR - Was a Line record obtained? Y for YES, N for NO
• P - Ported flag from line record where:
• O = Ported-out
The DN has been ported-out from the original serving LEC (the
LMOS system owner).
• I = Ported-in
The DN has been ported into the currently serving LEC (the LMOS
system owner) from an external LEC (NOT the LMOS system
owner).

4-28 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

• W = Win Back
The DN was ported-out but has been ported back to the original
serving LEC (the LMOS system owner).
• R = Reclaim
The DN is vacant. There is no customer service.
• U = Unknown (Default)
• LRNUSED - Indicates which LRN was used to perform the test. An LRN
with a T suffix indicates that the TV override field was used. An LRN with a
L suffix indicates that the Line Record LRN was used.
• OVER - The contents of the OVER field of the TV mask
• SRC - Source of the request. Same as in the TAF log.
• RQ - Type of request. Same as in the TAF log.
• OE - Line record OE or OE entered on TV mask.
• DATE - Date of request
• TIME - Time of request

NOTE:
For all instances where data for a particular column was not available, a
single '-' will occupy the column.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-29

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

Sample
UNTESTED.STAT
Log File

LTE.STAT Log The TAF.STAT and UNTESTED.STAT logs both require that the TN identify the
test equipment. However, for tests that use Circuit Data Inputs from the End User
GUI (such as Loop Terminating Equipment Id), a separate log file, LTE.STAT will
contain these transactions. Both tested and untested records will be logged in
LTE.STAT; the displayed VER code can be used to distinguish between tested
and untested.

The following data items (columns) are captured in LTE.STAT.

• Circuit ID (CIRCUIT ID) - The circuit identification number is a single
unique identifier that points to the access information of a line. This is used
in place of a telephone number.
• LTE AID - The Access Identifier used in testing , including the identifier for
the Loop Terminating Equipment, typically the CLEI (Common Language
Equipment Identifier) code. For examples of LTE AIDs for different types of
LTEs, see Sample LTE.STAT Log.
• Test Unit Used (UNIT) - this is the RMU-S Sequence Number
• Source (SRC) - Identifies where the request came from (GUI, TV, API)
• User ID (USER ID) - user who initiated the request

4-30 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

• Request (RQST) - Type of request, all the requests recorded in the TAF log
plus the following.

Test Request Abbreviation

VOIP V
VOIPX VX
VOIPRING VR
VOIPRINGx VRX

• Date (DATE) - Date of the request (mmdd).

• Time (TIME) -Time of day the request was started (hhmmss).
• Test Duration (SEC) - Holding time of the initial test, given in seconds.

NOTE:
When the Circuit ID is not entered for a test request, a “-” is displayed in the
LTE.STAT Circuit ID field.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-31

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

Sample LTE.STAT
Log

CIRCUIT ID LTE AID

UNIT SRC USER ID RQST VC DATE TIME SEC

--------------------------------------------------------
- LET/RST1/1/01/1
37 GUI afctst MTX 0T 1120 110829 058
- adtranip/1/01/01/01
6 GUI adc MTX 47 0520 092647 029
- adccraft/08/01/01
17 GUI load001 LX 0C 0520 092631 098
- amulet5/00/00/00
38 GUI tester1 TR -- 0520 095133 000
- turnstoneip/1/5/1
19 API - LX 0E 0630 154932 139
- stinger1/1/1/1
- API - LX 0D 0630 155450 172
- adtran3050/1/01/01/01
5 GUI load001 FX 47 0615 095457 035
- nicotraip/00001
19 GUI tester3 LX 0E 0629 092726 153
- bwamdau1/0000
5 GUI tester2 L 0E 0708 174314 111
- AMAS1/1/1/1
17 API - LX 41 0630 152638 038
- ASAMsim72/1/1/1/1
136 API - LX 0T 0709 074248 198
- COTBW/COT/01/02/01
287 GUI load002 COX 36 0615 155420 049
- nicotraip/00300
19 GUI lmerola LX 0E 0630 132048 152
- TL1TEL2/0001
5 API - LX 0E 0630 155854 101
-

4-32 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

CIRCUIT ID LTE AID

UNIT SRC USER ID RQST VC DATE TIME SEC

--------------------------------------------------------
- POLT-pinky/1/1/99/9/99
- GUI tester4 FDG HK 0628 155916 004
- bwparadyne/1/1/02/1/01
19 GUI tester3 QLX 0 1009 131547 080
- cienaip/001/01/01
37 GUI tester3 MTX 0C 1011 113446 058
- bblwip/1/01/01
37 GUI tester1 MTX 0C 1104 105632 058
- entrisphereip/11/04
37 GUI tester5 FX 41 0114 133952 192
- msas/00/2/04
37 GUI tester6 FX 41 0222 143036 181
- calixc7/1/1/3/2
20 GUI tester1 FX 0 2505 114626 138
- malc7/1/1/3
20 GUI tester1 FX 0 2505 114626 138
- 7330a/1/1/4/5
20 GUI tester1 FX 0 2512 114628 138
- acemap01/1/1/4
20 GUI tester1 FX 0 2512 114628 138
- accessnode1/1/6
20 GUI tester1 FX 0 2612 114626 138
- hn40002/3/29
20 GUI tester1 FX 0 2812 114628 138

NOTE:
An LTE.STAT log record occupies more than 80 characters due to the
maximum length that must be allowed for each field. Thus, the header and
each record wrap around to the next line in the log file.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-33

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

VOIP.STAT Log VOIP.STAT logs all VOIP tests.

The following data items (columns) are captured in VOIP.STAT.

• VoIP Source (Circuit Access Information of BSU-equipped test head)
• VoIP Destination (SIP ID / TN)
• VER Code
• Source (SRC) - Identifies where the request came from (GUI, TV, API)
• User ID (USER ID) - user who initiated the request
• Request (RQST) - Type of request, all the requests recorded in the TAF log
plus the following.

Test Request Abbreviation

VOIP V
VOIPX VX
VOIPRING VR
VOIPRINGx VRX

• MOS Score - Listening (MOS-LQ)

• MOS Score - Conversational (MOS-CQ)
• Date (DATE) - Date of the request (mmdd).
• Time (TIME) -Time of day the request was started (hhmmss).
• Test Duration (SEC) - Holding time of the initial test, given in seconds.

4-34 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

Sample VOIP.STAT
Log

HUBLTE.STAT Log All TAF data on lines accessed via a HUB's TMU TAPs are logged in /mlt/reports/
HUBLTE.STAT.

The following data items (columns) are captured in HUBLTE.STAT.

•
• DCN ID
• HUB ID
• TMU SL - HUB slot number where the TMU is located.
• TAP IN - look-in TAP number
• TAP OUT - look-out TAP number
• ACCESS INFO - access information: LTE ID, Rack, Shelf, Slot, Circuit,
etc., separated by slashes.
• SRC - the source of the request (GUI, TV, API)
• RQ- Type of request. See Test Request Abbreviations on page 4-20.
• VC - VER Code
• DATE - Date of the request (mmdd).
• TIME -Time of day the request was started (hhmmss).

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-35

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

• SEC - Holding time of the initial test in seconds.

TAF.ROH.STAT This log records all occurrences of the ROH (Receiver Off Hook) test included in
Log the Enhanced ROH feature. It contains most of the data fields in the TAF.STAT log
plus additional ROH test measurements.

There are 19 data items captured for each log entry. They are:
• DCN ID (D) - A single character identity of the DCN (or LCN or LTCN)
associated with the MLT2 test head. This column will be blank if no DCN is
associated with the test.
• MLT Testhead ID (MLT) - Identifies the testhead used for the test. The
choices are: DCTU, LTS, CMU, LTF, and EMU. For the first three, the
letters D, L and C are used followed by a 4-digit ID number. For the LTF,
the letter F is followed by three digits that represent the LTF ID (1 digit) and
the 11/34 controller ID (2 digits). For the EMU, the letter E is followed by a
3-digit ID number. If an RMU (RTU) testhead is used together with a
DCTU, LTS, CMU, or EMU, it will be identified in the LOOP Type field.
• Port ID (PT) - Identifies the port or trunk (LTF) or trunk group (LTS) ID
used. The value is 2 digits in length.
• Exchange Key (EXK) - Identifies the trunk group and the switch.
• Switch Type (SW) - Identifies the type of switch. See Table 4-1 on page
4-17.
• Source of Request (SRC) - Identifies where the request came from (TV
mask, TEST mask, Predictor, PST, Craft Access System, TE/TR). See
lengthening the line and causing it to wrap.
• Request (RQ) - Identifies the type of test request entered (i.e., FULL,
LOOP, CO, etc.).
• VER Code (VC) - Identifies the VER Code reported to the user.
• LOOP Type (LOOP) - The type of loop is identified in this field as well as
the RMU ID (where applicable).
"M" defines metallic loop, in the format "Mxxx," where xxx is the RMU
Number (1 to 768)
"I" defines Integrated DLC
"U" defines Universal DLC.
If an RMU is associated with either a UDLC or IDLC, it will have an RMU ID
of up to 3 digits attached to the "U" or "I." "B" identifies a bPON line.
• Directory Number (TN) - Identifies the directory number tested.
• Date (DATE) - The date of the transaction (mmdd).

4-36 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Feature (TAF)

• Time (TIME) - The time of day the transaction started (hhmmss).

• Holding Time in Seconds (SEC) - The holding time of the initial test is
given in seconds.
• Resistance Low (RTRL) - Low DC resistance measured.
• Resistance High (RTRH) - High DC resistance measured.
• Delta (DELTA) - Difference between calculated resistance TR low minus
high.
• IDCCH - TG current from high voltage test.
• IDCCL - TG current from low voltage test.
• Retried (RET) - ROH tests retried, Yes or NO (Y or N).

Sample
TAF.ROH.STAT
Log File

Cleaning Up the The TAF.STAT, UNTESTED.STAT, and LTE.STAT files under /mlt/reports will be
Log Files cleaned up by mltclean.sh whenever LoopCare is bounced (see Group Descriptor
File for the MLT Group in Appendix A of the System Administrations Guide for
more information about mltclean.sh). In applications where LoopCare is bounced
nightly this results in the preservation of 2 days worth of data - the current days
data would be found in TAF.STAT, the previous days data would exist in
s1.TAF.STAT. Additional data can be saved as needed through the use of cron
and shell scripts.

The mltclean.sh module cleans up the following directories:

• /mlt/reports/cgi
• /mlt/tmp
• /mlt/webgui/results

The treatment of /mlt/webgui/results is determined by the following two

environmental variables in the MLT.env file:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-37

System Administration Guide Performance Monitoring
Testing Activity Feature (TAF)

• MLT_WEBFILES
• MLT_RMVWEBFILES

See Appendix B in this guide.

4-38 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LTE.ERR

LTE.ERR

Overview The LTE.ERR file, generated in /mlt/reports, facilitates troubleshooting

communication problems between LoopCare and LTEs and either TL1 or SNMP
(Zhone MALC only) processing problems.

The first line of each entry contains the following fields:

• date and time
• AID
• IP address and TCP port of the LTE
• type of error

If there is a communication error, text appears below the first line indicating the
nature of the error, for example, "Connection Failure". If the error is due to a
particular TL1 response, the response appears after the first line. Figure 4-6
illustrates both types of entries.

Figure 4-6. LTE.ERR

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-39

System Administration Guide Performance Monitoring
OPENSLOG.STAT

OPENSLOG.STAT

Overview If the -A option is used in the mltout module of the MGRP.gdf, the
OPENSLOG.STAT file is created in the /mlt/reports folder.

The OPENSLOG.STAT file has three fields in addition to those in the TAF.STAT:

RG AC resistance

TG AC resistance

TR AC Resistance

The OPENSLOG.STAT file is meant as a tuning tool for the OPENS Reduction
Feature.

4-40 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LoopCare Activity Report Generator (LARGE)

LoopCare Activity Report Generator

(LARGE)

Overview The LoopCare Activity Report Generator (LARGE) provides a Graphical User
Interface (GUI) to a report generator that processes test transactions submitted by
TN or circuit information that are executed by LoopCare test heads. LARGE data
is similar to that reported by TAF. Like TAF reports, LARGE reports can be used to
identify defective ports, trunks, RMUs, etc. and to help solve sizing and blockage
problems by determining the source and amount of test traffic passing through
each test head.

LARGE logs one line of information for each test request sent to a test head.
When the LARGE feature is enabled, TAF log files are still generated. For more
information on TAF. See Testing Activity Feature (TAF): page 4-16

In order to use the LARGE feature the tafman module must be running. See the
MGRP.gdf section in Appendix B.

In addition to using the LARGE GUI, you can create shell scripts to gather data
required to solve a specific problem.

LARGE Log Files The log file for the current day is LARGE.STAT, located in /mlt/reports/.

LARGE.STAT is automatically archived on a daily basis. The format for the name
of each archived file is LARGE.DDMM when your environment is configured for
international date format and LARGE.MMDD when it is configured for North
American date format, where DD = the day and MM = the month. The archived log
files are also located in /mlt/reports/TAF.

Procedure To access the LARGE GUI, click the Large link on the LoopCare GUI Circuit Test
page. This link appears only if you have Admin privileges. Below is an example of
the initial LARGE GUI page showing the specific types of reports that can be
generated.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-41

System Administration Guide Performance Monitoring
LoopCare Activity Report Generator (LARGE)

Click the desired report type to display the report criteria fields for that report type.
The report criteria fields appear on the right side of the page. For descriptions of
the report criteria fields see Table on page 4-49 .For example:

4-42 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LoopCare Activity Report Generator (LARGE)

After selecting a value for each input parameter, click the Submit button. Click the
Reset button at any time to reset the report criteria fields.

The report is displayed on the right side of the page.

Full LARGE Report The Full LARGE report displays all LARGE data (PSTN and DSL) for a user
specified time interval.

Below is an example of the Full LARGE report criteria page.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-43

System Administration Guide Performance Monitoring
LoopCare Activity Report Generator (LARGE)

LARGE PSTN The LARGE PSTN report displays PSTN data for a specified time period.
Report
The report criteria is the same as that displayed for the Full Large report.

LARGE DSL The LARGE DSL report displays DSL data for a specified time period.
Report
The report criteria is the same as that used for the Full Large report.

4-44 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LoopCare Activity Report Generator (LARGE)

User Activity The User Activity report provides data on the tests run by a specific user(s) for a
Report specified time period. For each test it shows:
• The telephone number or circuit identifier.
• The switch identifier or LTE ID.
• The test request type.
• The date and time the request was submitted.
• The VER code returned by the test request.

You can select multiple LoginId(s) by holding down the control key (Ctrl) while
clicking on login names. Selecting ALL is equivalent to selecting all users.

Below is an example of the User Activity report criteria page.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-45

System Administration Guide Performance Monitoring
LoopCare Activity Report Generator (LARGE)

User Results Report The User Results report provides summary data for a specific user(s) for a
specified time period:
• A list of test requests run by the user.
• A list of VER codes returned by these test requests.
• A percentage for each of these VER codes representing the percentage of
test requests that returned the VER code.

The report criteria is the same as that used for the User Activity report. You can
select multiple LoginId(s) by holding down the control key (Ctrl) while clicking on
login names. Selecting ALL is equivalent to selecting all users.

Switch Activity The Switch Activity report lists the tests run against a specific switch(s) for a
Report specified time period. For each test it shows:
• The login identifier of the user who submitted the request.
• The telephone number specified in the request.
• The date and time the request was submitted.
• The VER code returned by the test request.

You can select multiple SwitchId(s) by holding down the control key (Ctrl) while
clicking on switch identifiers. Selecting ALL is equivalent to selecting all switches.

Below is an example of the Switch Activity report criteria page.

4-46 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LoopCare Activity Report Generator (LARGE)

LTE Activity The LTE Activity report lists the tests run against a specific LTE(s) for a specified
Report time period. For each test it shows:
• The login identifier of the user who submitted the request.
• The circuit identifier and AID.
• The type of test request submitted.
• The date and time the request was submitted.
• The VER code returned by the test request.

You can select multiple LTE(s) by holding down the control key (Ctrl) while clicking
on LTE identifiers. Selecting ALL is equivalent to selecting all LTEs.

Below is an example of the LTE Activity report criteria page.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-47

System Administration Guide Performance Monitoring
LoopCare Activity Report Generator (LARGE)

Request Types The Request Types report provides data for a specific test request type(s) for a
Report specified time period. For each occurrence of the test request it shows:
• The login identifier of the user who submitted the request.
• The telephone number or circuit identifier.
• The switch or LTE identifier.
• The test request submitted.
• The date and time the request was submitted.
• The VER code returned by the test request.

4-48 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LoopCare Activity Report Generator (LARGE)

You can select multiple test requests by holding down the control key (Ctrl) while
clicking on test request types.

Below is an example of the Request Types report criteria page.

Report Criteria Table 4-3 on page 4-50 describes the report criteria fields.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-49

System Administration Guide Performance Monitoring
LoopCare Activity Report Generator (LARGE)

Table 4-3. LARGE GUI Report Criteria

Report Criteria Field Description

Start Date Specifies the beginning of the time period covered by
the report.
This field is a pull-down list.
End Data Specifies the end date of the time period covered by the
report.
Start Time Specifies the beginning time of the period covered by
the report.
This is an editable field. The format is HH:MM where
HH is the hour and MM is the minute.
End Time Specifies the end time of the period covered by the
report.
This is an editable field. The format is HH:MM where
HH is the hour and MM is the minute.
LoginId(s) The identifier of the user for which testing data is
reported.
This field is a pull-down list. You can select multiple
login identifiers by holding the control key (Ctrl) while
clicking on items in the list. Selecting ALL is equivalent
to selected all the listed login identifiers.

4-50 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LoopCare Activity Report Generator (LARGE)

Report Criteria Field Description

Switchid(s) The identifier of the switch for which testing data is
reported.
This field is a pull-down list. You can select multiple
switch identifiers by holding the control key (Ctrl) while
clicking on items in the list. Selecting ALL is equivalent
to selected all the listed switch identifiers.

LTE(s) The identifier of the LTE for which testing data is

reported.
This field is a pull-down list. You can select multiple LTE
identifiers by holding the control key (Ctrl) while clicking
on items in the list. Selecting ALL is equivalent to
selected all the listed LTE identifiers.

Request Types The type of request type for which testing data is
reported.
This field is a pull-down list. You can select only one
item.

LARGE.STAT There are 12 data items captured for each log entry. They are:
Fields • Switch Id (SWITCHID/LTEID) - Identifies the switch or LTE where the
tested telephone number resides.
• User Id (USID) - Identifies the login name of the user who ran the test.
• LTE Type (LT) - Identifies the type of LTE
• AA
Alcatel ASAM
• AI
Alcatel 7330
• AL
Alcatel Litespan
• C7
Calix C7
• CC

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-51

System Administration Guide Performance Monitoring
LoopCare Activity Report Generator (LARGE)

Ciena CN1000
• GD
Generic
• LA
Lucent AnyMedia
• LS
Lucent Stinger
• MB
mPHASE BBLW
• NI
Nicotra ITBM
• TM
Tollgrade MSAS
• TT
Tollgrade Telaccord
• ZA
Zhone AccessNode
• ZM
Zhone MALC
• Source of Request (SRC) - Identifies where the request came from For a
list of abbreviations, see Source of Test Request: page 4-18.
• Request (RQ) - Identifies the type of test request entered (i.e., FULL,
LOOP, CO, etc.). for a list of abbreviations, see Test Request
Abbreviations: page 4-20.
• VER Code (VC) - Identifies the VER Code reported to the user.
• LOOP Type (LOOP) - The type of loop is identified in this field as well as
the RMU ID (where applicable).
"M" defines metallic loop, in the format "Mxxxxx," where xxxxx is the RMU
Number
"I" defines Integrated DLC
"U" defines Universal DLC.
"D" defines DLC line.
If an RMU is associated with either a UDLC or IDLC, it will have an RMU ID
attached to the "U" or "I." "B" identifies a bPON line.

4-52 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
LoopCare Activity Report Generator (LARGE)

• Directory Number (TN/CIRCUITID) - Identifies the directory number tested

or the circuit access information.
• Office Equipment (OE/AID) - Identifies the subscriber Office Equipment or
Access Identifier.
• Date (DATE) - The date of the transaction (mmdd for North American
format and ddmm for international format).
• Time (TIME) - The time of day the transaction started (hhmmss).
• Holding Time in Seconds (SEC) - The holding time of the initial test is given
in seconds.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-53

System Administration Guide Performance Monitoring
Testing Activity Report Enabler (TARE)

Testing Activity Report Enabler (TARE)

Overview The Testing Activity Report Enabler (TARE) feature is a subset of the TAF feature
that allows you to store information about all testing activity in the LoopCare
Oracle database, with one record for each test. Only initial entry data for long-term
accesses is logged. The Oracle database information is in addition to the TAF
ASCII files described in the previous section.

The information collected by TARE can be used to identify defective ports, trunks,
RMUs, etc., and to help solve sizing and blockage problems by determining the
source and amount of test traffic that passes through each test head.

Users can create SQL scripts to gather particular data that they might need to
solve a problem. For example, a sort on a specific test head could be performed
to determine if a persistent blockage condition is caused by heavier than expected
test requests.

Managing the Use the OA&M to manage the behavior of the TARE feature. The TAF Requests
TARE Feature screen allows you to determine whether TARE report files are generated and how
they are handled. See the Operations, Administration and Maintenance (OA&M)
Guide.

TARE Results Table The TARE records are stored in the TARE Results Table of the LoopCare Oracle
database. The following table lists the columns in the TARE Results Table.

NOTE:
All columns may not be populated in each record.

4-54 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Report Enabler (TARE)

Table 4-4. Columns in the TARE Results Table

Field Description
Source of Request A numeric pointer to the tafSource table, identifying the
source of the request (and the abbreviation), for example:
•TV TV
•TEST TST
•PREDICTOR PRE
•PST PST
•CRAFT ACCESS SYSTEM CAS
•TE/TR TE
•MSCR MSC
•DISP DIS
•RETEST RET
•TRFULL TRF
•TRCALLED TRC
•ADSL BATCH XDL
Machine ID The Logical Machine ID. In multiple-machine
environments, this column indicates the machine on which
the test executed.
In single-machine environments, the value of this column
is always the same.
Employee Code User ID of the user who initiated the request. This is a
pointer to act_tv_tester
TN The complete Telephone Number tested:
• NPA/NXX/Digits
or
• City Code/Exchange/Line
Extra Digits The Terminal Number or Hunt Group Number
Circuit ID The circuit identification number is a single unique
identifier that points to the access information of a line.
This is used in place of a telephone number.
Request A numeric pointer to the tafRequests table, identifying the
type of test request entered (FULL, LOOP, CO, etc.).

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-55

System Administration Guide Performance Monitoring
Testing Activity Report Enabler (TARE)

Table 4-4. Columns in the TARE Results Table

Field Description
VER Code Identifies the VER Code returned by the test.
Error number A pointer to the ACT_ERRNUM table, which contains
internal error numbers associated with E and F VER
Codes.
DCN ID A two-character identifier of the Data Communications
network (DCN) used to communicate with the Central
Office test units.
CO Test Head ID The identifier of the Central Office test unit.
CO Test Head Type A single-character pointer to the ACT_THTYPE table,
which indicates the type of the Central Office test unit (for
example, LTS, DCTU, EMU, Harris 105, etc.)
RMU DCN ID This column is used when the RMU is being controlled by
a different CO test head.
RMU Test Head ID This column is used when the RMU is being controlled by
a different CO test head.
Remote Test Head The RMU or RMU-S ID.
ID
Port Used Identifies the port or trunk (LTF) or trunk group (LTS) ID of
the Central Office test head.. A 2-difgit value. For MDF
trunks accessed via a HUB XMU this field contains the slot
number of the XMU. For MDF trunks accessed via a HUB
TMU, this field contains the odd TAP number.
Loop Type A pointer to the TAFLOOPTYPE table, which identifies the
type of loop as well as the RMU ID (where applicable). “M”
defines metallic loop, “I” defines Integrated DLC and “U”
defines Universal DLC. If an RMU is associated with either
a UDLC or IDLC, it will have a 3-digit RMU ID attached to
the “U” or “I.”
Cable ID The identifier of the Cable being tested.
Pair Pair on the cable being tested.
Wire Center ID The identifier of the Wire Center.
EXK The Exchange Key for the switch.
Switch ID Pointer to the ACT_SWITCH table, which identifies the
switch.
OE The Office Equipment number associated with the line.
LRN Used The Location Routing Number for the switch.

4-56 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Testing Activity Report Enabler (TARE)

Table 4-4. Columns in the TARE Results Table

Field Description
LTE ID A numeric pointer to the DSLAMS table, which identifies
the Loop Terminating Equipment (LTE), typically the CLEI
(Common Language Equipment Identifier) code.
Node name The name of an Alcatel Litespan node at which the
customer's loop is terminated.
Rack The number of an Alcatel ASAM 7300 rack at which the
customer's loop is terminated.
Bank The number of an Alcatel Litespan bank at which the
customer's loop is terminated.
Shelf The number of the shelf on the LTE at which the
customer's loop is terminated.
This column is also used for the Unit ID of an ADTRAN
3000.
Slot The number of the slot on the shelf of the LTE at which the
customer's loop is terminated.
For a Hatteras HN4000, this is the switch identifier.
Line The number of the port in the slot of the LTE at which the
customer's loop is terminated.
For an ADC 528r, this is the port identifier.
For an ADTRAN 3000, this is the port identifier.
For the AFC AccessMax, this is the circuit.
For a Turnstone CX100, this is the pair.
For an CN 1000, this is the port identifier.
For a BBLW, this is the port identifier.
For a Hatteras HN4000, this is the 2bPME (2Base
Physical Medium Entity) identifier.
Channel The number of the channel of the LTE at which the
customer's loop is terminated.
Chassis The ADC 528r Chassis identifier.
IAD Integrated access Device. A CPE that supports voice and
data.
DiGroup The ADTRAN 1500 DiGroup identifier, or the Group ID of
an ADTRAN 3000.
Start time The time at which the test was initiated.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-57

System Administration Guide Performance Monitoring
Testing Activity Report Enabler (TARE)

Table 4-4. Columns in the TARE Results Table

Field Description
Test Duration The duration of the test in seconds.
MDF MDF wire center (first 3 digits) and trunk ID (remaining
digits)

Storage The feature can store records for up to 1 million records. The total required
Requirements storage is approximately 585 MB.

The Loop Care Oracle administrator is responsible for creating the space for the
TARE tables.

Retention Interval The retention interval for TARE records in the database is in increments of 1
week, with a default value of 1 week. This allows the retention of up to 150,000
records per day. The retention interval can be set in multiples of 1 week by the
OA&M administrator. The maximum retention period is 104 weeks (2 years). See
the Operations, Administration and Maintenance (OA&M) Guide For Automated
Data Element Form (ADEF) Administrators.

NOTE:
Changing the retention period does not increase the database space.
Customers who generate fewer than 150,000 daily records can set longer
retention periods. Customers with larger numbers of daily records must set
shorter retention periods and archive records more often.

Active-Active In an active-active environment, the testing activity records are stored on the
Environments master machine only. If the master machine is down, results are not stored.

Required The LoopCare Oracle administrator is responsible for creating a temporary area,
Administrative from which purged records can be offloaded to other media for archiving. The
Functions administrator then frees the temporary area.

Activation See Activation of the TARE Oracle Database Feature: page 4-59.

4-58 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Activation of the TARE Oracle Database Feature

Activation of the TARE Oracle Database

Feature

Introduction In order to use the TARE Oracle database feature, you must perform the following
procedures.

NOTE:
To activate the database, LoopCare Release 1.5 or greater must be
installed.

Process Activating the TARE feature involves the following phases:

For this Phase See Page

Main Installation page 4-59
Activation on Remote page 4-60
Machines
Activate the TAF page 4-62
Cleanup Utility
Create a cron File to page 4-62
Schedule the Cleanup
Utility

Main Installation In a multi-machine environment, you must perform this procedure on the main
machine.
1. Login to the main machine as oracle.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-59

System Administration Guide Performance Monitoring
Activation of the TARE Oracle Database Feature

2. Add Unix commands to /mlt/config/oraclevars to set the following

environmental variables.:

Add to /mlt/config/
Variable oraclevars Notes
TAF_TBL TAF_TBL=[directory]; [directory] is a directory path name.
export TAF_TBL This directory must have at least
585 MB of free space.
TAF_INX TAF_INX=$TAF_TBL;
export TAF_INX
TAF_TMP TAF_TMP=[directory]; [directory] is a directory path name.
export TAF_TMP This directory must have at least
400 MB of free space.
If BMDB is already activated set
TAF_TMP to $TAF_TBL.
TAF_MASTER TAF_MASTER=$ORA TAF_MASTER must point to
CLE_SID;export $ORACLE_SID.
TAF_MASTER

3. Type the following commands:

. /mlt/config/oraclevars
cd /mlt/install/conv
./activateTAF -s manager
4. Type the following command:
su - mlt
LoopCare prompts you for a password.
5. Enter the password for mlt.
6. Enter the following commands:
. /mlt/config/oraclevars
cd /mlt/install/conv
./upschema -s manager

Activation on In a multi-machine environment, replication is not needed. Instead, the database

Remote Machines lives on the master machine, and the remote machine accesses the data via
remote procedure calls.
1. You must make sure the machines can talk to each other over sqlnet. If you
are already using replication between the two machines, everything should
be fine.

4-60 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Activation of the TARE Oracle Database Feature

If not, have your DBA configure the following files appropriately:

$ORACLE_HOME/network/admin/tnsnames.ora
$ORACLE_HOME/network/admin/listener.ora
and make sure the Oracle listener process is running on both machines.
2. Perform the following SQL steps on the remote machine.
3. As mlt, export and set TAF_MASTER to the ORACLE_SID value of the
master machine.
Example
export TAF_MASTER=$ORACLE_SID
4. Log into SQLPLUS as taf.
5. Type the following commands:
. /mlt/config/oraclevars
sqlplus taf/taf
6. At the SQL prompt, type the following command:
DROP PUBLIC SYNONYM pk_taf;
7. Type the following command:
CREATE PUBLIC DATABASE LINK <linkname> CONNECT TO
<login> IDENTIFIED BY <password> USING
'<service_name>';

NOTE:
Step 7 is not required if you have the BMDB feature activated. If the BMDB
feature is activated, and you attempt step 7, the step will fail.

8. Type the following command:

CREATE PUBLIC SYNONYM pk_taf FOR taf.pk_taf@
<linkname>;
exit
where:
<linkname> is the TAF_MASTER name
<login> is the TAF owner name on the master machine
<password> is the TAF password on the master machine
<service_name> is the TAF_MASTER name

NOTE:
The <service_name> must be the same as the <linkname>, except
that it is preceded and followed by single quotes.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-61

System Administration Guide Performance Monitoring
Activation of the TARE Oracle Database Feature

Installing the TAF The TAF Cleanup Utility archives expired TAF data into flat files and provides
Cleanup Utility room in the database for the new TAF data.

The Cleanup Utility uses Oracle to write data to files. In order to do this, a special
entry must be added to the init.ora file.

Modify init.ora file.

1. Log in as oracle.
2. Type the following command:
sqlplus /nolog
The SQL> prompt is displayed.
3. Type the following commands:
connect / as sysdba
shutdown immediate
exit
The UNIX prompt is displayed.
4. Type the following command:
sqlplus /nolog
The SQL> prompt is displayed.
5. Type the following commands:
connect / as sysdba
startup
exit
6. Run oam and bring up the Features->TAF->OPTIONS->CONFIGURE TAF
OPTIONS form.
7. Check the box next to Turn Testing Activity Records On.
8. Save the form, quit, then exit OAM. See the OAM Guide for more
information on using data entry forms.

Create a cron Job Setup a cron job to run TAF Database Cleanup Utility every day early in the
morning.

4-62 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
Activation of the TARE Oracle Database Feature

NOTE:
This is mandatory. Failure to run this cron job will result in the system
running out of database space and being unable to store results in the
Oracle database.

This is the command that should be placed in the cron file:

/mlt/install/taf_cleanup.sh -s <oracle system password>
-m <mail list>
Where <mail list> is a list of e-mail addresses enclosed in double
quotes with each e-mail address delimited by a space. These are the
eMails of persons to be notified of any errors produced from TAF Cleanup
Utility.

The cleanup utility will append data to two files:

• /mlt/reports/TAFCLEANUP.log
This file contains information about the days and times the utility ran.
• /mlt/reports/TAF.ARCHIVE
This file contains any records removed from the database. It is the
administrator’s responsibility to backup this file to another media and then
remove the file from the server.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-63

System Administration Guide Performance Monitoring
Customized Report Service

Customized Report Service

Overview LoopCare provides a service designing customized reports that extract data
regarding testing activity from the LoopCare Oracle database.

The reports are generated with the Crystal Reports application. The Crystal
Enterprise application allows the user to schedule the running and storage of
reports on a dedicated PC or other machine and make them viewable on a web
site by users with appropriate password permissions.

For more information about this service, consult with your LoopCare Sales
Representative.

4-64 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
VER 99 Improvement Feature

VER 99 Improvement Feature

Overview The VER 99 improvement feature reduces the number of VER 99 codes that are
generated. (VER code condition 99 is a catch-all for cases where the system
wants to return more than one VER code.) This feature will select the hardest of
the multiple faults and provide the corresponding VER code as defined in the
Priority Table.

NOTE:
A feature file update is necessary before this feature can be used.

Priority Table A priority table is used to specify which VER code to return when multiple faults
are found.

The first column is called the Priority Code, and it is this code that will be returned
if two or more VER Codes in the adjacent row are set. These other codes are
called combo codes as the generation of any inclusive combination of the Priority
Code and corresponding combo codes will cause LoopCare to return the code
specified in the Priority Code column. Should a non-combo VER code be among
the combo VER codes, a VER 99 will be returned.

Changing The Priority Codes may be added, deleted or their combo codes may be modified. Just
Priority Table edit the Priority Code and Combo Codes that you want LoopCare to use instead
of the codes currently listed.

The Priority Table is located in the /mlt/config/ver99 file. If this file does not
exist, it can be created using a copy of the default Priority Table, which is provided
with each release and is located in the /mlt/config/ver99.def file. For
further information, refer to the section, Updating the Priority Table: page 2-6.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-65

System Administration Guide Performance Monitoring
VER 99 Improvement Feature

NOTE:
Priority Table The VER codes in the first column are the priority codes, all following VER
codes are combo codes.

Reporting Each time multiple faults are detected, information about the faults is logged to the
file /mlt/reports/VER99.STAT. Data is displayed in the following format:

4-66 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
VER 99 Improvement Feature

Example

Telephone
Date Time Number Resulting VER Code Other VER Codes

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-67

System Administration Guide Performance Monitoring
The OE.STAT Report

The OE.STAT Report

Introduction The OE.STAT report is generated if the Measurement of OE Retrieval Response

Time feature is enabled. (See the -o option of the tip module in MGRP.gdf for
enabling this feature.)

When enabled, this feature logs every OE Retrieval request by TN and the
response time in seconds. This allows system administrators to determine which
switches have slow response times, and whether the slow performance is caused
by the switch or by a testhead.

Report Location The OE.STAT report is located in the /mlt/reports directory. You must add
the -o option to the tip module of the MGRP.gdf for this report to be generated.

Field Descriptions The OE.STAT report contains the following information:

Table 4-5.

Column Description
TN The TN for which OE Retrieval information is requested.
SWID The ID of the switch being queried for OE information.
OE The OE ID.
SWVC The VER Code generated by the OE Retrieval request.
This may not be the VER Code that is displayed to the
user since LoopCare may make further attempts to
retrieve OE information, or LoopCare will run a test and
return the Ver Code of the test.
Date The date on which the OE Retrieval request was made.
Time The time at which the OE Retrieval request was made.
Resp(Sec) The total response time for the request in seconds, the
time the request waits on the queue plus the time for the
switch to process the request.
SW(Sec) The the time, in seconds, for the switch to process the
request.

4-68 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Performance Monitoring System Administration Guide
The OE.STAT Report

Example The following is an example of the OE.STAT report.

In this example, there are several instances of LoopCare requesting OE

Information from multiple switches. Failure to find the TN on the Primary Switch
causes LoopCare to query the secondary switches.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 4-69

System Administration Guide Performance Monitoring
CPU Utilization and Related Statistics

CPU Utilization and Related Statistics

Overview Bottlenecks can occur in the system when certain thresholds are reached.
• process run queue is more than 2 times the number of CPUs and/or the
percentage of CPU utilization is greater than 75%
• percentage of CPU system time is greater than .25 of user/application
percentage of CPU utilization and the percentage of CPU utilization is
greater than 85%

Use the top command to obtain CPU utilization statistics and the number of CPUs.
Use the vmstat command to determine run queue statistics, system CPU system
time and application CPU time.

4-70 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance 5

Contents

• Overview 5-2
• Buffer and Module Tracing 5-3
• Save System Information for Diagnosing Hangs 5-5
• Trouble Clearing Strategy 5-6
• Hourly Reports 5-10
• Sizing a Standalone LTS 5-16
• Test Trunk Troubleshooting 5-19

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-1

System Administration Guide Maintenance
Overview

Overview

Introduction This chapter provides guidelines for using LoopCare tracing to diagnose problem
system. It also contains general information on the trouble ticketing process, and
has a test trunk trouble locator.

5-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Buffer and Module Tracing

Buffer and Module Tracing

Overview There are two types of tracing: module tracing and buffer tracing. Each software
module in LoopCare is capable of generating tracing messages that help
LoopCare developers pinpoint problems in the code. Tracing is only used when a
LoopCare Technical Support person has asked for it, in order to find a tricky bug.

NOTE:
Do not turn on tracing unless requested. Tracing slows the system and
uses filespace.

There are four levels of module tracing:

• 0 (tracing off), and
• 1-3, increasing in the degree of tracing from one to three.

Each module has each tracing statement labeled as to its importance using this 1-
3 scale. The tracing levels are incremental; level two will cause level one and level
two tracing messages to be output, and level three causes level one, two, and
three messages to be output.

Controlling Tracing There are three ways to control tracing.

Behavior • Edit the MLT.env file
• Edit the gdf file for the Group
• Turn on tracing through UIP

Editing MLT.env The first method is to edit the MLT.env file (in /base/config directory) and change
File the MLTTRACE variable. This method will turn on tracing for ALL modules. It is
used mostly by the development group.

NOTE:
Do not to use this method in a Data Center Environment because within
one-half hour, the disk will fill completely, and the LoopCare application will
go down.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-3

System Administration Guide Maintenance
Buffer and Module Tracing

Editing the gdf file The second method is to edit the gdf file for a particular group. The gdf file is a list
for the Group of modules to be brought up in the group, along with relevant parameters for each
module. The gdf file may be edited, and a parameter in the form of -
trace,<trace_level> may be inserted. This tells LoopCare to keep this module in
tracing mode each time the group is brought up. This may be used by LoopCare
Technical Support to track down a highly intermittent problem.

Use the UIP Options The third and most recommended method is to turn on tracing through UIP. UIP
prompts you for the module name, then the level of tracing. The module tracing
may be turned on and off while the groups are up; the change takes effect
immediately. You can change the tracing status of any module, even if the tracing
was initiated via methods One or Two.

Tracing Output When a module goes into tracing mode, it creates a file <module>.trc (e.g. tip.trc)
in the directory specified by the environmental variable $MLT_TRC (usually /mlt/
trace). If the file is there from a previous trace, the new data is appended to the
old file.

NOTE:
This directory should be cleared occasionally to free up disk space. The
files can be removed while the group is up.

Buffer Tracing Buffer tracing causes certain information regarding the test hardware buffers to be
saved to disk for later inspection. Buffer tracing is not effective in all modules, only
those that communicate with test hardware. As in module tracing, buffer tracing
should be used only when instructed by support personnel, as some modules will
create data with every test made. In a live system this could be disastrous.

The buffer tracing feature may be turned on via the UIP, or with the -& option used
in the gdf file, similar to the module tracing. The output files are only read by
Support personnel at this time.

5-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Save System Information for Diagnosing Hangs

Save System Information for Diagnosing

Hangs

Overview The hang.mlt program saves system information in the event of a hang condition
on the LoopCare system. The information is used to diagnose the cause of the
hang. The following files are generated by hang.mlt and stored under /mlt/exec:
• msched.<date>: This file records the activity of the SAM transaction
scheduler.
• comm.<date>: This file records the status of the Communications ports on
a HP Front End, where <date> is month, day, hour, and minute.

The program also executes the program hang.base described in the Guide to
Base (col.451). The hang.base program saves information about shared memory,
inter--process message queues and process status in the following files under /
base/exec:
• shmem.<date>
• ipms.<date>
• psel.<date>
• trst.<date>
• ports.<date>
• cons.<date>

where <date> is month, day, hour, and minute.

All files generated by hang.mlt should be saved for analysis.

NOTE:
If you wish to execute hang.mlt from the BASE environment, proceed as
shown below:

1. Log in as a BASE user.

2. Enter the command with the full path name:
/mlt/ubin/hang.mlt

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-5

System Administration Guide Maintenance
Trouble Clearing Strategy

Trouble Clearing Strategy

The Location Each MC should have a Location Controller to serve as the point of contact with
Controller Facilities Management. The Location Controller should be an LMOS/LoopCare
expert who can answer any questions that might arise, as well as isolate system
problems to report to the FacMan. They should be informed of all system changes
or maintenance that affect MC operations. The Location Controllers knowledge of
system maintenance will directly affect the relationship between the FacMan and
the MC.

The Location Controller requires the following:

1. The Local Administration and Maintenance (LAM) User Guide, which
describes the LoopCare system and LAM mask.
2. A list of maintenance contacts in case a problem arises.
3. A list of questions to be asked when a trouble is reported.
4. A LoopCare MC Trouble Log which tracks all reported and cleared
troubles.
5. A list of maintenance priorities. This information gives the Location
Controller an idea of how quickly a particular problem may be cleared.

Trouble Tracking Taking an MC Trouble Report

When taking a trouble from a Location Controller, the FacMan should fill out a
LoopCare MC Trouble Report. This report lists the questions to ask on the left and
provides an area to record the answers on the right. Because the Location
Controller also has this form, they should be ready to provide all necessary
information when the call is made.

Cross-checking Outstanding LoopCare Trouble Tickets

Whether a problem is discovered by routine maintenance, automatic system

reports, or MC Trouble Reports, the FacMan must verify the problem by following
the procedures discussed earlier in this guide; The FacMan should also verify that
the problem did not exist previously by comparing the new trouble description with
outstanding LoopCare Trouble Tickets. The LoopCare Trouble Ticket provides the
FacMan with a place to describe troubles and track actions made in association
with these troubles. If the new trouble matches an outstanding ticket, the FacMan
should not fill out another ticket. If the trouble was taken from the MC, the
Location Controller should be told that the trouble is in the process of being
corrected.

5-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Trouble Clearing Strategy

Initiating a Trouble Ticket

LoopCare trouble tickets must be filled out as completely and accurately as

possible. Each is divided into pre- and post-dispatch sections. All information
gained during trouble report and isolation should be entered in the pre-dispatch
section or attached to the ticket. It is important that this information be relayed to
the organization responsible for clearing the trouble. The FacMan should be
especially careful in specifying the exact component that failed. Failed LTS
devices should be listed by device id (BYD1, for example). Entries in the OTHER
IMPORTANT INFORMATION area should include recent sanity reports, trouble
counts, failure rates and trunk measurements. This is also the place to record the
results discovered by running LoopCare requests using the bad equipment.

Making Priority Decisions

Plans should be developed and documented by the FacMan for handling

LoopCare system failures. A decision must be made concerning which failure has
priority and which affected users should receive priority treatment.

Consider, as an example, the possibility that two LTSs are "down" simultaneously.
The FacMan must determine the needs of the individual users and establish a
restoration priority. A method of determining the needs of the individual affected
users would be the retrieval of RJR Reports to determine the number of customer
troubles pending screen, pending test and those that would require pre- and post-
dispatch tests. Even more important with LoopCare is the number of repair
personnel already dispatched and the types of problems they are working on. The
evaluation process may take several minutes but it is absolutely necessary for the
FacMan's decisions to be based on the available facts.

This same decision making process should be used by the FacMan in determining
whether a failing apparatus should be removed from service and repaired after
hours or repaired during the normal business day. Repair during the day will make
LoopCare unavailable to users.

It is recommended that the FacMan and the appropriate level of higher

management conduct meetings with the responsible Network maintenance,
Comptroller and Data repair group personnel, to address the corrective
maintenance procedures and identify the methods for referral of LoopCare
troubles to the responsible organization. Expected clearing times and restoration
priorities must be defined for all groups.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-7

System Administration Guide Maintenance
Trouble Clearing Strategy

The suggested maintenance priorities for failures are as follows:

PRIORITY#1 Service affecting trouble; an immediate response is

required. Two hour clearing time applies during normal
business hours and 4 hours clearing time outside of
normal business hours.
PRIORITY#2 Service affecting problem detected which requires an
immediate response from Network Maintenance but
does not require the removal of the equipment from
service. Two hour clearing time applies during normal
business hours and 4 hours clearing time outside of
normal business hours.
PRIORITY#3 Non-service affecting trouble that requires the removal
of the equipment from service outside of normal
business hours. Expected clearing time is 24 hours from
the time it is referred to Network Maintenance.
PRIORITY#4 Non-service affecting trouble that does not require the
removal of the equipment from service and be worked
on during the day. Expected clearing time is 8 working
hours from the time it is referred to Network
Maintenance.

It is important for each work group to understand why LoopCare requires such
high priority. It is also important that the responsibilities of the FacMan be
identified and various work groups be informed about the sectionalization
procedures performed by the Administrator before troubles are referred to them.

Several meetings may be required before joint agreements are made. The
objective is to establish joint clearing time agreements that are consistent with all
work groups. Division or General level interdepartmental agreement should be
obtained.

Completing a Trouble Ticket

The post-dispatch section of the trouble ticket can be filled out as soon as the
trouble is cleared by the responsible organization. The ticket should be closed
only after all MCs affected by the trouble have been notified. Note that one of the
functions of this ticket is to assign responsibility for reporting, receiving, clearing,
and closing out a trouble. Proper entry of this information ensures that the correct
people are credited for action taken.

The last area on the ticket, the ADDITIONAL INFORMATION area, should be
used to record any information that the clearing organization makes to pass along.

5-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Trouble Clearing Strategy

This could include reports that the trouble found did not match the description
entered in the pre-dispatch section of the ticket.

Logging a Trouble

Once a trouble is closed it should be entered into the LoopCare Trouble Log. This
log allows the FacMan to generate reports that show recurrent problems or trends
in specific equipment. These reports are discussed in detail in the System
Analysis section of the guide. The log also provides an audit trail of all work done
on the LoopCare system and by whom.

Note that the log refers to LTS and DCN devices rather than the entire LTS or
DCN. This is also true of the out-of-service entry. If a failure leads to the failure of
an entire LTS, this should be noted in the Comments area. Similarly, if a DCN
failure leads to the failure of the entire DCN or a group of LTSs (a bad level 3
board, for example), this also should be noted in the Comments section.

Reporting Design Problems to LoopCare Technical Support

The LoopCare Technical Support team has implemented the Remedy Service
Request Tracking System to better manage troubles that are encountered in using
LoopCare operations systems. Remedy has the following features:
1. Provides for the creation and maintenance of an assistance requests
reporting data base.
2. Allows users to enter any type of problem directly into that assistance
requests data base.
3. Allows users to access the most current list of statused assistance
requests reports.
4. Allows users to generate overall status reports that summarize all
assistance requests in the data base.
5. Allows users to access news items of general interest for each individual
project.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-9

System Administration Guide Maintenance
Hourly Reports

Hourly Reports

Overview The MCRREPORT, MRRREPORT, and DZREPORT together provide the main
reporting facility for the CMU, EMU, DMU-C, DMU-R, RMU, and RMU-S
testheads. These reports can be combined and updated hourly by setting up the
snapshot utility.

Enabling Hourly To enable this hourly report feature which sends reports on possible testhead
Reports problems to the FacMan printer, a statement must be added to the /usr/spool/
cron/crontabs file that will trigger the shell /mlt/ubin/snap.sh and create
the reports.To generate the report on an hourly basis, from the "root" login edit
the /usr/spool/cron/crontabs file and include the following entry:
1 * * * * /mlt/ubin/snap.sh

This entry will force cron to invoke the snap.sh shell and execute the snapshot
report generator process hourly. snap.sh is a tool which generates a report
which is the concatenated information from /mlt/reports/MCRREPORT, /mlt/
reports/DZREPORT and /mlt/reports/MRRREPORT. snap.sh can be set in cron to
be generated every hour. This module sorts the information in these three reports
and eliminates duplicate messages for the same testhead, showing only the last
occurance of the message for that testhead. The module /mlt/ubin/snapshot
creates the initial (and subsequent hourly) reports and sends the chronological
output to the printer. Also the output is sent to /mlt/reports/dataout. The size of this
file should be checked periodically and cleaned up when necessary.

Each hour new information will be sent which lists any additional potential problem
situations that have occurred since the previous report was generated. This
information is read from three files under the /mlt/reports directory called
DZREPORT, MCRREPORT and MRRREPORT. These files may be checked
between hourly report generation for the latest status changes.

Sample A sample report is provided below. A header row identifies the columns.
DZREPORT
DATE TIME EMU/SEQ IP/TEL PORT DEVICE LAST EV
Report
1207,16:40 1025 999.999.999.999 6005 ttyDK: ACCESS SERVER FAILURE

1209,08:50 921 10.2.12.3 6014 ttyDK: FAILED TO GET PASSWORD PROMPT

1209,10:49 903 10.2.12.5 0007 ttyDK: SOCKET CONNECTION REFUSED

1209,12:03 1025 10.2.12.5 6002 ttyDK: PASSWORD NOT ACKNOWLEDGED

5-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Hourly Reports

The fields are:

• DATE - in MMDD format,
• TIME - in HH:MM format
• EMU/SEQ - the Central Office testhead ID or Sequence Number of the
RMU-S
• IP Addr - the IP Address of the EMU
• Port - The Master Service ID of the Access Server associated with the
EMU
• Device - The device associated with the RMU.
• Last Ev(ent) - The status of the most recent event associated with the EMU

DZREPORT Error The following are error messages that appear on the DZREPORT.
Messages • ACCESS SERVER FAILURE
• DKTRAM TERMINATED PROCESS
• FAILED TO GET PASSWORD PROMPT
• FAILED TO LOGIN
• LINK RECONNECTION FAILED
• LOST CARRIER, RECONNECTED
• MODEM NOT RECOGNISED
• MODEMFAILED TO CONNECT
• PASSWORD NOT ACKNOWLEDGED
• SOCKET CONNECTION REFUSED
• TOO MANY NAKS, LINK RECONNECTED

Sample DATE TIME DCN EMU TRUNK LAST EVENT

MCRREPORT 1011,09:44 001 803 3 EMU MU TROUBLE RATE OVERFLOW
Report
1011,09:44 001 803 3 EMU DIAGNOSTICS MARGINAL

1011,09:44 001 803 3 EMU ACCESS RESPONSE - ACC FAILED

1011,09:59 001 803 3 EMU ACCESS RESPONSE - ACC FAILED

1011,10:00 001 803 3 EMU DIAGNOSTICS MARGINAL

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-11

System Administration Guide Maintenance
Hourly Reports

1011,10:00 001 803 3 EMU MU TROUBLE RATE OVERFLOW

1011,10:07 001 803 1 EMU TAU_1 TROUBLE RATE OVERFLOW

1011,10:11 001 803 3 EMU MU TROUBLE RATE OVERFLOW

1011,10:11 001 803 3 EMU TAU_1 TROUBLE RATE OVERFLOW

1011,10:33 001 803 1 EMU MU TROUBLE RATE OVERFLOW

1011,10:33 001 803 1 EMU TAU_1 TROUBLE RATE OVERFLOW

1011,10:34 001 803 3 EMU DIAGNOSTICS MARGINAL

1011,10:46 001 803 3 EMU ACCESS RESPONSE - ACC FAILED

1011,13:59 001 892 3 EMU TAU_1 TROUBLE RATE OVERFLOW

1011,15:24 001 803 3 EMU DIAGNOSTICS MARGINAL

1011,15:24 001 803 3 EMU ACCESS RESPONSE - ACC FAILED

1015,11:00 001 892 2 EMU TAU_1 TROUBLE RATE OVERFLOW

DATE TIME DCN EMU TRUNK LAST EVENT

1016,08:50 001 803 3 EMU DATA LINK CONNECTION FAILED - NO LOGIN

DATE TIME DCN EMU TRUNK LAST EVENT

1017,13:19 001 1492 2 EMU DATA LINK CONNECTION FAILED

Report Analysis The following messages are reported on the MCRREPORT.

• ALARM CONTACTS CLOSED
• EMU ACC_CKT AUTO REMOVED FROM SERVICE
• EMU ACC_CKT TROUBLE RATE OVERFLOW
• EMU ACCESS RESPONSE - ACC FAILED
• EMU ALARM CONTACTS CLOSED
• EMU AOOS 8 CONNECTION FAILURES
• EMU AOOS CONNECTION THRESH OVERFLOW
• EMU AUTO REMOVED FROM SERVICE
• EMU AUTO REMOVED FROM SERVICE
• EMU CALIBRATION FAILED
• EMU CALIBRATION MARGINAL

5-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Hourly Reports

• EMU DATA LINK CONNECTION FAILED

• EMU DATA LINK CONNECTION FAILED - NO LOGIN
• EMU DIAGNOSTICS FAILED
• EMU DIAGNOSTICS FAILED - ALT TEST OK
• EMU DIAGNOSTICS MARGINAL
• EMU DP_DLR AUTO REMOVED FROM SERVICE
• EMU DP_DLR TROUBLE RATE OVERFLOW
• EMU DTMF_DLR AUTO REMOVED FROM SERVICE
• EMU DTMF_DLR TROUBLE RATE OVERFLOW
• EMU HAZ_POT TROUBLE RATE OVERFLOW
• EMU MEMORY LOST - RELOAD
• EMU MEMORY LOST - USE EMUADMIN TO DLOAD
• EMU MF_DLR AUTO REMOVED FROM SERVICE
• EMU MF_DLR TROUBLE RATE OVERFLOW
• EMU MTAU AUTO REMOVED FROM SERVICE
• EMU MTAU TROUBLE RATE OVERFLOW
• EMU MU AUTO REMOVED FROM SERVICEEMU TCU AUTO REMOVED
FROM SERVICE
• EMU MU TROUBLE RATE OVERFLOWEMU TCU TROUBLE RATE
OVERFLOW
• EMU NOT EQUIPPED
• EMU OUT OF SERVICE - ACC FAILED"
• EMU PGTC_COIN TROUBLE RATE OVERFLOW
• EMU SLEEVE CONTROL FAILURE
• EMU TALK_CKT AUTO REMOVED FROM SERVICEEMU HAZ_POT
AUTO REMOVED FROM SERVICEEMU PGTC_COIN AUTO REMOVED
FROM SERVICE
• EMU TALK_CKT TROUBLE RATE OVERFLOW
• EMU TAU_1 AUTO REMOVED FROM SERVICE
• EMU TAU_1 TROUBLE RATE OVERFLOW
• EMU TAU_2 AUTO REMOVED FROM SERVICE
• EMU TAU_2 TROUBLE RATE OVERFLOW
• EMU TAU_3 AUTO REMOVED FROM SERVICE

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-13

System Administration Guide Maintenance
Hourly Reports

• EMU TAU_3 TROUBLE RATE OVERFLOW

• EMU TAU_4 AUTO REMOVED FROM SERVICE
• EMU TAU_4 TROUBLE RATE OVERFLOW
• EMU TAU_6 AUTO REMOVED FROM SERVICE
• EMU TAU_6 TROUBLE RATE OVERFLOW
• EMU TROUBLE RATE OVERFLOW
• ERROR READING EMU/RMU DATA BASE
• LINK TO DZMASTER NOT AVAILABLE
• NO VIRTUAL CHAN TO DZMASTER
• TEST HEAD UNABLE TO RESOLVE THE MESSAGE
• WIDEBAND UNIT AUTO REMOVED FROM SERVICE
• WIDEBAND UNIT TROUBLE RATE OVERFLOW
• WRITE TO DZMASTER FAILED

Sample 1203,12:45 4 000 0 3 0 RMU DIAGNOSTICS MARGINAL

MRRREPORT
1203,12:45 4 000 0 3 0 RMU CALIBRATION MARGINAL
Report
1207,16:34 4 000 0 6 0 RMU ACCESS RESPONSE - ACC FAILED

1209,09:45 4 000 0 48 0 RMU ACCESS RESPONSE - ACC FAILED

1209,11:43 4 000 0 48 0 RMU DIAGNOSTICS MARGINAL

1209,11:43 4 000 0 48 0 RMU ACCESS RESPONSE - ACC FAILED

1209,12:03 4 000 0 3 0 RMU DIAGNOSTICS MARGINAL

1209,12:03 4 000 0 3 0 RMU CALIBRATION MARGINAL

MRRREPORT The following messages are reported on the MRRREPORT.

Messages • ALARM CONTACTS CLOSED
• ERROR READING EMU/RMU DATA BASE
• LINK TO DZMASTER NOT AVAILABLE
• NO MORE RMU ACCESSES ALLOWED
• NO RMU ACCESS - NO TESTING ALLOWED

5-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Hourly Reports

• NO VIRTUAL CHAN TO DZMASTER

• REQUESTED RMU ALREADY ACCESSED
• RMU ACCESS RESPONSE - ACC FAILED
• RMU AUTO OUT OF SERVICE
• RMU AUTO REMOVED FROM SERVICE
• RMU CALIBRATION FAILED
• RMU COULD NOT DROP USE DZADMIN TO CLEAR PORT
• RMU DIAGNOSTICS FAILED
• RMU DIAGNOSTICS MARGINALRMU CALIBRATION MARGINAL
• RMU MEMORY LOST - RELOAD
• RMU SPURIOUS DROP
• TEST HEAD UNABLE TO RESOLVE THE MESSAGE
• UNRECOGNIZED OR NON-STANDARD RMU
• WIDEBAND UNIT AUTO REMOVED FROM SERVICE
• WIDEBAND UNIT TROUBLE RATE OVERFLOW
• WRITE TO DZMASTER FAILED

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-15

System Administration Guide Maintenance
Sizing a Standalone LTS

Sizing a Standalone LTS

Overview This section describes the basic sizing guidelines for a stand-alone LTS.Initial
Sizing of a New LTS A new LTS installation should be sized according to the total
number of lines that the LTS will serve. For a LTS which will test more than one
switch, this number will be the sum of the lines served by each switch. The
recommended number of each piece of equipment within the LTS as a function of
total number of lines is provided below. Use of fewer than the recommended
number of each piece of equipment is possible but will result in a higher
percentage of testing failures due to the lack of available equipment.

Test Trunks Test trunk requirements, as a function of line sizes served by a common group of
test trunks, are summarized below. Use of fewer than the recommended number
of test trunks will result in a higher probability that access requests will be blocked.

Table 5-1. LTS Test Trunk Requirements for a Standalone

System

Number of Lines served No. of Test Trunks

by LTS LTS
0-4K 3
4K-10K 4
10K-30K 6
30K-50K 7
50K-80K 9
80K-100K 10
100K-130K 12

Precision The PMU sizing requirements are summarized below:

Measurement Unit
Number of PMUs
No. of Lines Required
0-10K 1
10-50K 2
50K-100K 3

5-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Sizing a Standalone LTS

Talk Trunks For interactive test/talk applications of LoopCare, the system will be required to
(Callback lines) set up a talk path to the user at a CRT. The estimated simultaneous talk path
capability required as a function of lines served is summarized below:

Number of Talk
No. of Lines Paths Required
0-4K 1
4-10K 2
10K-30K 3
30K-50K 4
50K-100K 5
> 100K 6

MDF Trunks The number of MDF Trunks required is sized on a per MDF basis. In instances
where a LTS will serve multiple MDFs, the number of MDF Trunks required for
each MDF should be determined first. The total number of MDF Trunks required
will then be the sum of the number required for each MDF. The sizing guidelines
for MDF Trunks are summarized below:

Number of MDF
No. of Lines Per MDF Trunks Required
0-10K 1
10K-30K 2
30K-60K 3
>60K 4

Unlike the LTF, each Test Port in the LTS is permanently connected to either a
Test Trunk or a MDF Trunk. Therefore, the number of ports needed for a certain
configuration is the sum of the MDF and Test Trunks.

Trunk Dialers A trunk dialer circuit pack provides one DP and one MF dialer. A total of two trunk
dialer circuit packs can be ordered. One dialer circuit pack is capable of serving
8,000 lines and two are needed more than 8,000 lines.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-17

System Administration Guide Maintenance
Sizing a Standalone LTS

Busy/Speech Small wire center clusters (less than 20K lines) require one Busy/Speech detector.
Detector Two Busy/Speech detectors are needed for wire centers greater than 20K lines.

Re-sizing of an It is strongly recommended that the sizing guidelines detailed above be revisited
Existing LTS for each LTS minimally on a yearly basis. In addition to these guidelines, it is also
recommended that the LoopCare Statistics program should be run on each LTS
on a regular basis.

The information within this document supersedes the ARSB Equipment Design
Requirements JIP023, 824-102-112.

5-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Maintenance System Administration Guide
Test Trunk Troubleshooting

Test Trunk Troubleshooting

Introduction See the MLT Trouble Locating Guide for Test Trunks section in chapter 13 of the
OAM Guide for the procedures on assisting maintenance personnel in identifying
and locating the causes of test trunk (and related equipment) failures. It provides
a complete list of access error codes and trunk calibration failure conditions
together with a list of probable causes of failure.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 5-19

System Administration Guide Maintenance
Test Trunk Troubleshooting

5-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture 6

Contents

• Oracle Architecture 6-3

Overview 6-3
System Requirements 6-3
ORACLE Database Instance 6-3
System Global Area 6-3
Background Processes 6-4
ORACLE Files 6-5
ORACLE RDBMS File System 6-7
• Database Backup Types Available 6-10
Overview 6-10
Cold Backups 6-10
Physical on-line backups 6-12
Logical backups 6-13
• Automated User Definable Backup 6-14
Overview 6-14

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-1

System Administration Guide ORACLE Database Architecture

Contents (continued)

Install Backup Utilities 6-14

Main Tasks 6-14
Dynamic Parameter File 6-15
Directory Contents 6-16
• Suggested Backup Strategies 6-21
Overview 6-21
Cold Backup 6-21
Hot Backup 6-22

6-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Oracle Architecture

Oracle Architecture

Overview This appendix provides ORACLE database reference information that supports
the Backup and Recovery procedures in the section on Database Backup and
Recovery of Chapter 3, System Operation in this guide.

System The LoopCare system running on HP-UX 10.20 uses a relational database using
Requirements the ORACLE Relational Database Management System (RDBMS), Release
7.3.2.

ORACLE Database ORACLE creates a set of background processes and memory structures, shared
Instance by all users, which are collectively called an instance. Each of the processes has
a specific function and shares the memory structures. This allows multiple users
consistent and reliable access to the data in the database. When users connect to
the database, a server and user-process pair are created to interact with the user
and communicate with the System Global Area. The background processes
manage the integrity of System Global Area and the data contained within.

System Global Area The System Global Area (SGA) is a large configurable memory structure used by
the ORACLE system and the user processes that connect to the database. It
maintains several buffer areas for database data, parsed SQL statements, and
redo log information. Each time a database instance is started, information
regarding the SGA is displayed by ORACLE.

Alternatively, the database administrator can access the Server Manager utility in
order to display the SGA.

SVRMGR> show sga

Total System Global Area 123632660 bytes
Fixed Size 76820 bytes
Variable Size 103817216 bytes
Database Buffers 19660800 bytes
Redo Buffers 77824 bytes

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-3

System Administration Guide ORACLE Database Architecture
Oracle Architecture

Background When an ORACLE database instance is active, several background processes

Processes are active, managing the integrity of the database. The major processes are:
PMON, SMON, DBWR, LGWR, ARCH, RECO, and SNP.

PMON

The Process Monitor (PMON) process reclaims database resources no longer

required by a user. Specifically, PMON does the following:
• Cleans up abnormally terminated database connections.
• Rolls back uncommitted transactions.
• Releases locks held by a terminated process.
• Frees SGA resources allocated to the failed process

MON

The System Monitor process (SMON) also reclaims database resources. SMON
does the following:
• Performs automatic instance recovery.
• Coalesces contiguous areas of free space in the data files.

DBWR

The Database Writer process (DBWR) manages the database buffer cache
contained in the SGA. It is responsible for writing data to disk by:
• Writing all changed buffers to data files via a LRU algorithm
• Defers writes for I/O optimization

LGWR

The ORACLE system records all of the changes made to the database in a redo
log buffer. The Log Writer process (LGWR) writes all of these changes in the redo
log buffer to the set of redo log files.

ARCH

When the database is running in ARCHIVELOG mode, before a redo log file is
about to be written over, the Archive process (ARCH) copies the redo log file to a
specified location. The archived file contains a sequence number in the filename
so that it can be uniquely identified.

6-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Oracle Architecture

RECO

The Recoverer Process (RECO) is responsible for resolving failures associated

with distributed transactions. In a distributed environment, there may be multiple
databases on multiple machines connected by a network.

SNP

The Snapshot background process (SNP) is responsible for handling the job
queue each time the database is started. The SNP background processes differ
from other ORACLE background processes in that the termination or failure of an
SNP process does not cause the database instance to fail. ORACLE will restart
the SNP process when the SNP process are terminated or fail.

ORACLE Files The ORACLE RDBMS requires certain physical files be present to start a
database instance and store its internal structures and user data. These files
include: parameter files, control files, data files, and redo log files.

Parameter files

The ORACLE parameter file has the default name INIT.ORA and contains all of
the startup values for the RDBMS. The items contained in this file all have the
<tag> = <value> format similar to shell variables definitions or a ".INI" file in the
MS-WINDOWS word. Some of the major definable items here are the database
name (equivalent to the $ORACLE_SID environment variable), the tunable
sections of the SGA, the names of all the control files, the naming convention for
redo log archives, and the ARCHIVELOG mode setting.

During the LoopCare installation process, there were database activities that were
performed in order to create the LoopCare database. When the LoopCare
database was created, the parameter file was defined so that ORACLE can read
its contents during the database startup to determine RDBMS configuration and
the size of the SGA. This file will be backed up to prevent the loss of any user
changes. It can be located under the following directory: ${ORACLE_HOME}/
dbs. The filename format is typically: init${ORACLE_SID}.ora. The variables
ORACLE_HOME is defined as the Path for the location of the ORACLE software
and ORACLE_SID identifies the database instance.

Archive Mode

The ARCHIVELOG mode setting in the INIT.ORA is part of ORACLE’s data

recovery strategy. Enabling this mode will force ORACLE to make a copy or
’archive’ of every redo log file before it attempts to re-write it. This allows systems
personnel to backup up the database (running some privileged ORACLE
commands first) without taking it down. The use of the set of redo log files by

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-5

System Administration Guide ORACLE Database Architecture
Oracle Architecture

ORACLE continues uninterrupted. The parameter settings in the INIT.ORA file

that influences the ARCHIVELOG mode for a database instance are defined as
follows:
log_archive_start
log_archive_dest
log_archive_format

Control files

A control file is a binary file where ORACLE stores the names of all of the physical
files that make up the RDBMS. The ORACLE documentation requires an
installation to define at least two (one for a backup). If ORACLE can not read this
file or any of the backup copies that it knows about (defined in the INIT.ORA file)
the database will fail.

As part of the LoopCare installation, three copies of the control file is maintained
by the ORACLE database. Each copy can be located under each of the /db1, /
db2, and /db3 file systems and end with the file extension, .ctl. The control files
will be included in the backup.

Data files

A tablespace is a logical division of a database. Every database has at least one

tablespace called the SYSTEM tablespace. A tablespace is made up of one or
more data files. Each data file is pre-allocated by ORACLE to be a contiguous
user-specified size. A data file may only be associated with one tablespace. The
name for each data file is recorded in the control file. Data files allow ORACLE to
easily extend a tablespace without taking off-line i.e. make it unavailable for use.

As part of the LoopCare installation, there were various tablespaces defined for
the LoopCare database. These tablespaces are located under each of the /db1, /
db2, and /db3 file systems and end with the file extension, .dbf. The data files that
make up each of the tablespaces will be included in the backup.

Redo Log files

ORACLE creates a set of user specified redo log files that contain all of the
transactions posted to the database. This set of files works in round robin fashion
-- ORACLE will fill up one file with transactions and then move onto the next one.
When the last file has been filled, ORACLE recycles the files and begins again
with the first one -- overwriting the existing contents.

Since Archive mode is enabled for LoopCare, ORACLE makes a copy or archive
of every redo log file before it attempts to re-write it. The naming convention of the
archived redo logs contains a numeric sequence to make each file unique. The
sequence number used is maintained in the control file.

6-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Oracle Architecture

As part of the LoopCare installation, there are three log file groups created, each
containing two log file members. Every member within a log file group is identical
and contains exactly the same information. These redo log files are located under
both the /db1 and /db2 file systems and also end with the file extension, ".dbf".
The redo log files will be included in the backup.

ORACLE RDBMS The structure of the ORACLE Relational Database Management System
File System (RDBMS) file system as installed on the LoopCare platform is shown below:

File System Description

/DB1 Indexes
/DB2 Tables
/DB3 Data Dictionary
/DB4 Redo Log Archives
/DB5 Indexes for Benchmark Database
/DB6 Tables related to Benchmark Database
/DB7 Temporary Tablespace
/ORACLE Software
/DBBACKUP Database Backup Location

For LoopCare systems without the LoopCare Benchmark Database feature, there
are three file systems, /DB1, /DB2, and /DB3 that contain all the ORACLE files
related to the LoopCare database, such as control files, data files, and redo log
files. The /DB4 file system is also used either for backups or archiving.

For LoopCare systems installed with the LoopCare Benchmark Database feature,
there are three files systems that are created in addition to the files systems /
DB1, /DB2, and /DB3. The LoopCare Benchmark Database feature will have
several large ORACLE data files that are stored in files systems /DB5, /DB6, and
/DB7.

The ORACLE database will hang if it is running in ARCHIVELOG mode and there
is no more space to write archive redo logs. Currently, LoopCare has a daemon
(known as fsckr) which periodically checks the /mlt file system and writes
warnings to the console and the LoopCare log files. This utility will be cloned and
marginally enhanced to create “redockr”. As with the original utility “fsckr”, the
user will be able to configure the initial threshold amounts.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-7

System Administration Guide ORACLE Database Architecture
Oracle Architecture

The tables below illustrate the contents of each of the file systems, /DB1, /DB2,
/DB3, /DB4, /DB5, /DB6, and /DB7 created to contain the data file elements of
the LoopCare ORACLE database.

File Tablespace
System Description Name Data File Name Size
/DB1 LoopCare Indexes MLTINX $(ORACLE_SID)_mltinc.dbf 120M
/DB2 LoopCare Tables MLTTBL $(ORACLE_SID)_mlttbl.dbf 140M
/DB3 Data Dictionary SYSTEM $(ORACLE_SID)_system.dbf 80M
Rollback Segments RBS $(ORACLE_SID)_rbs.dbf 140M
Temporary Tables TEMP $(ORACLE_SID)_temp.dbf 140M
/DB4 ORACLE Archive or N/A N/A 700M a
backups
/DB5 LoopCare Indexes BMINX1 $(ORACLE_SID)_bminx1.dbf 800M
for Benchmark BMINX2 $(ORACLE_SID)_bminx2.dbf 800M
Database BMINX3 $(ORACLE_SID)_bminx3.dbf 800M
/DB6 LoopCare Tables for BMTMLM $(ORACLE_SID)_bmtblms.dbf 1M
Benchmark S $(ORACLE_SID)_bmtblm1.dbf 1349M
Database BMTBLTN $(ORACLE_SID)_bmtblm2.dbf 1300M
BMTBLB 1300M
M1
BMTBLB
M2
/DB7 LoopCare TEMP $(ORACLE_SID)_temp.dbf 400M
Temporary
Tablespace
a. Increase the amount of space currently allocated for the redo log directory, for example,
/db4, to 1500M to accommodate the BMDB database and usage.

File System Description Data File Name Size

/DB1 Redo log #1 $(ORACLE_SID)_log1a.dbf 5M
Redo log #2 $(ORACLE_SID)_log2a.dbf 5M
Redo log #3 $(ORACLE_SID)_log3a.dbf 5M
Control File ctrlmlt1.ctl 56K
/DB2 Redo log #1 $(ORACLE_SID)_log1b.dbf 5M

6-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Oracle Architecture

File System Description Data File Name Size

Redo log #2 $(ORACLE_SID)_log2b.dbf 5M
Redo log #3 $(ORACLE_SID)_log3b.dbf 5M
Control File ctrlmlt2.ctl 56K
/DB3 Control File ctrlmlt3.ctl 56K

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-9

System Administration Guide ORACLE Database Architecture
Database Backup Types Available

Database Backup Types Available

Overview There are two basic types of backup: physical and logical. Physical refers to the
operating system files that contain the ORACLE structures and user data. The
physical database backup are classified as "cold" (having the database off-line
and unavailable) or "hot" (the database remains on-line and available). Hot
database backups require the system to be in ARCHIVELOG mode. To be able to
recover a database to the point prior to failure, the redo log archives must be
saved.

Cold Backups Almost every computer system has some form of system backup to tape or CD-
ROM. Since ORACLE the database ultimately resides in operating system files,
we can achieve a complete reliable backup of the database by a conventional file
system backup. Before performing a cold backup, the ORACLE system requires
shutting the database instance down. The shutdown guarantees a transaction
consistent database. Simply copying the contents of the file systems while the
database is on-line could not provide this consistency.

6-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Database Backup Types Available

The shutdown sequence must be executed as the SYS user from the SVRMGR
utility:

The database instance is now shutdown and can be verified by searching for the
ORACLE background processes via the "ps" command.
ora_utopia> ps -fu oracle|grep -v grep|grep $ORACLE_SID
ora_utopia>

Once down, the file system backup utilities can copy file systems /DB1, /DB2, and
/DB3. Included in this copy process should be the "INIT.ORA" file. The dbbackup

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-11

System Administration Guide ORACLE Database Architecture
Database Backup Types Available

shell will provide this capability. The database can be restarted via the startup
command:

When available this is the preferred method for backup. The drawback to this
approach is that the database is unavailable for the time it takes to copy the files.
If the database is in ARCHIVELOG mode, the archived redo logs must be deleted
because all information in them has already been applied to the data files and are
no longer needed for recovery.

Physical on-line The ORACLE system has a facility to perform a hot backup while the system is
backups still available. This method can only be performed if the database is
ARCHIVELOG mode. The procedure is to place each tablespace into "backup"
mode and immediately copy the associated data files to tape or auxiliary disk.
After each the copy is complete, the tablespace must be returned to the normal
state. The procedure continues until all of the tablespaces have been copied. The
redo logs, their archives, and the control files must all be subsequently copied.

6-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Database Backup Types Available

The entire process must be coordinated via special ORACLE commands, again
run from the SVRMGR utility:
alter tablespace <TABLESPACE> begin backup;
alter tablespace <TABLESPACE> end backup;
alter system switch logfile;
alter database backup controlfile to '<FILENAME>';

The first two take the tablespace in and out of backup mode. The third commands
forces a redo archive to be taken, ensuring all the transaction data will be save to
disk for subsequent backup. The last is simply ORACLE’s form of copying the
control file to another location. The entire time the database is available for users.
One drawback here is that the system may slow down while this activity is taking
place. We can delete the archived redo logs from the system once copied to disk
or tape. A hot backup is not a complete backup and we need to have the copies of
archived redo logs to facilitate a successful recovery.

Logical backups The ORACLE system includes a pair of utilities for exporting and importing data.
They are EXP and IMP respectively. The EXP command produces a binary file
containing all of the data dictionary information (table creation statements, user
definitions, privileges, etc.) in addition to the data, allowing a complete database
to be captured in its logical form. The file can then be used as input to the IMP
utility to completely restore/recreate a database. A drawback to this method of
backup is that uncommitted transactions are not saved.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-13

System Administration Guide ORACLE Database Architecture
Automated User Definable Backup

Automated User Definable Backup

Overview A series of Korn shells was created to assist LoopCare administrators who will be
required to implement a backup and recover procedure for the LoopCare
database. These scripts are used to automate the backup process. This
automated backup method provides a mechanism (which can be automated
through use of cron) to mix and match the backup methods presented above.

This method provides flexibility that allows it to be adapted to customers’ needs.

This implementation makes use of a Backup Disk as the backup target allowing
customers to copy to tape independent of LoopCare operation.

Install Backup Backup scripts are included with the LoopCare software and reside under the
Utilities directory /mlt/install. Customers, who have not already implemented any backup
and recovery procedures, can use the following procedures to install these
backup scripts.

Install the backup scripts as user ORACLE by running the following command.
/mlt/install/installbackup

Main Tasks The main driver shell dbbackup, provides the control logic for hot and cold
backups along with export file creation and special purpose DBA level tasks. The
command line syntax is:
dbbackup [-c | -S] <dbname> <system-password>
where:
The -c option indicates that gzip should be used to compress the
Oracle database files
The -S option indicates that the mltctrl utility be executed to stop
the MLT application before attempting to run the backups. Since this
process is executed by oracle, it is necessary to ensure that the
oracle user account also belongs to the baseadm group defined in
the /etc/group folder.

Environment variables specific to the database required by dbbackup are defined

in:

${ORACLE_HOME}/${ORACLE_SID}/tools/<dbname>_backup_admin.sh

A summary of these environment variables are displayed below:

6-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Automated User Definable Backup

#ADMIN=$TOOLS/admin; export ADMIN

TOOLS=${ORACLE_HOME}/tools
BACKUPDIR=; export BACKUPDIR
EXPORTDIR=; export EXPORTDIR
EXPORTDIROLD=; export EXPORTDIROLD
ARC=; export ARC
LOGFILESIZE=2049; export LOGFILESIZE
export DBA_MAIL_LIST=""

Each of the undefined environment variables need to be defined with an

appropriate directory path. In addition, the defined directories need to be created
prior to running any of the backup scripts.

These variables are used by the dbbackup_begin and dbexport_begin procedures

for directing backup copies of files and export files.

Dynamic Parameter The dbbackup_begin utility builds a dynamic listing of database files for use by hot
File and cold backup to the file:

${ORACLE_HOME}/${ORACLE_SID}/tools/backup/<dbname>_backup_<date>.dyn

This file is of the format:

[tablespace name] [file name] [backup directory logical]

When the shell is performing the Hot Backup:

• The dbbackup_begin procedure that is called by dbbackup performs the
hot backup. Each tablespace is put into hot backup mode, a file copied,
then hot backup mode ended.
• A log switch is forced before the archive logs are copied.
• Online redo logs are not copied.
• Only a single control file backup is made.

When the shell is performing the Cold Backup:

• The dbbackup_begin procedure that is called by dbbackup performs the
cold backup.
• Wall messages are sent to the system at 15, 5 and 1 minute intervals to
warn of impending database shutdown.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-15

System Administration Guide ORACLE Database Architecture
Automated User Definable Backup

• The database is shutdown. Each of the database files, online redo logs,
control files and archive logs is copied (the logs do not, however, need to
be copied for a cold backup).
• The database is restarted in restricted mode and DBA mode tasks are
performed such as ANALYZE. NOTE: This is not required for a cold
backup, but the shells attempt to facilitate DBA related activities such as
ANALYZE.
• The database is shutdown and restarted. A wall message is sent
announcing online status.

Export:
• The dbexport_begin procedure performs the export using the parameter
file:

${ORACLE_HOME}/${ORACLE_SID}/tools/<dbname>_export.par
• The old export file is copied to a backup location and deleted to make room
for the new export file. The new export file is created.
• In our replicated environment, the system should be queued if we want to
have a consistent image at backup time.

Special Tasks:
• The dbbackup_begin procedure performs special_tasks while in DBA
mode.
• The use of this function will expand over time.

Directory Contents The automated backup mechanism will be installed into a directory tree
designated by $TOOLS (initially ${ORACLE_HOME}/tools) with the following
subdirectories:

./admin utility shells and wrappers to ORACLE tools

./mail shells to send mail messages
./db_mgmt the location of the backup utitlies
./system cron data

The complete list of files, both those delivered and those generated at execution,
are listed below. NOTE: The LoopCare installation will resolve the file names
described with "$" variables to be complete names,

Example:

6-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Automated User Definable Backup

${ORACLE_HOME}/${ORACLE_SID}/tools/<dbname>_backup_admin.sh

could become /oracle/app/oracle/product/8.1.7/mlt51/tools/

mlt51_backup_admin.sh

File Description
$TOOLS /admin/analyze called by analyze_driver
$TOOLS /admin/analyze_create called by space_report
$TOOLS /admin/analyze_driver command line or cron
$TOOLS/admin/dbredo_backup command line or cron
$TOOLS /admin/kill_processes.ksh called by dbbackup
$TOOLS /admin/online_banner called by dbbackup
$TOOLS /admin/shutdown_abort called by dbbackup
$TOOLS /admin/shutdown_banner called by dbbackup
$TOOLS /admin/shutdown_immediate called by dbbackup
$TOOLS /admin/startup called by dbbackup
$TOOLS /admin/startup_restrict called by dbbackup
$TOOLS /mail/dba_mail_list called by dbbackup
$TOOLS/db_mgmt/backup/dbbackup main routine
$TOOLS/db_mgmt/backup/dbbackup_begin called by dbbackup
$TOOLS/db_mgmt/backup/dbexport_begin called by dbbackup
$TOOLS/db_mgmt/backup/dbbackup_sched.dat schedule file
${ORACLE_HOME}/${ORACLE_SID}/tools/<dbname> environment variables
_backup_admin.sh
${ORACLE_HOME}/${ORACLE_SID}/tools/<dbname> sql written by
_backup_<date>.dyn dbbackup_begin
${ORACLE_HOME}/${ORACLE_SID}/tools/log/ log written by dbbackup
<dbname>_backup_<date>.log
${ORACLE_HOME}/${ORACLE_SID}/tools/log/ error log written by
<dbname>_backup_<date>.err dbbackup
${ORACLE_HOME}/${ORACLE_SID}/tools/log/ email msg written by
<dbname>_backup_<date>.msg dbbackup
${ORACLE_HOME}/${ORACLE_SID}/tools/log/ export parameter file
<dbname>_export.par

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-17

System Administration Guide ORACLE Database Architecture
Automated User Definable Backup

File Description
${ORACLE_HOME}/${ORACLE_SID}/log/dbbackup.log crontab log
$TOOLS/system/crontab.dat crontab schedule
$TOOLS/system/crontab.env environment variables
$TOOLS /system/script_footer called by dbbackup
$TOOLS /system/script_header called by dbbackup

analyze

A small shell to execute the SQL commands generated by the analyze_driver

script.

analyze_create

The ORACLE analyze command creates usage statistics for any database object
and stores the results in the data dictionary. The statistics can be used over time
to make performance improvements to the database in the form of more efficient
storage allocations. This shell scans the MLTDBA schema and creates a dynamic
SQL file to create statistics for all its objects. The generated SQL file is
subsequently run by the analyze shell.

analyze_driver

The ORACLE analyze_driver command generates a script which calls the above
analyze and analyze_create scripts for each user object.

crontab.dat

This file contains the default cron schedule to implement the automated backup.

NOTE:
The entries defined in this file need to be updated to reflect the correct path
for HOME directory of ORACLE.

dbbackup

The main driver logic for the backup mechanism.

dbbackup_begin

The workhorse of the backup mechanism, this shell controls all of the hot and cold
backup logic described above in section 5.1.

6-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Automated User Definable Backup

dbredo_backup

This shell copies all of the archive redo logs from the archive file system to the
backup disk and removes the originals once copied. This utility is run from the
command line but optimally from cron and accepts two arguments for the archive
and backup directories, respectively.

dbbackup_sched.dat

The basic mechanism reads a schedule parameter file and calls appropriate
shells to execute the tasks defined by the input. The format of the file is:

<ORACLE_SID> <day-of-the-week> <hot|cold|nobackup>

<export|noexport> <special script>

dbexport_begin

Similar to dbbackup_begin, this shell is called from dbbackup when the parameter
file indicates an export is required. It makes use of a parameter file for the EXP
utility, which can be changed to tailor the export to customer needs without
effecting the main export logic.

dba_mail_list

The dbbackup shell notifies a receipt list of the backup completion. This simple
shell sends the mail message generated during the backup to a list of recipients
designated by the variable $DBA_MAIL_LIST, which is defined in

${ORACLE_HOME}/${ORACLE_SID}/tools/<dbname>_backup_admin.sh.

kill_processes.ksh

This shell will kill off the remaining ORACLE user processes after the database
has been shutdown during a cold backup.

online_banner

Send a wall message to notify the users that the database is back on-line.

script_header and script_footer

These shells provide a header and footer for the logs generated during the
backup.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-19

System Administration Guide ORACLE Database Architecture
Automated User Definable Backup

shutdown_abort and shutdown_immediate

These wrapper shells for SQLDBA perform the ORACLE "shutdown abort" and
"shutdown immediate" commands respectively during a cold backup.

shutdown_banner

Send a wall message to notify the users that the database will be going off-line in
<$1> minutes.

startup and startup_restrict

These wrapper shell for SQLDBA perform the ORACLE "startup" and "startup
restrict" commands respectively during a cold backup.

redockr

This daemon process described earlier will be launched by the MLT group startup
sequence.

6-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Suggested Backup Strategies

Suggested Backup Strategies

Overview Customer requirements determine whether cold or hot backups are employed.
This section provides a suggested schedule for each type as well as configuration
information.

The customer needs to review all existing backup and recovery procedures in
order to determine what strategy is implemented for the LoopCare database.

Cold Backup A seven day rotation beginning with a cold backup on the first day followed by six
days of archive redo log backups should provide adequate safety with minimal
data loss exposure. The following entries are needed:
• an entry in the dbbackup_sched.dat file for the day of the week the cold
backup will run.
• a crontab entry for the backup driver dbbackup.
• a crontab entry for the frequency with which dbredo_backup is run.
• a crontab entry for a cpio/tar backup to tape or a network scheduled tape
backup is run.

dbbackup_sched.dat

This example requests a cold backup of the mlt51 for Sunday and an export of the
database.
• mlt51 Sun cold export

crontab.dat

The following sample crontab.dat file entries run the backup on Sunday nights at
3am, copy the redo every half hour and backup to tape every hour.

0 3 * * 0 ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
dbbackup $ORACLE_SID manager >> /dev/null

0,30 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/

dbredo_backup $DB4 $BACKUPDIR >> /dev/null

0 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
copy_to_tape >> /dev/null

(Continued on next page)

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-21

System Administration Guide ORACLE Database Architecture
Suggested Backup Strategies

You will need to replace the ORACLE_HOME variable used in the above Crontab
entries with the full directory path to the location of the ORACLE software.

Note that dbbackup script should be run with two parameters; database instance
name and the system DBA password. These two are required parameters. It is
okay to specify the DBA password in the crontab.dat file because it is protected
against read and write. Also note that "manager" is the default password for
System DBA. If this password is changed then the this file should also be
updated. If not the nightly job would fail.

Hot Backup The same seven day rotation beginning with a hot backup on the first day followed
by six days of archive redo log backups should provide adequate safety with
minimal data loss exposure. The following entries are needed:
• an entry in the dbbackup_sched.dat file for the day of the week the
cold backup will run.
• a crontab entry for the backup driver dbbackup.
• a crontab entry for the frequency with which dbredo_backup is run.
• a crontab entry for a cpio/tar backup to tape or a network scheduled
tape backup is run.

dbbackup_sched.dat

This example requests a hot backup of the mlt51 for Sunday and an export of the
database.

mlt51 Sun hot export

crontab.dat

The following sample crontab.dat file entries run the backup on Sunday nights at
3am, copy the redo every half hour and backup to tape every hour.

0 3 * * 0 ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
dbbackup $ORACLE_SID manager >> /dev/null

0,30 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/

dbredo_backup $DB4 $BACKUPDIR >> /dev/null

0 * * * * ksh ${ORACLE_HOME}/tools/db_mgmt/backup/
copy_to_tape >> /dev/null

You must replace the ORACLE_HOME variable used in the above Crontab
entries with the full directory path to the location of the ORACLE software.

6-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ORACLE Database Architecture System Administration Guide
Suggested Backup Strategies

Note that dbbackup script should be run with two parameters; database instance
name and the system DBA password. These two are required parameters. It is
okay to specify the DBA password in the crontab.dat file because it is protected
against read and write. Also note that "manager" is the default password for
System DBA. If this password is changed then the this file should also be
updated. If not, the nightly job would fail.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 6-23

System Administration Guide ORACLE Database Architecture
Suggested Backup Strategies

6-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration 7

Contents

• Introduction 7-2
• Replication 7-3
• Creating a Replicated Environment 7-10
• Propagating Changes Between Replicas 7-18
• Resolving Out-of-Sync Databases 7-21
• Troubleshooting Replication 7-30
• Disabling OAM and MLT UIP Functionalities 7-43
• Warm Standby Server Configuration 7-44
• Hot Standby Server Configuration 7-51

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-1

System Administration Guide Replication Administration
Introduction

Introduction

Overview This chapter provides instructions for the Oracle Database Administrator (DBA) to
monitor and maintain the Oracle Server capabilities to replicate data between
LoopCare front-ends. Some of the common tasks associated with the
administration of Oracle replication includes:
• Verify status of replication objects
• Verify status of replication schema
• Monitor Oracle job queue
• Monitor Oracle replication, e.g. deferred transactions
• Resolve Oracle replication errors, e.g. deferred transaction errors

Each of these tasks will be covered in the following section of this chapter. For
LoopCare administrators who also have the burden of being the Oracle DBA for
the LoopCare front-ends, there are several sections included, which briefly
describes Oracle replication.

7-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Replication

Replication

Overview The Oracle Server provides several ways for data to be replicated between two or
more LoopCare front-ends. The replication installation utilities for the LoopCare
databases will set up asynchronous replication. Therefore the focus of our
discussions will revolve around asynchronous replication, which is also referred to
as store-and-forward replication.

With a completely asynchronous replication environment, there are several

advantages over other forms of replication. Some of these advantages have been
summarized below:
• Failures of remote replicated sites does not prevent remaining sites from
querying, updating replicated data locally.
• Response times for updates are improved because of the ability to store-
and-forward changes to the remote sites.
• Deferred transactions are propagated as a any defined interval, which can
achieve”near real-time” replication when the defined interval is just a few
seconds.

Along with the advantages of replication are some disadvantages. Some of the
disadvantages have been summarized below:
• Changes at remote sites do not immediately reflect the local site until the
deferred transactions have been completely applied.
• Conflicting changes between multiple sites can result in deferred
transaction errors but most conflicts are handled by built-in mechanisms in
Oracle.

Definitions Before we begin our discussions on Oracle replication, there are many terms that
are constantly used throughout the chapter. In an effort to help the reader

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-3

System Administration Guide Replication Administration
Replication

understand the subsequent information, this section has been added to define
each of these important terms.

Asynchronous replication One of several ways for data to be replicated

between databases. Asynchronous replication
propagates changes made to the database using
deferred transactions. This type of replication is
also referred to as store-and-forward replication.
Data definition language Schema-level statements that are performed
against a database schema, e.g., tables, views,
triggers, packages, synonyms. In replicated
environments, these statements can be replicated.
Data manipulation language Data-level statements that are performed against
a table, e.g., add, update, or delete statements. In
a replicated environment, these statements are
ultimately propagated to every other replica of the
table.
Deferred transaction error In the event that a deferred transaction in the
deferred transaction queue can not be applied to
each destination, the result is a deferred
transaction error.
Deferred transaction queue One of the mechanisms for asynchronously
propagating data-level (DML) changes between
replicated sites.
In a replication environment, when changes are
made to the database, the change fires a trigger
that builds a remote procedure call to a packaged
procedure at the remote replicated site(s). The
remote procedure calls are stored in the local
deferred transaction queue. The queue is cleaned
as each transaction has been successfully
propagated to each of the replicated sites.
Job queue The job queue facility is used to schedule the
periodic execution of PL/SQL code. The job queue
facility is used extensively with replication in order
to propagate changes between replicated sites.

Continued on next page

Master definition site The replication site used as the control point for
performing administrative activities. For example,
the master definition site is the site where
replication objects are created/removed and
replication can be quiesced.

7-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Replication

Master site The replication site(s) where copies of objects in a

replication group are sent. Each master site
propagates its changes to every other master site
for the replication group.
Remote procedure call The request to a remote site(s) to execute PL/SQL
code.
Replication catalog Used by the symmetric replication facility to
maintain information pertaining to which objects
are being replicated, where objects are being
replicated, and how updates are replicated to each
replica(s).
Replicated environment An environment consisting of replication objects
belonging to a replication group. There is also a
master definition site and master site(s) containing
replicas of the group.
Replicated group The basic unit for controlling and managing
advanced replication.
Replicated object Any database object that is copied to multiple sites
in a replication environment.
SNP background process The SNP processes are responsible for the
execution of any queued jobs that are scheduled
to run. These processes run at a pre-determined
interval. Unlike all the other Oracle background
processes, the SNP processes that fail will not
cause the instance to fail. The Oracle instance will
restart the SNP processes.
Symmetric replication The advanced replication option allows the ability
to update records from any database. These
transactions are applied to all remaining sites.
Ultimately all sites in the replication environment
converge on the same data.

Replication Tables Oracle provides several tables and views that will help the Oracle DBA administer
replication. The following list identifies each of these table or views along with a
description.

The tables and views that are helpful in administering deferred transaction have
been included.

The tables and views that are helpful in administering jobs in the Oracle job
queue.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-5

System Administration Guide Replication Administration
Replication

All_RepGroup Lists all of the object groups that are being replicated.
All_RepCatLog All messages encountered while executing any
asynchronous administrative request are record in
this view. If the request completes without errors, the
request is removed from this view.
All_RepColumn_Group Lists all the column groups defined for each replicated
table.
All_RepConflict Lists all conflict resolution methods defined for each
replicated table.
All_RepDDL Lists all the DDL for replication objects.
All_RepGenerated Lists information about the system generated objects
for each replicated object.
All_RepGrouped_Column Lists all of the columns that make up the column
groups for each replicated table.
All_RepKey_Columns Lists information relating to the primary key column for
each replicate table.
All_RepSites Lists the members of each replicated object group.
All_RepObject Lists information about the objects in a replicated
object group.
All_RepParameter_Column Lists information about the columns to be used to
resolve conflicts.
All_RepPriority Lists the value and priority level of each priority group
member.
All_RepPriority_Group Lists the priority and site priority groups defined for
each replicated object group.
All_RepProp Lists the method used to propagate operations on an
object to the same object at each of the replicated
sites.

Continued on next page

All_RepResolution Lists the routines used to resolve update, unique, or
delete conflicts for each table replicated using row-
level replication.
All_RepResol_Stats_Control Lists the information about statistics collection for
conflict resolutions for all replicated tables.

7-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Replication

All_RepResolution_Method Lists all the conflict resolution routines available.

All_RepResolution_Statistics Lists information about successfully resolved updates,
uniqueness, and delete conflicts for each replicated
table.
All_RepSchema Refer to view: All_RepSites

DefCall Records all deferred remote procedure calls.

DefCallDest Lists the destinations for each deferred remote
procedure call.
DefDefaultDest Lists the default destination for deferred remote
procedure calls.
DefError Provides information about transactions that could not
be applied at each destination.
DefSchedule Displays information about when a job is next
scheduled to be executed.
DefTran Records all deferred transactions.
DefTranDest Lists the destinations for a deferred transaction.

DBA_Jobs Lists information about all queued jobs in the

database. The USER_JOBS table provides the same
information but for the individual user.
DBA_Jobs_Running Lists information about any jobs that are currently
running.

Advanced The LoopCare database that is replicated between two or more front-ends is
Replication configured with the advanced replication option, which supports symmetric
replication, also referred to as update-anywhere replication model. This means
that all copies of data can be potentially updated, and ultimately all sites will
converge on the same data.

It is recommended that all changes continued to be made through the LoopCare

OAM application from the master definition system. In the past, some customers
would update information from each of the LoopCare front-ends. Under this
situation, updates being performed on the same record from two different
LoopCare front-ends could result in a conflict. In cases where a conflict occurs,
the replication objects have been configured to resolve the conflict using the
LATEST TIMESTAMP method. Specifically, the LoopCare record with the latest
timestamp for the MODIFIEDDATE column in the LoopCare table would be
applied to the database. In the LoopCare database, each of the LoopCare tables

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-7

System Administration Guide Replication Administration
Replication

in the database have the column, MODIFIEDDATE, in order to capture the exact
time a DML statement was applied to the record.

In a replicated environment created for LoopCare environments with two or more

LoopCare front-ends, all of the replication objects created are one of the following
structure types:
• Package
• Package Body
• Table
• Trigger

Each of the above replication objects can be identified by examining the

ALL_REPOBJECT table. Furthermore, each object must have a VALID status.

All the replication objects are grouped for the purpose of controlling and managing
advanced replication. By grouping replication objects, the replication administrator
can associate replication objects with a particular application and/or to be
replicated to a set of sites. With LoopCare, there is only a single replicated group,
called MLTDBA, which all the replication objects belong. Information about each
of the replication groups can be queried from the ALL_REPGROUP table.
Furthermore, each replication group must have a status of NORMAL, which
indicates replication is running. Other statuses that can exist are quiescing or
quiesced. In each of these other statues, no updates can be applied to the
database.

Replication Sites In a typical LoopCare environment configured with asynchronous replication,

there are two kinds of replication sites: master definition site and master site(s).

A master definition site is used as the control point for performing administrative
activities related to replication. These activities can include suspending
replication, resume replication, relocate master definition site responsibilities, drop
and recreate replication objects, etc. On the other hand, the master site is only
responsible for propagating its changes to every other master site for the
replication group. In summary, all data-level changes can be made at any site
defined in a replication environment, but schema-level changes must be
performed from the master definition site.

7-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Replication

Most configurations included one master definition site and one master site as
illustrated in Figure 6-1.

Master
Definition Master
Site Site

Figure 7-1. Master Site Configuration

However there are other possible configurations. In the LoopCare environment,

these other configurations include multi-master replication. In a multi-master
replication environment, there is at least one master definition site with several
master sites, as illustrated in Figure 6-2.

Master
Site

Master
Definition
Site

Master
Site

Figure 7-2. Multi-master Replication Environment

Regardless of the kind of configuration, changes applied to any table from any site
is propagated and applied to all other replicas of the table.

Oracle Replication Oracle Replication Manager is a graphical user tool that lets you configure,
Manager schedule, and administer you replicated environment. To learn more about this
tool, refer to the Oracle Replication Manger documentation.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-9

System Administration Guide Replication Administration
Creating a Replicated Environment

Creating a Replicated Environment

Overview This procedure assumes that the LoopCare ORACLE database(s) and schema(s)
have already been created and populated minimally with data. At this point,
replication can be configured to run on top of these existing databases. This
procedure consists of the following tasks:
• Preparing the databases for replication
• Generate files and scripts for SQL/*Net and replication configuration
• Configuring SQL/*Net on the databases
• Creating database links between the databases
• Configuring replication on the databases

Collect Information The replication environment to be created requires one machine to be designated
for Replication as the master definition site and one or more machines designated as the master
site(s).

Fill in information on the designated master definition and master site(s) prior to
creating the replication environment.

Table 7-1. Master Definition Site

Hostname TCP/IP Address Oracle SID

Table 7-2. Master Site(s)

Hostname TCP/IP Address Oracle SID

7-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Creating a Replicated Environment

Preparing the This procedure creates the necessary accounts and packages on the database(s)
Databases for to support replication.
Replication
The following procedure should be completed on all sites, including:
• the master definition site machine
• all master site machines in the replicated environment
1. Login to each server as user oracle:
su - oracle
2. Dot execute mlt's .profile:
. /mlt/exec/.profile
3. Execute the oraclevars file:
. /mlt/config/oraclevars
4. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
5. Verify the permissions are for the log directory is read, write, and
executable to all users.
chmod 777 /mlt/install/dblog
6. Change directory:
cd /mlt/install
7. Run setuprep to create the replication accounts and replication packages
and procedures needed to support LoopCare:
/mlt/install/setuprep
8. Check the log file, /mlt/install/dblog/setuprep_<SID>.log, for errors and
correct as appropriate.
more /mlt/install/dblog/setuprep_<SID>.log
(SID is defined as the as the $ORACLE_SID.)-

Generate Files and This procedure creates the SQL/*Net configuration files and the SQL scripts used
Scripts for SQL/ to create database links in the replication environment.
*Net and 1. Login as mlt on the server selected to be the master definition site
Replication machine.
su - mlt

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-11

System Administration Guide Replication Administration
Creating a Replicated Environment

password:
2. Dot execute the oraclevars file:
. /mlt/config/oraclevars

NOTE:
Refer to the above section, Collecting Information for Replication.

3. Run cfgrep to create the SQL/*Net configuration files.

Run this script only on the master definition site machine:
ksh /mlt/install/cfgrep -p <repadmin passwd> -s <sys
password>
(where <password> refers to the password setup for the repadmin user in
Oracle. The default is repadmimpw.)

The following paragraphs provide information on the content of the cfgrep script
along with a sample script output and prompts.

The <master definition SID> refers to the Oracle SID value for the
LoopCare machine that will act as the master definition site machine in the
replication environment. The <master definition host> simply refers to the
host name of the master definition site machine.

The LoopCare database can be replicated across several host machines in a

replication environment. The <master site SID> refers to the Oracle SID of a
LoopCare machine, which will rely on the <master definition host> in order keep
the LoopCare database in sync. The <master site host> simply refers to the
host name for the master site machine.

The ”111” is the Unix process id of this execution of cfgrep.

ENTER ‘q’ to QUIT OR TO SPECIFY NO MORE ENTRIES
Enter oracle SID for new master definition site: mlt50
Enter host machine name for new master definition site:
jupiter
Enter host port number for new master definition site
[1521]: 1521

Enter oracle SID for new master site: mlt51

Enter host machine name for new master site: saratoga
Enter host port number for new master site [1521]: 1521

Enter oracle SID for new master site: q

7-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Creating a Replicated Environment

Generated scripts:
/mlt/install/dblog/tnsnames111.ora
/mlt/install/dblog/listener111.ora.< master site host>
/mlt/install/dblog/listener111.ora.< master definition
host>
/mlt/install/dblog/crlinks111
/mlt/install/dblog/crrep111
4. Verify the contents of the scripts generated for SQL/*Net and Replication:
more /mlt/install/dblog/tnsnames111.ora
more /mlt/install/dblog/listener111.ora.<master site
host>
more /mlt/install/dblog/listener111.ora.<master
definition host>
more /mlt/install/dblog/crlinks111
more /mlt/install/dblog/crrep111

NOTE:
Make sure that the /etc/host file contains the TCP/IP addresses for the
master definition site machine and all the master site machine(s).

Configure SQL/ This procedure creates the SQL/*Net configuration files and the SQL scripts used
*Net to create database links and the replication environment.

Any reference to password In this procedure indicates that the user must specify
the password for the replication manager. The Oracle default settings for the
replication manager are:
userid: repadmin
password: repadminpw
1. Login as oracle on the server selected to be the master definition site
machine.
su - oracle
password:
2. Dot execute the oraclevars file:
. /mlt/config/oraclevars
3. Copy the tnsnames.ora and listener.ora to the <master definition host> and
startup the listener process.
cp /mlt/install/dblog/tnsnames111.ora \

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-13

System Administration Guide Replication Administration
Creating a Replicated Environment

$ORACLE_HOME/network/admin/tnsnames.ora
cp /mlt/install/dblog/listener111.ora \
$ORACLE_HOME/network/admin/listener.ora
4. Verify the owner, group, and permissions on the tnsnames.ora and
listener.ora files.
cd $ORACLE_HOME/network/admin
chown oracle tnsnames.ora listener.ora
chgrp dba tnsnames.ora listener.ora
chmod 644 tnsnames.ora listener.ora
5. Startup the listener process on the master site machine.
lsnrctl start
6. Add the listener startup command to the /sbin/rc2.d/SXXXoracle file for the
automatic startup of the SQL/*Net listener process on the <master
definition host>. Where XXX equals the number setup in the specific
environment.
su - root
passwd:
vi /sbin/rc2.d/SXXXoracle
“verify or add the following in the /sbin/rc2.d/
SXXXoracle“
# Execute the commands to start your subsystem
su - oracle -c $ORACLE_HOME/bin/dbstart
su - oracle -c "lsnrct1 start“
set_return

# Execute the commands to stop your subsystem

su - oracle -c "lsnrct1 stop“
su - oracle -c $ORACLE_HOME/bin/dbshut
set_return

NOTE:
In the previous step, be sure to include the double quotes around the -c
option.

7. Exit and return to the oracle login.

8. Copy the tnsnames.ora and listener.ora to all the <master site host> .
cd /mlt/install/dblog
ftp <master site host>

7-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Creating a Replicated Environment

Name: <oracle>
Password: <passwd>
ftp> cd $ORACLE_HOME/network/admin
ftp> put tnsnames111.ora tnsnames.ora
ftp> put listner111.ora <master site host> listener.ora
ftp> quit
9. Login as oracle on the master site machine(s).
rlogin <master site host> -l oracle
10. Verify the owner, group, and permissions on the tnsnames.ora and
listener.ora files.
cd $ORACLE_HOME/network/admin
chown oracle tnsnames.ora listener.ora
chgrp dba tnsnames.ora listener.ora
chmod 644 tnsnames.ora listener.ora
11. Startup the listener process on the master site machine.
lsnrctl start
12. Add the listener startup command to the /sbin/rc2.d/SXXXoracle file for the
automatic startup of the SQL/*Net listener process on all master site
machines.
su root
passwd:
vi /sbin/rc2.d/SXXXoracle

verify or add the following in the /sbin/rc2.d/

SXXXoracle"
# Execute the commands to start your subsystem
su - oracle -c $ORACLE_HOME/bin/dbstart
su - oracle -c "lsnrct1 start“
set_return

# Execute the commands to stop your subsystem

su - oracle -c "lsnrct1 stop“
su - oracle -c $ORACLE_HOME/bin/dbshut
set_return

NOTE:
In the previous step, be sure to include the double quotes around the -c
option.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-15

System Administration Guide Replication Administration
Creating a Replicated Environment

13. Verify that the database(s) and SQL/*Net listener processes are running by
trying to connect to all database(s) from each machine. Do not proceed
until there are no errors.
rlogin <master definition host> -l oracle
. /mlt/install/oraclevars
sqlplus repadmin/password@<master definition SID>
SQL> connect repadmin/password@<master site SID>
SQL> exit
exit
rlogin <master site host> -l oracle
. /mlt/install/oraclevars
sqlplus repadmin/password@<master site SID>
SQL> connect repadmin/password@<master definition SID>
SQL> exit
exit

Run Replication The procedure below is a continuation of the procedure in the previous section
Scripts Items in italics are specific to this sample execution. These generated replication
scripts must only be run if you are configuring a replicated environment.
1. Login to the master definition site machine as user oracle.
su - mlt
password:
2. Dot execute the oraclevars file:
. /mlt/config/oraclevars
3. Verify that the setuprep was executed in order to create the replication
accounts, replication packages, and procedures needed to support
LoopCare replication.
more /mlt/install/dblog/tnsnames111.ora
more /mlt/install/dblog/listener111.ora.<master
definition host>
more /mlt/install/dblog/listener111.ora.<master site
host>
more /mlt/install/dblog/crlinks111
more /mlt/install/dblog/crrep111
4. Verify permissions for the /mlt/install/dblog directory, if necessary.
su - mlt

7-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Creating a Replicated Environment

chmod 777 /mlt/install/install/dblog

exit
5. Run crlinks111 to create the SQL/*Net configuration files and to the
replication scripts.

NOTE:
This script should only be run on the master definition site machine.

The crlinks111 program will output a log file, crlinks111.log under the
directory /mlt/install/dblog
/mlt/install/dblog/crlinks111
6. Check the log files for errors and correct as appropriate.
more /mlt/install/dblog/crlinks111.log
7. Run crrep111 to setup up replication between all the LoopCare databases.

This script should only be run on the master definition site machine.

The crrep111 script takes some time to complete, so be patient. The crrep111
program will output a log file, crrep111.log,under the directory /mlt/install/
dblog.
/mlt/install/dblog/crrep111
1. Check the log files for errors and correct as appropriate.
more /mlt/install/dblog/crrep111.log

Automate Process of Occasionally, an Oracle job breaks. Follow this procedure on both master sites to
Unbreaking Oracle automate the process of unbreaking it. This procedure is required for the Hot
Jobs Standby Server feature.
1. Go the mlt/install directory.
cd /mlt/install
2. If replication is already set up in your system, re-compile the repadmin
package.
sqlplus repadmin/repadminpw @pk_repladmin
3. Schedule the job after setting up replication.
sqlplus repadmin/repadminpw @createUnbreakPush.sql

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-17

System Administration Guide Replication Administration
Propagating Changes Between Replicas

Propagating Changes Between Replicas

Overview When updates are made to the LoopCare database, which belongs to a
replication environment, the changes are ultimately propagated to all the master
sites.

The LoopCare database with replication is configured to asynchronously

propagate data-level changes between replication sites. The mechanism for this
process is called deferred transactions.

Deferred For asynchronous replication using deferred transactions, Oracle generates a

Transactions trigger and a stored procedure for each table belonging to the replicated
environment in order to support the replication of data-level changes. When a
change is made at one site, Oracle fires a generated trigger that builds a remote
procedure call to a packaged procedure at each of the remote sites.

The arguments passed via the remote procedure call contain the information that
will be necessary to apply the changes to each remote site. The remote procedure
call is stored in the local deferred transaction queue and can be viewed by
referencing the DEFTRAN view.

An illustration of asynchronous replication using deferred transactions can be

seen in Figure 7-3.

7-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Propagating Changes Between Replicas

Definition Site Master Site

MLTDBA Replication Group MLTDBA Replication Group

Change to TABLE-A Call Replication Package

Fire Replication Trigger

Replicate to TABLE-A

Deferred Transaction
Queue

Background Process: Background Process:

ora_snp0_mlta ora_snp0_mlta
ora_snp1_mlta ora_snp1_mlta

Figure 7-3. Example of asynchronous replication using deferred transactions

In Figure 6-3, when changes are made to a table, Oracle inserts the necessary
remote procedure calls into the deferred transaction queue, which can be viewed
by referencing the DEFTRAN view. Oracle references the ALL_REPSITES view
to determine the destinations of each of replicate sites to push this queue.

In separate transactions, the entries in the deferred transaction queue are

propagated to each replicated site. Oracle will not remove the transaction from the
local deferred transaction queue until it has been successfully propagated to all
the replicated sites. In the event that errors were encountered, the deferred
transaction will have an associated deferred transaction error, which can be
referenced from the DEFERROR view.

In a replication environment running normally, there should not be any deferred

transaction errors. In the event that there are deferred transaction errors, the
associated deferred transaction does not get applied to the targeted replication
site. As a result, the replication site with the deferred transaction errors will be out
of sync with each of the remaining databases in the replicated environment. Any

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-19

System Administration Guide Replication Administration
Propagating Changes Between Replicas

subsequent updates to the same record in the table with the error will result in
additional deferred transaction errors. Detail procedures are included in this
chapter outlining the steps required to resolve differences between databases due
to deferred transaction errors.

Keep in mind that when a transaction is added to the deferred transaction queue
at the local site, the remote procedures are not executed until the queue is
pushed. In order words, the job queue process controls propagation of deferred
transactions.

Job Queues Job queues are used to schedule periodic execution of PL/SQL code. To schedule
a job, a job queue must be designated and a frequency at which the job is to run.
Job queues can be altered, disabled, or deleted as needed.

Associated with the job queue are the background processes, called SNP
background processes. For each job queue, there is a separate background
process running on the Unix server. The SNP processes will periodically wake up
and execute any queued jobs that are due to run.

SNP background processes differ from other Oracle background processes that
run on the Unix server. In the event that an SNP background process fails, the
database instance will remain running. Oracle is capable of restarting any failed
SNP background processes.

An instance can have up to thirty-six SNP processes, named SNP0 to SNP9 and
SNPA to SNPZ. In an instance have multiple SNP processes, the task of
executing queued jobs is shared across the processes, thereby, improving
performance.

The number of job queues and the interval to have the queue pushed is set by the
job queue parameters, JOB_QUEUE_PROCESSES and
JOB_QUEUE_INTERVAL, which is set in the Oracle parameters file for the
database instance.

For the LoopCare database configured with replication, there are two job queue
processes started for each instance. The job queue interval is set to five seconds,
thus simulating near real-time propagation of changes between each of the sites.

A job is labeled as either broken or not broken. In the event that Oracle has failed
to successfully execute a job after sixteen attempts, the job is labeled as broken.
Oracle will not attempt to run broken jobs. This is one reason for the LoopCare
utility, db_unbreakjobs, to run out of the Unix CRON facility. The “db_unbreakjobs“
attempts to determine whether any jobs have been labeled as broken. If a broken
job is found, the utility will call packaged procedures that will attempt to re-run the
job.

7-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Resolving Out-of-Sync Databases

Resolving Out-of-Sync Databases

Overview Because of the complex nature of replication, it is likely that replicated

environments will encounter troubles that will require the DBA to resolve. In the
event that the number of differences between the LoopCare databases in a
replicated environment is too great, there are several LoopCare utilities that can
be used to rectify the database differences.

Installation Before the DBA can begin to use the LoopCare utilities to preview and resolve
database differences, there are several installation steps that need to be
completed. All these steps can be performed to the Oracle database with no
impact to LoopCare.

A new tablespace will need to be created in the LoopCare database, which is

used by the utilities to determine differences between the databases for each of
the LoopCare tables. The tablespace will be called REPTBL and will reside under
the DB2 files system, /db2.

NOTE:
It is recommended that local backup/recovery utilities used in your
environment be reviewed to ensure that the new tablespace created in DB2
is properly handled. If necessary, update the scripts and perform any
required testing.

1. Login to the master definition site machine as user oracle:

su - oracle
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Change to the installation directory:
cd /mlt/install
4. Create the REPTBL tablespace for the LoopCare database.
/mlt/install/crreptbl /db2
5. Verify no Oracle errors were reported in the log file.
grep”ORA” /mlt/install/dblog/crreptbl_mlt??.log
6. Verify the new tablespace exists under the DB2 file system.
ls -lt /db2/mlt??_reptl.dbf
7. Verify whether local scripts need to be modified.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-21

System Administration Guide Replication Administration
Resolving Out-of-Sync Databases

Once the tablespace has been created, it must be initialized with information
related to each of the tables. The following steps will need to be completed before
the DBA can begin to use the utilities.
1. Login to the master definition site machine as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Change to the conversion directory:
cd /mlt/install/conv
4. Initialize the REPTBL tablespace.
/mlt/install/conv/cr_repl_diff_tables -p <repadminpw>
where <repadminpw> refers to the password for the
“repadmin“ account.
5. Verify no Oracle errors were reported in the log file.
grep “ORA” /mlt/install/conv/logs/
cr_repl_diff_tables.log

NOTE:
You will see errors for ORA-00942 indicating a table or view does not exist.
These errors can be ignored because the objects are dropped before being
created.

Preview Mode To check the differences between two LoopCare databases in a replicated
environment, the LoopCare utility, chk_dbdiff, can be used. Before executing the
utility, you will need to determine which of the two databases contains the most
current information. The database with the most accurate information is referred
to as the “truth“ site. The other site which needs to have database differences
resolve is referred to as the comparison site.

Since LoopCare users should only be making changes to the LoopCare database
from the master definition site, the most accurate information will usually be the
master definition site. Therefore, the “truth“ site will typically be the same as the
master definition site.

The resulting output of the utility will be a log summary identifying each of the
LoopCare database tables that are out-of-sync with the “truth“ site. Each of these
tables will need to be resolved using additional utilities that are available with
LoopCare.

7-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Resolving Out-of-Sync Databases

Details about the exact differences between each of the tables can be extracted
by designating the appropriate options. Additional processing time will be needed
to report all the records that differ between the tables that are out-of-sync.

If specified in the system, notification can be sent electronically to the “mlt“ user
account. The default is to send this information to no one, the administrator must
set up if they want the output to be sent to the “mlt“ user account. Additionally,
users can review the log summary by viewed the log file from the appropriate
directory.

A summary of each of the options for the "chk_dbdiff" utility is provided below:
-c [ ORACLE SID of the comparison site ]
-d [ Y to log table differences at row level, N to suppress table differences
at row level ]
-l [ The absolute directory path under which the logfile is to be created ]
-m [ mltdba password ]
-n [ e-mail address to notify the outcome of the script ]
-p [ repadmin password ]
-r [ ORACLE SID of the reference site ( truth site ) ]

The following outlines the flow-through for processing using the "chk_dbdiff"
utility:
Step 1:
For each replicated table in the LoopCare database, utility will start by
truncate the corresponding temporary tables in the REPTBL tablespace.
Afterwards, the utility calls the packaged procedures
DBMS_RECTIFIER_DIFF.DIFFERENCES to determine the row
differences between reference (truth) site and comparison site for the given
table. If differences are found, the packaged procedure populates the row
differences in the another corresponding temporary table under the
REPTBL tablespace.
Step 2:
Once each of the LoopCare tables in the replicated environment has been
examined, the utility will query the temporary tables to determine all the
tables that are different between the reference (truth) site and the
comparison site. Each of the LoopCare tables with differences are
recorded in the summary log.
Step 3:
If the detail (-d) option has been specified with the argument "Y", then each
table that has been identified as being different between the LoopCare
databases is parsed by calling the utility, disp_dbdiffcol. The disp_dbdiffcol
utility will determine the differences fore each record. A summary log
containing the differences is generated for review.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-23

System Administration Guide Replication Administration
Resolving Out-of-Sync Databases

Step 4:
With all the processing completed, the final step is an electronic notification
to the defined list of email addresses. The mail message will outline the
tables that contain differences between the reference (truth) site and the
comparison site. All the log files are captured in the directory designated by
the "-l" option at the time the command was invoke.

The following outline the steps to successfully determine the LoopCare tables that
are out-of-sync between the LoopCare databases.
1. Login to the master definition site machine as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Change to the LoopCare replication utility directory:
cd /mlt/ubin
4. Execute the utility to preview the differences between the databases.

NOTE:
See the Note on page 7-25.

./chk_dbdiff -r <truth site> -c <comparison site> -d Y

-l /mlt/install/dblog -m <mlt passwd> -p <repadmin
passwd> -n mlt
5. Verify results recorded in the summary log.
pg /mlt/install/dblog/chk_dbdiff.log
6. Verify results mailed to "mlt" user account.
mail

Resolve Mode To resolve the differences between two LoopCare databases in a replicated
environment, the LoopCare utility, fix_dbdiff, can be used. Before executing the
utility, you will need to determine which of the two databases contains the most
current information. The database with the most accurate information is referred
to as the "truth" site. The other site which needs to have database differences
resolve is referred to as the comparison site.

Since LoopCare users should only be making changes to the LoopCare database
from the master definition site, the most accurate information will usually be the
master definition site. Therefore, the "truth" site will typically be the same as the
master definition site.

7-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Resolving Out-of-Sync Databases

The resulting output of the utility will be a log summary identifying each of the
LoopCare database tables that are out-of-sync with the "truth" site. Each of these
tables will need to be resolved using additional utilities that are available with
LoopCare.

Details about the exact differences between each of the tables can still be
extracted by designating the appropriate options. Additional processing time will
be needed to report all the records that differ between the tables that are out-of-
sync.

Notification is sent electronically to the email address specified in the -n option

below. Additionally, users can review the log summary by viewed the log file from
the appropriate directory.

A summary of each of the options for the "fix_dbdiff" utility is provided below:
-c [ ORACLE SID of the comparison site ]
-d [ Y to log table differences at row level, N to suppress table differences
at row level ]
-l [ The absolute directory path under which the logfile is to be created ]
-m [ mltdba password ]
-n [ e-mail address to notify the outcome of the script ]
-p [ repadmin password ]
-r [ ORACLE SID of the reference site ( truth site ) ]

Processing Using The following outlines the flow-through for processing using the "fix_dbdiff" utility:
the fix_dbdif Utility
NOTE:
Before using the fix_dbdiff utility, make sure that all the following conditions
have been met:

• All connections to oracle on all machines are idle:

— Groups are down.
— No OAM sessions are active.
— No sqlplus sessions are active.
Step 1:
The utility starts off by suspending replication between each of the
replicated sites. This is also referred to as quiescing replication. During this
time that replication has been suspended, there will be no updates allowed
to any of the LoopCare databases. However, the database is still available
and information can be searched/queried.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-25

System Administration Guide Replication Administration
Resolving Out-of-Sync Databases

Step 2:
With replication suspended, this next step is to call the "chk_dbdiff" utility to
determine any row differences between reference (truth) site and
comparison site for the given table. If differences are found, the packaged
procedure populates the row differences in the another corresponding
temporary table under the REPTBL tablespace.
Step 3:
Resolution of differences is performed. First, all the constraints are
disabled on the comparison site. Next there are calls to packaged
procedures that are executed. The DBMS_RECTIFIER_DIFF.RECTIFY
procedure is executed to resolve differences for the designated table. Each
of the tables identified with differences by the "chk_dbdiff" utility is
resolved. Once all differences are resolved, the constraints are enabled.
Step 4:
With the differences resolved between the databases in the replicated site,
the deferred transaction errors logged in the DEFERROR view can be
purged. In this step of the utility, all the deferred transactions and any
associated deferred transaction errors are removed.
Step 5:
The utility completes with resuming replication between each of the
replicated sites. At this point, all the tables should be back in sync with the
reference (truth) site.

The following outline the steps to successfully determine the LoopCare tables that
are out-of-sync between the LoopCare databases.
1. Login to the master definition site machine as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Change to the replication utility directory:
cd /mlt/ubin
4. Execute the utility to resolve the differences between the databases.

NOTE:
Before using the fix_dbdiff utility, refer to the note on page
page 7-25.

./fix_dbdiff -r <truth site> -c <comparison site> -d Y -l /mlt/install/dblog -m

<mlt passwd> -p <repadmin passwd> -n ml
tVerify results recorded in the summary log. pg /mlt/install/dblog/
fix_dbdiff.log

7-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Resolving Out-of-Sync Databases

5. Verify results mailed to "mlt" user account.

mail

Using the The validateReplicationObjects utility compares the replication objects listed in the
validateReplication Oracle data dictionary with the list maintained by Loopcare. To run this utility,
Objects Utility execute:
validateReplicateObjects -s <system password> -p <repadmin password>
1. Login to the master definition site machine as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Change to the install directory:
cd /mlt/install
4. Execute the utility.
/mlt/install/validateReplicationObjects -s <system password>
-p <repadmin password>
5. The utiltiy looks for tables that should be replicated but aren't.
• It displays the following message if it finds any:
The following tables lack replication support:
• Press enter to page through this list of tables.
• If there are no missing tables, the utility displays:
No replication objects missing for existing tables.
6. Next, the utility looks for tables that still have replication objects but should
no longer be replicated.
• It displays the following message if it finds any:
The following tables are no longer replicated and need to be
removed:
• Press enter to page though the list of tables.
• If no tables are found, the following message is displayed:
No replication objects exist for old tables.
7. Finally, if the utility detects any discrepancies, it displays the following
message:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-27

System Administration Guide Replication Administration
Resolving Out-of-Sync Databases

You can execute sqlplus repadmin/repadmin @/mlt/install/conv/sql/

REPSUPPORT.sql
• All connections to databases must be down. It is recommended that
all MLT groups, OA&M sessions, and sqlplus sessions be brought
down, since the REPSUPPORT sql script waits until all processes
on all replicated databases terminate.

Validation With the ability to preview and resolve database differences between LoopCare
database, it will also be necessary to verify there are no other differences.

There are a couple of ways this validation process can be done and both are
outlined below.

One method is to check each of the LoopCare tables reported in the

"chk_dbdiff.log" file for differences using the "db_diff" command. These steps
have been outlined below:
1. Login to the master definition site machine as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Change to the utility directory:
cd /mlt/ubin
4. Run db_diff to query the differences between two tables that are replicated
on two different sites. The query will list 3 types of differences. It will list the
primary key values of rows in the first database that does not exist in the
second database and vice-versa. It will also list rows in the two databases
with the same primary key values but different secondary values.

Example: Suppose we want to query the differences between the adef_switch table owned
by the mltdba user between the databases mlt50 and mlt51.

Following are the user prompts and user information from cfgrep. "111" is the
process id of this execution of cfgrep:
/mlt/ubin/db_diff mlt50 mlt51 <repadminpw> mltdba
adef_switch

Creating views for table ëmltdba.work_switchí

differences ...

7-28 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Resolving Out-of-Sync Databases

PL/SQL procedure successfully completed.

PKey values of ëmltdba.adef_switchí in ëmlt50í not in

‘mlt51’:
no rows selected

PKey values of ëmltdba.adef_switchí in ëmlt51í not in

‘mlt50’:
no rows selected

PKey values of ëmltdba.adef_switchí with different

secondary:
no rows selected

Another method is to re-execute the "chk_dbdiff" utility. The log file should report
that there were no tables with differences between the LoopCare databases.
These steps have been outlined below:
1. Login to the master definition site machine as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Change to the replication utility directory:
cd /mlt/ubin
4. Execute the utility to preview the differences between the databases.
./chk_dbdiff -r <truth site> -c <comparison site> -d Y
-l /mlt/install/dblog -m <mlt passwd> -p <repadmin
passwd> -n mlt
5. Verify results recorded in the summary log.
pg /mlt/install/dblog/chk_dbdiff.log

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-29

System Administration Guide Replication Administration
Troubleshooting Replication

Troubleshooting Replication

Overview Because of the complex nature of replication, it is likely that replicated

environments will encounter troubles that will require the DBA to resolve. The
troubles may be related to a number of areas related to replication. Some of these
troubles include:
• Invalid/missing replication objects, e.g., replication package/trigger
• Invalid replication status, e.g., replication quiesced
• Deferred transaction errors
• Failed Job Queue process

Managing As outlined previously, each replicated environment will have two kinds of
Replication Objects replication sites: master definition site and master site.

In a LoopCare environment that uses replication, the ALL_REPSITES table can

be viewed to determine each of the replication sites and their operational status.
The following outlines the steps to take to verify that replication sites exist and are
functioning normally.
1. Login to each server as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
4. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)
sqlplus repadmin/repadminpw
5. Verify each replicated site.
SQL> select dblink, masterdef from all_repsites;
For example, your environment may display:
DBLINK
---------------
M

7-30 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Troubleshooting Replication

-
MLT50.WORLD
Y

MLT56.WORLD
N
6. Verify the status of replication environment.
SQL> select status from all_repgroup;
STATUS
---------
NORMAL
7. Exit the SQL/*Plus session.
SQL> exit.

Verification Using In a LoopCare environment with replication, there is a replication group for which
the all the replication objects belong under, called MLTDBA. The ALL_REPGROUP
All_REPGROUP view can be used to verify the replication group and its current status.
View 1. Login to each server as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
4. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)
sqlplus repadmin/repadminpw
5. Verify each replicated group, MLTDBA, and its status.
SQL> select gname, status masterdef from all_repgroup;
GNAME STATUS
------------------------------ ---------
MLTDBA NORMAL
6. Exit the SQL/*Plus session.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-31

System Administration Guide Replication Administration
Troubleshooting Replication

SQL> exit.

Verification Using Since the LoopCare environment using replication will propagate all changes
the All_REPPROP across to each replicated site using asynchronous replication. The
View ALL_REPPROP view can be used to verify the propagation method used for each
replicated table.
1. Login to each server as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
4. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)
sqlplus repadmin/repadminpw
5. Verify the method which changes get propagated to other replicated sites.
You will need to record the defined value of ORACLE_SID for your
environment.
SQL> select distinct how
2 from all_repprop
3 where dblink = ë${ORACLE_SID}.WORLDí;

HOW
-------------
ASYNCHRONOUS
6. Exit the SQL/*Plus session.
SQL> exit.

Verification Using Another useful check is to verify each of the replication objects and their status.
the This information can be collected from the ALL_REPOBJECT table.
All_REPOBJECT 1. Login to each server as user mlt:
View
su - mlt

7-32 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Troubleshooting Replication

2. Execute the oraclevars file:

. /mlt/config/oraclevars
3. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
4. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)
sqlplus repadmin/repadminpw
5. Verify each of the replication objects and its status.
SQL> select status, count(*)
2 from all_repobject
3 group by status;

STATUS COUNT(*)
--------- ----------
VALID 1530

NOTE:
The total number of replication objects will vary depending on the release of
the LoopCare software. To verify the total count of replication objects, refer
to the Release Notes for the release of LoopCare software installed on your
system.

6. Exit the SQL/*Plus session.

SQL> exit.

Verification Using This script displays replication information for LoopCare systems that have been
the Replchk Utility configured to replicate between a designated master definition site and one or
more master sites. Specifically, it provides:
• information the administrator can use to validate the master definition site
and any master sites
• replication counts that indicate whether or not there are any replication
objects in the process of being built, replication deferred transactions, or
deferred errors
• job queue status that identifies Oracle jobs that have failed

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-33

System Administration Guide Replication Administration
Troubleshooting Replication

This utility resides in /mlt/ubin/replchk.

Usage: ./replchk {-cjlps}

where: -c reports only the replication counts
-j reports only the replication job queue
-l identify the replication user login
-p identify the replication user password
-s reports the replication site information
By default it reports all replication information.

Managing Deferred Oracle will always detects and logs any update conflicts, uniqueness conflicts,
Transactions and delete conflicts. Oracle provides build-in mechanisms to detect and resolve
conflicts that arise during normal operations of a replicated environment.

The purpose of conflict resolution is to ensure data convergence and to avoid

having cascading errors. Convergence ensures that all the replicated sites have
the same data. Avoiding cascading errors ensures the system to run smoothly.

With LoopCare running in a replicated environment, where changes are

propagated asynchronously, conflicts will occur if two or more replicated sites
update the same replicated data. In these situations, a deferred transaction will
not be applied to the database and an associated deferred transaction error will
be generated.

It is the responsibility of the DBA to monitor the deferred transaction process on

each of the LoopCare systems in a replication environment. The following
procedures outlines the steps to be completed to check the deferred transactions.
Additionally, the procedure to resolve the deferred transaction errors is included.
1. Login to each server as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
4. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)
sqlplus repadmin/repadminpw

7-34 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Troubleshooting Replication

5. Check for the number of deferred transactions and errors.

SQL> select count(*)
2 from deftran;
COUNT(*)
----------
0

SQL> select count(*)

2 from deferror;

COUNT(*)
----------
0

NOTE:
The number of deferred transactions and deferred errors are typically zero
on all the LoopCare systems. Transactions are applied in near real-time to
each replicate site because the job queue interval is every five seconds.

If there is load on the system with SAM transaction and/or OAM updates,
you will likely see the count for deferred transaction greater than zero in the
DEFTRAN view. However, as the transactions are sent to each of the
replicated sites, Oracle will remove the entry from the DEFTRAN view.
Therefore the count in DEFTRAN should decrease back down to zero.
In the event that a deferred transaction on a system cannot be applied due
to a conflict, Oracle will generate an associated deferred transaction error
in the DEFERROR table. The following is an example where databases are
out-of-sync because the deferred transactions have resulted in deferred
transaction errors:
SQL> select count(*)
2 from deftran;

COUNT(*)
----------
22

SQL> select count(*)

2 from deferror;

COUNT(*)

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-35

System Administration Guide Replication Administration
Troubleshooting Replication

----------
22
6. If there are no deferred transactions errors, exit the SQL/*Plus session.
Otherwise proceed to Step 7.
SQL> exit.
7. Determine the error messages associated with each of the deferred errors.
SQL> select distinct error_msg
2 from deferror;
For example, the results may return:
ERROR_MSG
----------------------------------------------
ORA-01403: no data found
ORA-06512: at "MLTDBA.ACT_THDB$RP", line 58
ORA-01085: preceding errors in deferred rpc to
“MLTDBA.ACT_THDB$RP.REP_DELETE
8. Determine the tables that have not been updated due to pending errors
associated with the deferred transactions.
SQL> select distinct substr(PACKAGENAME, 1,
length(PACKAGENAME)-3)
2 from defcall;
For example, the results may return:
SUBSTR(PACKAGENAME,1,LENGTH(PACKAGENAME)-3)
----------------------------------------------
ACT_THDB
9. Exit the SQL/*Plus session.
SQL> exit.
10. Change to the replication utility directory:
cd /mlt/ubin
11. On the master definition site machine, execute the utility to preview the
differences between the databases.
./chk_dbdiff -r <truth site> -c <comparison site> -d Y
-l /mlt/install/dblog -m <mlt passwd> -p <repadmin
passwd> -n mlt
12. Verify results recorded in the summary log to be consistent with results
from Step 8.
pg /mlt/install/dblog/chk_dbdiff.log

7-36 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Troubleshooting Replication

13. On the master definition site machine, execute the utility to resolve the
differences between the databases.

NOTE:
Before using the fix_dbdiff utility, refer to the note on page
page 7-25.

./fix_dbdiff -r <truth site> -c <comparison site> -d Y

-l /mlt/install/dblog -m <mlt passwd> -p <repadmin
passwd> -n mlt
14. Verify results recorded in the summary log.
pg /mlt/install/dblog/fix_dbdiff.log
15. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)
sqlplus repadmin/repadminpw
16. Verify deferred transaction have been removed and no pending errors
exist.
SQL> select count(*)
2 from deftran;

COUNT(*)
----------
0

SQL> select count(*)

2 from deferror;

COUNT(*)
----------
0
17. Exit the SQL/*Plus session.
SQL> exit.

Managing Job Since the method of propagating changes to other LoopCare databases in a
Queues replicated environment is deferred transactions, the job queue capabilities play a
very important role in routing these calls back and forward.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-37

System Administration Guide Replication Administration
Troubleshooting Replication

The following steps can be completed to check the status of each of the job
queues.
1. Login to each server as user mlt:
su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
4. Execute the job status utility.
/mlt/ubin/db_jobstatus <repadminpw>

5. Verify each jobs have zero failures (F) and no broken jobs (B). In the event
that there are troubles with the job queue, you will see results similar to the
following examples.

The following example indicates troubles with the second job queue on the MLT50
server. After attempting 16 times to send a deferred transaction to MLT56, the job
was marked as broken.

7-38 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Troubleshooting Replication

The following example indicates troubles as the above trouble but in the opposite
direction.

Once a job has been marked as broken, Oracle will not attempt to execute the job.
You will need to mark the job as not broken or force the job to be executed.
1. If a job has been marked as broken, execute the mlt utility to force the job
to be executed.
/mlt/ubin/db_unbreakjobs <repadminpw>
2. Verify that the status of the job queue is normal.
/mlt/ubin/db_jobstatus <repadminpw>

There are also cases where the job queue appears to be running but deferred
transactions are not being sent to the replicated systems. This situation does not
occur frequently and usually goes undetected until users begin to notice data
getting out of sync between databases or when the administrators notices a large
number of deferred transaction being queued with no deferred transaction errors.
Under this situation, the job queue can be deleted and recreated.

Procedure The following procedure outline the steps to determine the above condition and
steps on stopping/starting the job queue.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-39

System Administration Guide Replication Administration
Troubleshooting Replication

1. Login to each server as user mlt:

su - mlt
2. Execute the oraclevars file:
. /mlt/config/oraclevars
3. Verify that Oracle variables are all correctly defined.
echo $ORACLE_SID
echo $ORACLE_HOME
echo $PATH
4. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)
sqlplus repadmin/repadminpw
5. Check for the number of deferred transactions and errors.
SQL> select count(*)
2 from deftran;

COUNT(*)
----------
0

SQL> select count(*)

2 from deferror;

COUNT(*)
----------

0
6. Exit the SQL/*Plus session.
SQL> exit.
7. Repeat the above SQL statements periodically on your system. It is not
unusual to have some deferred transaction on the queue with no deferred
transaction errors. However, the number of deferred transactions should
return back to zero. A clear example of a troubled job queue is when the
number of deferred transaction is continually increasing and no deferred
transaction errors are logged. If these symptoms exist on you system,
proceed with the next steps to stop/start the job queue.
8. Open a SQL/*Plus session using the "repadmin" account. (Substitute
"repadminpw" with the correct password for the "repadmin" user account.)

7-40 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Troubleshooting Replication

sqlplus repadmin/repadminpw
9. Determine the destination database of the deferred transactions.
SQL> select distinct deferred_tran_db
2 from deftran;
For example, the above SQL statement may return:
DEFERRED_TRAN_DB
-------------------
MLT56.WORLD

NOTE:
Record the ORACLE SID of the destination database. In the above case,
the ORACLE SID would be MLT56.

10. Drop the associated job queue.

SQL> exec Pk_Repadmin.StopReplSite
('<DEFERRED_TRAN_DB>');
For example,
exec Pk_Repadmin.StopReplSite ('MLT56');

NOTE:
Be sure to designate the correct ORACLE SID of the destination database.
Refer to Step 9.

11. Create the associated job queue.

SQL> exec Pk_Repadmin.StartReplSite
('<DEFERRED_TRAN_DB>', '5');
For example,
exec Pk_Repadmin.StartReplSite ('MLT56', '5');

NOTE:
Be sure to designate the correct ORACLE SID of the destination database.
Refer to Step 9.

12. Exit the SQL/*Plus session.

SQL> exit.
13. Verify that the status of the job queue is normal.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-41

System Administration Guide Replication Administration
Troubleshooting Replication

/mlt/ubin/db_jobstatus <repadminpw>

14. Repeat Steps 4-6 to verify that the number of deferred transactions are
gradually decreasing.

7-42 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Disabling OAM and MLT UIP Functionalities

Disabling OAM and MLT UIP

Functionalities

Overview In a replicated environment, it is recommended that OAM and MLT UIP changes
be made in the Master Definition site only and not in the replicated sites (master
sites). To disable these capabilities in the replicated sites, change the permissions
of the files that enable this functionality by executing the following commands:
• chmod 000 /mlt/ubin/oam
• chmod 000 /mlt/ubin/MLT
• chmod 000 /mlt/ubin/mltuip

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-43

System Administration Guide Replication Administration
Warm Standby Server Configuration

Warm Standby Server Configuration

Overview The Warm Standby Server Configuration process supports a switch to a standby
server that has a current Oracle production database. It requires the execution of
the following procedures:
• Setting up nightly cold Oracle database backups
• Setting up an RHOST (remote host) file to enable the execution of RCP
(remote copy).
• Setting up a CRON job to perform database backups.

The Hot Standby Server feature (#326) supercedes the Warm Standby feature.

Utilities The warm standby procedure uses the following utilities:

/mlt/install/go_standby
/mlt/install/recoverdb

The "go_standby" retrieves Oracle backup files from a designated LoopCare

server and places them in the local backup directory. The "recoverdb" program
later moves this copy of the database to make it available on the standby
LoopCare server. "oracle" executes these utilities since it is the owner of the
LoopCare database.

Usage:

oracle: ./recoverdb -?

usage: ./recoverdb {-a| -d BACKUP_DIR |-b|-r|-B|-C|-T}

-a automatically recover database files

-b indicates that BATCH is configured

-d specify the BACKUP_DIR directory

-o specify Oracle BKUP type: {COLD|HOT|EXPORT}.

-r specify the removal of existing data files

-t specify the transaction ARCHIVE_DIR directory

-A indicates that ACCLOG is configured.

7-44 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Warm Standby Server Configuration

-B indicates that BMDB is configured

-C indicates backup files are GZIPed

-T indicates that TARE is configured

oracle: ./go_standby -?

usage: ./go_standby -p PRODUCTION_SERVER -s STANDBY_SERVER {-b| -d

BACKUP_DIR |- B|-C|-T}

-p specify the HOST name of production LoopCare server

-s specify the HOST name of the standby LoopCare server

-b indicate whether BATCH is configured

-a specify the ARCHIVE_DIR directory

-d specify the BACKUP_DIR directory

-S specify a secondary BACKUP_DIR directory

-o specify Oracle BKUP type: {COLD|HOT|EXPORT}

-A indicate whether ACCLOG is configured.

-B indicate whether BMDB is configured

-C indicates backup files are GZIPed

-T indicate whether TARE is configured

The following variables must be set in /mlt/config/oraclevars in order for the warm
standby process to support certain features or capabilities. See the Installation
Guide for information on setting these variables.

Supported Feature/
Variable Capability
BMDB_TBL BMDB

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-45

System Administration Guide Replication Administration
Warm Standby Server Configuration

Supported Feature/
Variable Capability
BATCH_TBL Batch
TAF_TBL TAF
ACCLOG_TBL Access Log (in
Security/Tester
Administration feature)

Set Up Cold Oracle This procedure assumes that the LoopCare application is running.
Backups
Set up Archive Mode.
1. Login as superuser.
2. Make certain that the following entry exists in /etc/group:
baseadm::200:mlt,base,oracle
If only "baseadm::200:" exists, add users "mlt,base,oracle" to group.
3. Setup up Oracle Archive logging.
• Mount CD-ROM with SilverCD media
• Change to installation directory
• Execute:
For HP-UX: cd /cd_rom/install/HP
For SUN: cd /cd_rom/disk1/install/SUN
• Execute: ./install_loopcare -A ARCHIVE
PROMPT:
Enter the database archive log destination [/db4/
archive_mlt50]:
4. Verify archiving is enabled.
su - oracle
sqlplus /nolo
SQL> connect / as sysdba;
Connected.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /db4/archive_mlt50

7-46 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Warm Standby Server Configuration

Oldest online log sequence 63

Next log sequence to archive 65
Current log sequence 65

SQL> alter system switch logfile;

Statement processed.
SQL> exit
ls -lt /db4/archive_mlt50

Set up Oracle backups.

5. Login as superuser.
6. Setup up Oracle backups.
• Mount CD-ROM with SilverCD media
baseadm::200:mlt,base,oracle
If only "baseadm::200:" exists, add users "mlt,base,oracle" to group.
• Change to installation directory;
Execute: For HP-UX: cd /cd_rom/install/HP
For SUN: cd /cd_rom/disk1/install/SUN
• Execute: ./install_loopcare -A DBBACKUP
PROMPTS:
Enter the ORACLE SID [mlt50] [Q|Quit]?
Enter the ORACLE HOME [/oracle/app/oracle/product/
9.2.0] [Q|Quit]?

Specify the password for SYSTEM database

account[manager]:
Enter the database archive destination [/db4/
archive_mlt50/]:
Enter the database backup destination [/dbbackup]:
Enter the backup type [HOT|COLD] for Monday: cold
Should a database export be performed [YES|NO] for
Monday: yes
Enter the backup type [HOT|COLD] for Tuesday: cold
Should a database export be performed [YES|NO] for
Tuesday: yes
Enter the backup type [HOT|COLD] for Wednesday:
cold

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-47

System Administration Guide Replication Administration
Warm Standby Server Configuration

Should a database export be performed [YES|NO] for

Wednesday: yes
Enter the backup type [HOT|COLD] for Thursday:
cold
Should a database export be performed [YES|NO] for
Thursday: yes
Enter the backup type [HOT|COLD] for Friday: cold
Should a database export be performed [YES|NO] for
Friday: yes
Enter the backup type [HOT|COLD] for Saturday:
cold
Should a database export be performed [YES|NO] for
Saturday: yes
Enter the backup type [HOT|COLD] for Sunday: cold
Should a database export be performed [YES|NO] for
Sunday:
7. Verify backup scripts.
su - oracle
cd /oracle/app/oracle/product/9.2.0/tools/db_mgmt/
backup
./dbbackup -c -S mlt50 manager

8. Verify that the backup files were created.

ls -lt /dbbackup/
ls -lt /dbbackup/datafiles
ls -lt /dbbackup/parameters
ls -lt /dbbackup/control
ls -lt /dbbackup/exports
ls -lt /dbbackup/mlt50

Set Up RHOST file This procedure enables the execution of RCP, required for retrieving files.
1. Login as superuser on the primary LoopCare server
2. Create file: /etc/hosts.equiv.
3. Create entries:
SECONDARY_HOST mlt
SECONDARY_HOST oracle

7-48 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Warm Standby Server Configuration

4. Login as superuser on the secondary LoopCare server,

5. Create file: /etc/hosts.equiv
6. Create entries
PRIMARY_HOST mlt
PRIMARY_HOST oracle

NOTE:
PRIMARY_HOST refers to the HOSTNAME of the primary LoopCare
server. SECONDARY_HOST refers to the HOSTNAME of the secondary
LoopCare server.

7. Verify an entry exists in /etc/hosts for the PRIMARY_HOST and

SECONDARY_HOST for each of the systems.
8. Verify ability to RCP files,
From PRIMARY_HOST:
rcp SECONDARY_HOST:/mlt/exec/.profile /tmp/
TESTFILE
pg /tmp/TESTFILE
From SECONDARY_HOST:
rcp PRIMARY_HOST:/mlt/exec/.profile /tmp/TESTFILE
pg /tmp/TESTFILE

Set Up Cron Job This procedure executes "go_standby" after production COLD backups have
completed.
1. Login as superuser on the STANDBY LoopCare server.
2. Setup CRON entry for ORACLE.
• Execute:
crontab -l oracle >/tmp/oracle.cron
• EDIT "oracle.cron" to add the following line
00 4 * * * ksh /mlt/install/go_standby -p
PRIMARY_HOST -s SECONDARY_HOST
• Execute:
crontab /tmp/oracle.cron

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-49

System Administration Guide Replication Administration
Warm Standby Server Configuration

NOTE:
PRIMARY_HOST refers to the HOSTNAME of the primary LoopCare
server. SECONDARY_HOST refers to the HOSTNAME of the secondary
LoopCare server. BE CERTAIN TO SET ALL THE OPTIONS THAT BEST
REFLECT YOUR OPERATING ENVIRONMENT.

3. Verify that there will not be any troubles with CRON entry.
• Execute:
su - oracle
cd /mlt/install
./go_standby -p PRIMARY_HOST -s SECONDARY_HOST
4. Verify that recent changes from production server are accessible from the
standby server.

7-50 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Replication Administration System Administration Guide
Hot Standby Server Configuration

Hot Standby Server Configuration

Modify MLT.gdf 1. On on the primary server, LM50, add entries for the bridge reader and
File writer in the MLT.gdf file. The example below assumes that the server ID
for the secondary server is L51. The -t option is optional.
R9:/mlt/bin/bridger -t,3,-l,51 brir51
R9:/mlt/bin/bridgew -t,3,-l,51 briw51
2. Add the same entries on the secondary server.
R9:/mlt/bin/bridger -t,3,-l,50 brir50
R9:/mlt/bin/bridgew -t,3,-l,50 briw50
3. Add the following line in MLT.gdf for both machines near the end of the file:
E:/mlt/ubin/cleanBridgePortTable dummy brCln

Set Up Replication To set up replication for the Hot Standby, you must include the procedure outlined
in Automate Process of Unbreaking Oracle Jobs on page 7-17.

Check Server Status The /mlt/reports/ServerStatus.txt file, located on both the primary and secondary
server, holds messages about the status of the server. These messages indicate,
for example, whether the LoopCare application on the server is up or down.
Check the messages in these files to determine if a server is in fail over or active
mode or in a transitional state.

Set Up Email To set up email notification of server fail over and recovery,
Notification 1. Copy /mlt/webgui/loopcare/WEB-INF/classes/bundles/Loopcare/
LCServerStatusMailWriter.properties to /mlt/webgui/loopcare/WEB-INF/
classes/bundles/Loopcare/UserServerStatusMailWriter.properties
2. Edit the /mlt/webgui/loopcare/WEB-INF/classes/bundles/Loopcare/
UserServerStatusMailWriter.properties file. This file contains instructional
information.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 7-51

System Administration Guide Replication Administration
Hot Standby Server Configuration

7-52 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification,
Configuration, and Customization 8

Contents

• Introduction 8-2
Web Server Products 8-3
• HP-UX 10.20 Systems 8-3
• HP-UX 11.00 and HP-UX 11.11 Systems 8-6
• Sun Solaris Systems 8-8
GUI Configuration 8-9
• System Configuration for GUI 8-9
• Group Administration 8-12
• User Administration 8-14
GUI Customization 8-15
• Introduction 8-15
• Customizing the GUI for Groups of Users 8-16
• Customizing the GUI for a User 8-18
• Modifying Logo GIF Files 8-20
• Customizing the Welcome to LoopCare Page 8-22
• Technical Support Page Customization 8-24
• Maintain Locally Managed VER Code and AID Files 8-25
• Modifying the Tip, Ring, and Ground Labels 8-26

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-1

System Administration Guide End User GUI Verification, Configuration, and
Customization

Introduction

Preview The LoopCare End User Graphical User Interface (GUI) is automatically
configured for all new installations of the LoopCare system. In the event that the
LoopCare system was installed prior to the availability of the End User GUI,
several steps are required before the End User GUI can be used. The necessary
procedures are outlined in the sections below.

8-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
HP-UX 10.20 Systems

Web Server Products

Introduction The LoopCare End User GUI requires the use of third-party products that need to
be installed and active on the LoopCare server. The products required and the
level of support software will vary. Please refer to the release letter for the current
version of LoopCare release running on your system. Additional installation
information regarding these products can be reviewed in the LoopCare CD
Installation Guide.

Assuming that the LoopCare system is installed with the appropriate web server
related products, the following procedures help identify whether the appropriate
Unix processes are active in order to properly access the LoopCare End User GUI
application.

HP-UX 10.20 Systems

Verify the Tomcat For HP-UX 10.20 systems, the Tomcat product is used to serve the LoopCare End
Product User GUI. Use the following procedure to verify the installation of the product.
1. Login as root.
2. Execute the following command to verify the Tomcat product installation.
ls -CF /opt/tomcat

NOTE:
The /opt/tomcat/conf/tomcat-apache.conf file is the configuration
file that defines various settings that are important to serving the LoopCare
End User GUI application.

The /opt/tomcat/logs directory will contain log information that may be

helpful in troubleshooting any End User GUI application access errors.
3. Verify that there are RC start and stop scripts installed for the Tomcat
product and the Tomcat product is automatically started during system
reboots.
For example:
cd /sbin
find. -name "*tomcat" -print
The following results should be displayed.
./init.d/tomcat
./rc1.d/K115tomcat

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-3

System Administration Guide End User GUI Verification, Configuration, and
Customization

./rc2.d/S115tomcat
4. Execute the following command to verify that the Tomcat product is
running.
ps -eaf |grep java
Output similar to the following should be displayed on one line.
root 689 1 0 Mar 16 ? 3:55 /opt/java/
bin/PA_RISC/green_threads/java -ms32m -mx32m -Dtom

NOTE:
The process owner may be "root" or "base" depending on the version of the
RC start/stop script installed. If owner is changed, be certain to reflect the
changes in the owner for the directory /mlt/webgui/loopcare/xlate
and files listed this directory.

Verify Netscape For HP-UX 10.20 systems where Wideband Graphical results are possible, the
Fasttrack Netscape Fasttrack product is also used with the LoopCare End User GUI. This is
not applicable to all environments but if it is applicable to yours, use the following
procedures to verify the installation of the product.
1. Login as root.
2. Execute the following command to verify Netscape product installation;
ls -CF /opt/netscape/fasttrack

NOTE:
The /opt/netscape/fasttrack/httpd-[SYSTEM]/config/
obj.conf file is the configuration file that defines various settings that are
important to serving graphical results from the LoopCare End User GUI
application. Be sure to substitute [SYSTEM] with the host name of the
LoopCare server.

The host name of the LoopCare server can be determined by using the
command.
hostname
The /opt/netscape/fasttrack/httpd-[SYSTEM]/logs directory
contains log information that may be helpful in troubleshooting any End
User GUI application access errors.
3. Verify that there are RC start and stop scripts installed for the Netscape
product and the Netscape Fasttrack product is automatically started during
system reboots.
For example:

8-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
HP-UX 10.20 Systems

cd /sbin
find . -name "*fasttrack" -print
The following results should be displayed.
./init.d/fasttrack
./rc1.d/K100fasttrack
./rc2.d/S890fasttrack
4. Execute the following command to verify that the Netscape Fastrack
product is running.
ps -eaf |grep netscape
Output similar to the following should be displayed on three lines.
web 8110 8109 0 Mar 17 ? 39:38 ns-httpd -d /
opt/netscape/fasttrack/httpd-hostname/config
mlt 17169 13099 0 17:26:58 ttyd1p0 0:00 grep netscape
web 8109 1 0 Mar 17 ? 0:00 ./uxwdog -d /
opt/netscape/fasttrack/httpd-hostname/config

NOTE:
The process owner may be "web" or "www" depending on the configuration
during the initial installation of the product.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-5

System Administration Guide End User GUI Verification, Configuration, and
Customization

HP-UX 11.00 and HP-UX 11.11 Systems

Verify Apache and For HP-UX 11.00 and HP-UX 11.11 systems, the Apache and Tomcat products
Tomcat Products are used with the LoopCare End User GUI. Use the following procedures to verify
that these products have been installed.

NOTE:
For HP-UX 11.00, use /opt/hpapache2 as the directory path instead of /opt/
hpws/apache.

1. Login as root.
2. Execute the following commands to verify that the Apache and Tomcat
products have been installed.
ls -CF /opt/hpws/apache
ls -CF /opt/tomcat

NOTE:
The /opt/hpws/apache/conf/httpd.conf and /opt/tomcat/
conf/mod_jk_apache.conf files are the configuration files that define
various settings that are important to serving graphical results from the
LoopCare End User GUI application.

3. If the above directories do not exist, it may be necessary to install the

current certified versions.
Refer to the appropriate LoopCare Release Letter and the LoopCare CD
Installation Guide.
The /opt/hpws/apache/logs and /opt/tomcat/logs directories
contain log information that may be helpful in troubleshooting any End User
GUI application access errors.
4. Verify that there are RC start and stop scripts installed for the Netscape
product and the Apache product is automatically started during system
reboots.
For example:
cd /sbin
find . -name "*apache" -print
The following results should be displayed.
./init.d/apache
./rc1.d/K115apache
./rc2.d/S885apache

8-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
HP-UX 11.00 and HP-UX 11.11 Systems

5. Execute the following command to verify that the Apache and Tomcat
products are running.
ps -eaf |egrep "apache|java"
Output similar to the following should be displayed.
root 18589 1 0 Mar 18 ? 0:10 /opt/hpws/
apache/bin/httpd -d /opt/hpws/apache -k start
base 18602 1 0 Mar 18 ? 4:11 /opt/java1.3/
bin/../bin/PA_RISC2.0/native_threads/java -ms32
www 18594 18589 0 Mar 18 ? 0:03 /opt/hpws/
apache/bin/httpd -d /opt/hpws/apache -k start
www 18591 18589 0 Mar 18 ? 0:00 /opt/hpws/
apache/bin/httpd -d /opt/hpws
/apache -k start

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-7

System Administration Guide End User GUI Verification, Configuration, and
Customization

Sun Solaris Systems

Verify Apache and For Sun Solaris systems, the Apache and Tomcat product are used to serve the
Tomcat Products LoopCare End User GUI. The procedures to verify these products are similar to
those for HP-UX 11.00 and HP-UX 11.11 systems.

The following exceptions apply to Sun Solaris Systems.

• The Apache and Tomcat products can be located under /opt/apache2
and /opt/tomcat, respectively.
• The RC start/stop scripts only reside under "/etc/init.d" and are usually just
named apache.

8-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
System Configuration for GUI

GUI Configuration

System Configuration for GUI

Introduction Before the LoopCare End User GUI application is available, several LoopCare
system configurations must be completed. The related configuration changes are
outlined in the procedures below.

Verify Presence of 1. Login as mlt.

GUI-specific 2. Execute the following command to verify that the indicated LoopCare End
Features User GUI features are enabled.
mltfeat | egrep "TRTDIL|TRITDIL|CGI_GUI"
Output similar to the following should be reported:
TRTDIL TDIL TestRequester Slice
TRITDIL TDIL TestRequester Slice (Interactive)
CGI_GUI HTML/CGI GUI

NOTE:
If the above features are not present, contact LoopCare Technical Support
for assistance.

Install the new If an update feature file with the required features is provided, then use the
Feature File following procedure to install the new feature file.
1. Execute the following command.
cd /mlt/config
2. Execute the following command to save a copy of the original Feature file.
cp /mlt/config/mlt.feature /mlt/config/mlt.feature.save
3. Execute the following command to install the Feature file into the /mlt/
config directory.
cp <feature file> /mlt/config/mlt.feature
4. Stop and then start LoopCare so that the changes take effect.
5. Execute the following command to verify the ENV settings in the "/base/
config/MGRP.env" file.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-9

System Administration Guide End User GUI Verification, Configuration, and
Customization

vi /base/config/MGRP.env
6. Validate the following customer definable parameter.
EUGUI_CUST=RBOC
7. If this environmental parameter is not defined, insert it as a new entry the
Customer Definable section of the file.
Non-RBOC customers should update the EUGUI_CUST parameter to
GCM.
EUGUI_CUST=GCM
8. Execute the following command to verify the GDF settings in the "/base/
config/MGRP.gdf" file.
vi /base/config/MGRP.gdf

NOTE:
If these GDF entries are not defined, add them.

9. Execute the following command to verify the MLT directory for processing
any CGI requests from the LoopCare End User GUI.
ls -ld /mlt/reports/cgi
10. If the /mlt/reports/cgi directory does not exist, use the following commands
to create it.
mkdir /mlt/reports/cgi
chown base:baseadm /mlt/reports/cgi
chmod 775 /mlt/reports/cgi
11. If any changes were made to ENV or GDF files, execute the following
commands to restart the LoopCare system.
base -q stop MGRP
base -q start MGRP
12. Verify the ability to access the LoopCare End User GUI by launching your
browser on your PC and entering the following URL.
http://<servername>.<domain>/loopcare
For example
http://asprin.lucent.com/loopcare

Where <servername> refers to the official hostname of the server; and

<domain> refers to the domain name for the customer
environment.

8-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
System Configuration for GUI

Further For further information regarding the LoopCare End User GUI, refer to Chapters 2
Information and 3 of the Test User Interfaces Guide.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-11

System Administration Guide End User GUI Verification, Configuration, and
Customization

Group Administration

Introduction Use the following procedure to administer the group information used in the
authentication process by the LoopCare system. Group information is required to
allow groups of testers to enter test requests on subscriber numbers.

Procedure 1. Login as mlt.

2. Enter the following command to start the OA&M application.
oam
3. On the main OA&M menu, select FEATURES -> EUGUI ADMIN ->USER
GROUPS.
The GROUP REQUEST CUSTOMIZATION form is displayed
4. Enter a value in the User Group Name field.
5. If the Group name is not in the database, the following message is
displayed.
User Group Name does not exist. Create New?
6. Select Yes to create a new Group.
7. Enter appropriate values in the fields.
8. Once finished, select Save & Submit to populate the database with the new
user group.
9. Press <F10> to display the Navigation Menu.
10. Select the Test Requests option from the Navigation menu.
The GROUP TEST REQUEST CUSTOMIZATION page is displayed.
11. For each test request, perform Steps 12 and 13.
12. Press Control-L.
The list of all LoopCare test requests is displayed.
13. Use the arrow keys to move the cursor to the desired test request and
press Enter.
The request is displayed in the Transaction column.
14. Once finished, select Save & Submit to populate the database with the new
user group.
15. Press <F10> to display the Navigation Menu.
16. Select the LTE INFO option.

8-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
Group Administration

The GROUP LTE TYPES CUSTOMIZATION page is displayed.

17. Select the LTE Types that the group will be allowed to test.
18. Select the Default LTE Display.
19. Once finished, select Save & Submit to populate the database with the new
user group.
20. Select Quit to return to the GROUP REQUEST CUSTOMIZATION form.
21. Select Quit to return to the main OA&M menu.

Additional For additional information on creating User Groups, see Chapter 9 of the
Information Operations, Administration and Maintenance (OA&M) Guide.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-13

System Administration Guide End User GUI Verification, Configuration, and
Customization

User Administration

Introduction Use the following procedure to administer the user information used in the
authentication process by the LoopCare system. User information is required to
allow testers to enter test requests on subscriber numbers.

Procedure 1. On the FEATURES pull-down menu, select EUGUI ADMIN - TESTER

ADMIN.
The Tester Admin screen is displayed.
2. On the Tester Admin Screen add a Login Name.
3. If the Group name is not in the database, the following message is
displayed.
Login does not exist. Create new?
4. Select Yes to create a new Login ID.
5. Enter the pertinent information and select Save & Activate to populate the
database.

Additional For additional information on creating a user record, see Chapter 9 of the
Information Operations, Administration and Maintenance (OA&M) Guide.

8-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
Introduction

GUI Customization

Introduction

Overview LoopCare provides several ways in which you may customize the appearance of
the End User GUI to do the following.
• Reflect the testing capabilities of groups of users and individual users
within a group; See Customizing the GUI for Groups of Users: page 8-16
and Customizing the GUI for a User: page 8-18.
• Display a corporate logo rather than the Tollgrade or LoopCare logo. See
Modifying Logo GIF Files: page 8-20.
• Display data in North-American and non-North-American environments.
See Appendix F, The Customer Environment Screen.
• Ensure that unnecessary fields are not displayed and that other fields are
displayed correctly. For more information about this customization, contact
LoopCare Customer Support.
• Customize the Technical Support page. See Customizing the Welcome to
LoopCare Page: page 8-22.

Individual testers and Tester Administrators also have the ability to modify the
appearance of the GUI during their sessions. See the Test Request User
Interfaces Guide and the Tester Administration GUI Guide.

When LoopCare Features are enabled or disabled, the appearance of the GUI
may also be affected.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-15

System Administration Guide End User GUI Verification, Configuration, and
Customization

Customizing the GUI for Groups of Users

Overview The LoopCare OA&M provides the means to customize the appearance of the
GUI for groups of users.

Additional For additional information, including illustrated examples see the Test User
Information Interfaces Guide.

Procedure 1. On the OA&M Main Menu select the FEATURES option.

The FEATURES pop-up menu is displayed.
2. Select the EUGUI ADMIN option.
The EUGUI ADMIN pop-up menu is displayed.
3. Select the USER GROUPS option.
The Group Request Customization form is displayed.
4. Enter the User Group Name and press Enter.
If the Name exists, go to Step 6.
If the Name does not exist, you are prompted whether to create a new User
Group.
5. Select OK.
6. Select the appropriate check box to indicate whether testing by TN and
Circuit ID is permitted.
One, both or none of these check boxes may be selected.
7. Select the appropriate radio button to indicate whether available test
requests are to be displayed in a pull down list or as a pop-up help window
with a free text input field. You must select one of these options.
8. Press <F6> to access the command buttons and Save your input.
9. Press <F10>.
The Navigation Menu is displayed.
10. Select the Test Requests option.
The Group Test Request Customization page is displayed.
11. Indicate which tests the group is permitted to perform.
12. Press <F6> to access the command buttons and Save your changes.

8-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
Customizing the GUI for Groups of Users

13. Press <F10>.

The Navigation Menu is displayed.
14. Select the LTE Info option.
15. The Group LTE Types Customization page is displayed.
16. Indicate the following:
• The LTEs which the group may test. When a user selects an LTE,
the appropriate fields are displayed to specify the line to test.
• The default LTE to be displayed
• Whether Override information may be entered
17. Press <F6> to access the command buttons and Save your changes.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-17

System Administration Guide End User GUI Verification, Configuration, and
Customization

Customizing the GUI for a User

Overview The LoopCare OA&M provides the means to customize the appearance of the
GUI for an individual user within a group.

Additional For additional information about the appearance of the GUI, see the Test User
Information Interfaces Guide.

Procedure 1. On the OA&M Main Menu select the FEATURES option.

The FEATURES pop-up menu is displayed.
2. Select the EUGUI ADMIN option.
The EUGUI ADMIN pop-up menu is displayed.
3. Select the TESTER ADMIN option.
The Tester Admin form is displayed.
4. Enter the Login and press Enter.
If the Login exists, go to Step 6.
If the Login does not exist, you are prompted whether to create a new
Login.
5. Select OK.
6. Enter appropriate information on the form.
For more information about the Tester Admin form, see the Operations,
Administration, and Maintenance Guide.
The following fields affect the appearance of the GUI:
• Callback Number - appears in the Test Parameters area.
• User Group - determines which test requests are available to the
user and which LTEs may be used for testing.
• Default Transaction - determines which test request is displayed by
default.
• Batch privileges - Determines whether a user is able to perform
Batch testing, and whether the user has single user or administrator
permissions.
• TDR Display - determines whether the TDR results graph is
displayed for the user.

8-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
Customizing the GUI for a User

7. Press <F6> to access the command buttons and Save your input.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-19

System Administration Guide End User GUI Verification, Configuration, and
Customization

Modifying Logo GIF Files

Overview The Circuit Test page of the End User Graphical User Interface (EUGUI) and the
Test page PDA GUI each have three GIF files:
• LoopCare logo
• Tollgrade Communications logo
• Copyright notice

Figure 8-1. Circuit Test Page

This section explains how to customize these logos.

8-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
Modifying Logo GIF Files

Files to Create A customer may create the following GIF files to replace the default logos on the
Circuit Test Page:

To replace this GIF File Create a File with this Filename

LoopCare Logo CustomLogo1.gif
Tollgrade Communications Logo CustomLogo2.gif
Copyright Notice CustomLogo3.gif

Graphic Size The GIF files created cannot exceed the following dimensions:
• The height must be 60 pixels or less.
• The width must be 102 pixels or less.

Location of the Files The system administrator must load the GIF files in the following directory:
/mlt/webgui/loopcare/oneui/images/logos

Effect of the Change Once the custom logo files are loaded in the directory names above, the GUI will
use these GIF files until they are erased. Updating LoopCare will not erase or
override the customer-specific files.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-21

System Administration Guide End User GUI Verification, Configuration, and
Customization

Customizing the Welcome to LoopCare

Page

Introduction This section describes the procedure for customizing the Welcome to LoopCare
page. You may replace the tester picture, the page title, or both of these graphics.
Make sure the size of your replacement images is appropriate.

Procedure 1. Copy the new .gif or .jpg files, for example,

cp MyNewTesterPicture.jpg /mlt/webgui/loopcare/oneui/images/logos
cp MyNewWelcomePicture.gif /mlt/webgui/loopcare/oneui/images/
logos
2. Execute:
cd /mlt/webgui/loopcare/WEB-INF/classes/bundles/Loopcare

8-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
Customizing the Welcome to LoopCare Page

3. Edit the file CustomerDefined.properties, substituting the names of

your.jpg. or .gif files for MyNewTesterPicture.jpg and
MyNewWelcomePicture.gif. If the CustomerDefined.properties file does not
exist, copy CustomerDefined.README to CustomerDefined.properties
first. For example, make the following changes in the properties file:
Login.banner = logos/MyNewTesterPicture.jpg
Login.welcome = logos/MyNewWelcomePicture.gif
4. Stop then start the apache Web server logged in as root.
For Sun execute:
/etc/init.d/apache stop
/etc/init.d/apache start
For HP execute:
/sbin/init.d/apache stop
/sbin/init.d/apache start

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-23

System Administration Guide End User GUI Verification, Configuration, and
Customization

Technical Support Page Customization

Introduction The LoopCare GUI provides a link to the Technical Support page. This section
describes the procedure used to customize the Technical Support page.

Procedure 1. Copy /mlt/webgui/loopcare/doc/support.html to /mlt/webgui/loopcare/

doc/localsupport.html.
2. Edit the file /mlt/webgui/loopcare/doc/localsupport.html as desired
3. Execute the following command:
cd /mlt/webgui/loopcare/WEB-INF/classes/bundles/Loopcare
4. Edit the file CustomerDefined.properties, adding the following line:
Loopcare.menu.left.techsupport.action = return(checkWin('localsupport',
'html', '' ));
5. If the file does not already exist, create one containing this line.
6. At a convenient time when the End user GUI is not being used; login as
root, then stop and restart the necessary web server components
For HP 10.20 run
/sbin/init.d/tomcat stop
/sbin/init.d/tomcat start
For HP 11i run
/sbin/init.d/apache stop
/sbin/init.d/apache start
For Sun run
/etc/init.d/apache stop
/etc/init.d/apache start

Further For further information regarding the LoopCare GUI, refer to Chapters 2 and 3 of
Information the Test User Interfaces Guide and the Tester Administration GUI Guide.

8-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

End User GUI Verification, Configuration, and
Customization System Administration Guide
Maintain Locally Managed VER Code and AID Files

Maintain Locally Managed VER Code

and AID Files

Introduction This section describes the procedure for managing VER code help files and AID
files.

Procedure 1. Under /mlt/aid/tv.aid create a directory called either en_US or en. The
system looks for altered files in en_US first, then in en.
2. Copy the files you wish to modify into these directories.
3. Edit the files.
4. Bring up the GUI. You will see your changes there.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 8-25

System Administration Guide End User GUI Verification, Configuration, and
Customization

Modifying the Tip, Ring, and Ground

Labels

Overview Follow the procedure below to change the labels used for Tip, Ring, and Ground
from T, R, and G, respectively, to A, B, and E.

Procedure 1. Login as mlt.

2. Edit or create the /mlt/webgui/loopcare/WEB-INF/classes/bundles/
Loopcare/CustomerDefined.properties file. Execute:
vi /mlt/webgui/loopcare/WEB-INF/classes/bundles/Loopcare/
CustomerDefined.properties
3. Add the following lines:
CircuitTest.result.tr.label = A-B
CircuitTest.result.tg.label = A-E
CircuitTest.result.rg.label = B-E

NOTE:
If you prefer the G label over E, substitute G for E in step 2.

4. Schedule the restart of Apache/Tomcat web services for the changes to

take effect; After logging in as root, execute:
For the Sun:
/etc/init.d/apache stop
/etc/init.d/apache start

For HP_UX:
/sbin/init.d/apache stop
/sbin/init.d/apache start

8-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Batch Testing 9

Contents

• Introduction 9-2
• Batch Schema Activation 9-3
• Configuring MGRP.gdf Modules 9-5
• Specifying Report Retention 9-6
• Specifying VER Codes 9-7
• Authorizing Users 9-9
• Creating a Batch List 9-11

Revision Q (p/n 040-0362) Release 2.15, December, 2006 9-1

System Administration Guide Administering Batch Testing
Introduction

Introduction

Overview The LoopCare Batch Testing feature provides users the ability to schedule tests of
up to 200 lists each of up to 10,000 domestic or international Telephone Numbers
to run in an automated fashion with minimum impact on regular testing.

This chapter explains the procedures a user with LoopCare administrator

permissions must perform to customize batch testing and to enable testers with
appropriate permissions to use the Batch Testing feature on the GUI.

9-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Batch Testing System Administration Guide
Batch Schema Activation

Batch Schema Activation

Overview The Batch Schema must be enabled in order for the Batch Feature to work.

Instructions These procedures are used to set up batch schema. Perform the following in
order to configure the database:
1. Using a telnet session, log in as mlt. Type:
Login: mlt
Password:
2. Use vi or another editor to verify that the . /mlt/config/oraclevars file
contains the following variables configured as specified.
BATCH_DB=Y;export BATCH_DB
BATCH_TBL=$DB3;export BATCH_TBL
BATCH_INX=$DB2;export BATCH_INX

NOTE:
BATCH_TBL must point to a directory with 60M of free space (110M if the
current temp tablespace is less than 50M). BATCH_INX must point to a
directory with 50M of free space. The Oracle user must be able to write to
these directories.

3. If necessary, add or modify these lines and save the file.

4. Login as oracle and run the activateBatch command. The arguments are
-l <batch login>, -p <batch password>, and -s <system
password>.
The defaults are listed below. Substitute your local secure passwords
appropriately. All options/passwords are required to run upschema. Type:
$ su - oracle
$ ./mlt/config/oraclevars
$ cd /mlt/install/conv
$ ./activateBatch -l batch -p batch -s manager
5. Login as mlt to complete the activation. The arguments are
-s <system password>.
The defaults are listed below. Substitute your local secure passwords
appropriately. All options/passwords are required to run upschema.
$ su - mlt
$ . /mlt/config/oraclevars

Revision Q (p/n 040-0362) Release 2.15, December, 2006 9-3

System Administration Guide Administering Batch Testing
Batch Schema Activation

NOTE:
The space between the . and the / is required.

$ cd /mlt/install/conv
$ ./upschema -s manager

Multi-Machine In a multi-machine environment, this procedure is required only on the master

Environment definition site.

9-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Batch Testing System Administration Guide
Configuring MGRP.gdf Modules

Configuring MGRP.gdf Modules

Overview To ensure that Batch Testing works properly, uncomment the following lines in the
MGRP.gdf file:

F:$MLT_BIN/tspool dummy tspool

F:$MLT_BIN/listmgr dummy listp,listr

Revision Q (p/n 040-0362) Release 2.15, December, 2006 9-5

System Administration Guide Administering Batch Testing
Specifying Report Retention

Specifying Report Retention

Introduction By default, each type of report is retained for a period of time and then deleted:
• Once - 30 days
• Daily - 7 days
• Weekly - 56 days
• Monthly - 120 days

The LoopCare OA&M allows you to change these defaults for your environment.

Procedure 1. On the OA&M main menu select the FEATURES option.

The FEATURES drop-down menu is displayed.
2. Select the BATCH option.
The BATCH drop-down menu is displayed.
3. Select the Configure Options option.
The Configure Batch Options page is displayed.
4. Change the retention periods, as desired.
The valid range of values is 1 to 999 days.
5. Press the <F6> key and save your changes.

9-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Batch Testing System Administration Guide
Specifying VER Codes

Specifying VER Codes

Overview Sometimes tests produce VER codes which are inconclusive and therefore
unusable for determining the condition of a line. The LoopCare OA&M utility
allows the LoopCare administrator to specify the VER codes that are unusable.
When batch tests return these codes, the lines are automatically retested.

Default Unusable The OA&M database is prepopulated with the following VER Codes flagged as
Codes unusable for Batch Testing:
• VER 6
• VER 53
• VER 61
• VER B*
• VER F*

Procedure Use the following

1. On the OA&M main menu select the FEATURES option.
The FEATURES drop-down menu is displayed.
2. Select the BATCH option.
The BATCH drop-down menu is displayed.
3. Select the Configure Vercode option.
The Batch VER Codes page is displayed.
4. For each VER Code that you wish to configure for Batch testing, enter the
following data:
• VER Code
• Transaction ID (Test Request)
• Send Test Again - Is the line returning this VER Code to be
retested?
• Testability Error - Is the test request returning this VER Code to be
included in the Number of Attempts specified by the User on the
New List Page?
5. Press the <F6> key and save the record.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 9-7

System Administration Guide Administering Batch Testing
Specifying VER Codes

NOTE:
Step 4 above must be repeated for each VER Code/test request
combination.

9-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Batch Testing System Administration Guide
Authorizing Users

Authorizing Users

Introduction To enable a tester to use the Batch Testing feature, a LoopCare administrator
must perform the procedure described below in the OA&M utility.

Required To authorize users to perform batch testing, a user must have permission to
Permissions access and modify records on the EUGUI ADMIN option of the FEATURES menu
of the OA&M application.

Before You Begin Before creating a new user profile with permissions to perform Batch Testing,
there must exist a user Group to which you assign the user. For information on
creating User Groups, see the Operations, Administration and Maintenance
Guide.

An existing user has been assigned to a User Group. It is not necessary to

change the User Group record to give permissions to use the Batch Testing
feature.

Types of Users The LoopCare OA&M utilities allow the LoopCare Administrator to designate
users authorized to use the Batch feature as one of the following two types of
users:
• Batch User - This kind of user is able to view only self-initiated
transactions.
• Batch Administrator - This kind of user is able to view all users’
transactions.

Procedure 1. Log in to the OA&M application.

2. On the main menu select the FEATURES option.
The FEATURES drop-down menu is displayed.
3. Select the EUGUI ADMIN option.
The EUGUI ADMIN drop-down menu is displayed.
4. Select TESTER ADMIN option.
The TESTER ADMIN screen is displayed.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 9-9

System Administration Guide Administering Batch Testing
Authorizing Users

5. Enter the Login of the desired user and press Enter.

If the Login exists, go to Step 7.
or
If the Login does not exist, LoopCare prompts whether you wish to create a
new Login.
6. Select Yes and Press Enter.
7. The TESTER ADMIN screen is populated with the available information
about the Login and the cursor is moved to the Password field.
For instructions on entering data on a TESTER ADMIN screen, see the
Operations, Administration and Maintenance Guide.
8. In the Batch Privileges field, click the User or the Administrator options, as
appropriate.
9. Press <F6> to access the command buttons at the bottom of the screen.
10. Save and Activate the record.
The user will be able to perform Batch Testing on the next login into the
End User GUI.

9-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Batch Testing System Administration Guide
Creating a Batch List

Creating a Batch List

Overview This section explains how to create a list for batch testing, the contents of the list,
and where to place the list.

Required To create list files for batch testing, a user must have Unix permission to access
Permissions and save files on the LoopCare server.

LoopCare LoopCare recommends creating a UNIX group (batch) that users with batch
Recommendation testing permission will belong to. For each user, create a directory under /mlt/lists/
batch that is owned by the user.

Example

For a user with the login id of batchuser, type the following commands:
mkdir -P /mlt/lists/batch/batchuser
chown batchuser:batch /mlt/lists/batch/batchuser

Pathname The pathname for a batch source file is limited to a total of 40 characters,
Limitations including delimiters.

NOTE:
Files with pathnames longer than 40 characters are not displayed on the
drop-down list on the New Batch List Page. See Chapter 4 of the Test User
Interfaces Guide.

Rules for the The Source File(s) must be plain text (ASCII) and can contain a mixed list of TNs,
Contents of List Circuit IDs, and Circuit Access Information. The following additional notes apply:
Files 1. Each line is preceded by an indication as to the circuit type, "T" for TN, "C"
for Circuit ID, and "A" for Circuit Access Information. A comma is used as a
separator between the prefix and line information.
2. If there is no indication as to the circuit type, TN is assumed.
3. All valid Circuit IDs formats are supported (Numbers, Alphabetic, and
separators such as "-", "/").

Revision Q (p/n 040-0362) Release 2.15, December, 2006 9-11

System Administration Guide Administering Batch Testing
Creating a Batch List

4. Ranges are not allowed for Circuit IDs.

5. For testing by Circuit Access Information, each line in the file must
preceded by A (for Access Information).
6. Ranges are allowed for Circuit Access Information. Use the following
format to specify a range for any component: <low end of range>:<high
end of range>. For example,
A, AnyMedia1, 1, 1:2, 1:4
7. The source file must contain only one TN, Circuit ID, or Circuit Access
Information per line.
8. A maximum of 10,000 circuits is allowed per source file. This maximum
includes the totals in ranges of TNs. A maximum of 200 lists can be active
on the system.
9. A list will be processed even if some of the lines contain errors (lines with
errors are skipped and an entry is written to a Batch Error Log file).

Example Batch Following is an example of a valid Batch input file for Circuit Access Information:
Input File C, line1
T, 908-243-3904
9085805481
T, 9085804679:4690
908-580-5696
C, stinger1-1-1-1
A, stinger1, 1 , 1, 1
A, DAU1, 0
A, DAU1, 199
A, stinger1, 1, 1, 1
A, AMAS1, 1, 1, 1
A, ADC528r14, 2, 20, 19
A,ADTRAN1500,1,1,2,10
A,TURNSTONECX100,1,5,1
A,ADTRAN3000,1,1,9,2
A,NICOTRA202,10394
A, LITESPAN1,NODE1,1,1,1
A,CIENACN1000,1,1,1:2
A,CALIXC7,1,1,1:2,1
A,TOLLGRADEMSAS,1,1,1
A.LET1,RST1,1,1,1

9-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Batch Testing System Administration Guide
Creating a Batch List

List File Placement The ASCII batch list files are to be placed in one of the following two directories in
the /mlt/lists/batch directory:
• /common
• /<userid>

The tester must know the name of the list file and the directory where it is saved.

Additional For additional information on batch testing output, see the Test User Interfaces
Information Guide.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 9-13

System Administration Guide Administering Batch Testing
Creating a Batch List

9-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR 10

Contents

• Introduction 10-2
• Verifying IVR Status 10-3
• Registry Settings 10-4
• Log Files 10-16
• Interruptions of IVR/LoopCare 10-20

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-1

System Administration Guide Administering IVR
Introduction

Introduction

Overview The LoopCare Interactive Voice Response (IVR) System enables field technicians
to execute LoopCare test requests and receive results via voice output using a
telephone with a touch-tone keypad, without the assistance of a tester in the
Repair Center, and without having access to a desktop or laptop computer.

The LoopCare IVR System consists of hardware and software components. The
hardware components are a PC that runs the IVR Application Software and an
Intel Dialogic Board that provides access to the IVR Application via a touch-tone
line. The software components include Windows 2000 or 2003 and the LoopCare
IVR Application.

This chapter explains the procedures a user with LoopCare administrator

permissions can perform to administer the IVR Application.

10-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Verifying IVR Status

Verifying IVR Status

Overview The IVR Application runs as a service on a Windows 2000 or 2003 PC. This
section explains how to verify the status and start and stop the IVR service.

You can perform this procedure remotely if the IVR PC has remote management
capabilities, such as Windows Tools or PC Anywhere.

Procedure Use the following procedure to verify the status of the IVR service.
1. Click the Start button on the Windows task bar.
The Start menu is displayed.
2. Click the Settings option.
The Settings menu is displayed.
3. Click the Control Panel option.
The Control Panel window is displayed.
4. Double-click the Administrative Tools icon.
The Administrative Tools window is displayed.
5. Click the Services icon.
The Services window is displayed.
This window lists each Service, its Status (Started, or blank), and its Startup
mode (Automatic, Manual, Disabled).
6. Click IVR Service to highlight the entry.
The entry in the Status column indicates the status of the IVR service:
• Started - indicates the service is running.
• Blank - indicates the service is not running.

Stopping IVR 1. If the entry displays Started in the Status column, click the Stop button.
The Services window displays “Stopped” in the lower margin.

Starting IVR 1. If the Status column is blank, click the Start button.
The Services window displays “Running” in the lower margin.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-3

System Administration Guide Administering IVR
Registry Settings

Registry Settings

Overview This section describes how several Windows Registry entries influence the
behavior of IVR.

! CAUTION:
Before attempting to change these registry settings, contact LoopCare
Customer Support.

! CAUTION:
Care should be taken when changing the registry. Only an experienced
administrator should make these changes.

! WARNING:
Do not modify any parameters that are not listed in the following sections.

regedit Access and The regedit utility is used to modify the values of Windows Registry parameters.
Usage
To access regedit, use the following procedure:
1. Click the Start button at the bottom of the Windows screen.
The Start menu is displayed.
2. Select the Run option.
The Run dialog box is displayed.
3. Type regedit and click the OK button.
The Registry Editor screen is displayed.

Use the paths in the following sections to locate and modify IVR-related registry
parameters.
1. To change the value of a parameter, double click the parameter name on
the right side of the window.
An Edit DWORD Value dialog box is displayed, allowing you to set the
current value of the parameter in Hexadecimal or Decimal format and to
edit the value.

10-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Registry Settings

Figure 10-1. The Edit DWORD Value for Pitch Dialog Box

2. Change the value, as appropriate.

3. Click the OK button to close the dialog box.

CustomerOptions The following path contains registries that determine the behavior of IVR menus
and other general characteristics.

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/customerOptions

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-5

System Administration Guide Administering IVR
Registry Settings

Valid
Default Entries or
Registry Name Description Value Ranges
AccessRequestType Determines whether OPEN MET
LoopCare uses the
OPEN
OPEN or MET request to
gain access as part of a
LRM or GRM test
request, when run as an
initial transaction.
Set AccessRequestType
to MET for remote test
heads and to OPEN for
central office test heads.
OPEN offers a speed
advantage for central
office test heads but is
invalid for remote test
heads.
AutoLogFileCleanUp Determines the maximum 14 1-14, to
age of daily IVR log files enable log
in days. If this registry is cleanup
not defined, system and specify
defaults to 14 days. number of
days
< 0 = use
default
0 = disable
log cleanup
BTLengthThreshold The minimum length in 200 0 or greater
feet of a bridged tap for
the BTCOMBO test. If the
calculated bridged tap
length is less than this
value, the bridged tap is
not reported
CktidTopRowOff Determines whether the 0 0 = Top
IVR user can use Top Row
Row format for Circuit ID Format
entry or a numeric entry.
1 = numeric
entry

10-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Registry Settings

Valid
Default Entries or
Registry Name Description Value Ranges
DefaultCableGauge Default Cable Gauge 4 = 26 1 = 19
2 = 22
3 = 24
4 = 26
InteractiveMenuRepeatD Duration in seconds of 20 5 to 60a
elay the interval between
repetitions of the
INTERACTIVE menu.
LoginTopRowFormat Determines whether or 0 0 = Off
not the user can enter a
1 = On
login and password in
Top Row Format..
Menu1OnorOff Determines whether a 0 = Off 0 = Off
user is allowed to select
1 = On
the kind of circuit to test.
MenuOneMaxAttempts Maximum Number of 10 2-60
Error Entries Before
Logout For Menu One.
MenuOneRepeatDelay Duration in seconds of 20 5-60
the intervals between
repetitions of Menu One.
MenuThreeMaxAttempts Maximum Number of 20 2-60
Error Entries Before
Logout For Menu Three.
MenuThreeRepeatDelay Duration in seconds of 20 5-60
the intervals between
repetitions of Menu
Three.
MenuTwoMaxAttempts Maximum Number of 10 2-60
Error Entries Before
Logout For Menu Two.
MenuTwoRepeatDelay Duration in seconds of 20 5-60
the intervals between
repetitions of Menu Two.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-7

System Administration Guide Administering IVR
Registry Settings

Valid
Default Entries or
Registry Name Description Value Ranges
OPENdelay Duration of delay in 3 0 to 60
seconds between the
selection of OPEN
duration and IVR sending
OPEN request to
LoopCare
SubMenuActive Determines whether 0 = No 0 = No
separate INTERACTIVE
1 = Yes
request and TEST
request menus are
presented.
SubMenuMaxAttempts Maximum number of 20 2 - 60
error entries before
logout for INTERACTIVE/
TEST menu
TestMenuRepeatDelay Duration in seconds of 20 5 to 60b
the interval between
repetitions of the TEST
menu.
ToneSubMenu Determines whether the 0 = No
Tone Sub-Menu is
1 = Yes
accessed from Menu2 or
Menu3 when the user If
presses 1. The Tone SubMenuA
Sub-Menu offers the ctive is set
TONE and TONECA to 1, this
options. registry
value is
treated as
0.
a. To set the recommended 30 second menu repetition cycle, the value of this registry item
should be set to 30-x, where x is the length in seconds of the INTERACTIVE requests menu
WAV file.
b. To set the recommended 30 second menu repetition cycle, the value of this registry item
should be set to 30-x, where x is the length in seconds of the Test requests menu WAV file.

CableTemperature The following path contains registries that desirable ranges of cable temperatures.

10-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Registry Settings

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/customerOptions/
CableTemperature.

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
DefaultCableTemperat Default acceptable cable 68 1 to 199
ure temperature.
Max Cable Maximum acceptable cable 199 1 to 199
Temperature temperature.
MinCableTemperature Minimum acceptable cable 0 0 to 199
temperature.

CircuitPromptType The following path contains registries that enable/disable the selection of circuits
for testing.

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/customerOptions/
CircuitPromptType.

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
ASAMPromptActive Determines whether the 0 = No 0 = No
user is allowed to enter an
1 = Yes
LTE ID, Rack, Shelf, Slot
and Circuit for testing.
CircuitIdPromptActive Determines whether the 0 = No 0 = No
user is allowed to enter a
1 = Yes
Circuit ID for testing.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-9

System Administration Guide Administering IVR
Registry Settings

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
LtePlus3PromptActive Determines whether the 0 = No 0 = No
user is allowed to enter an
1 = Yes
LTE ID, Shelf, Slot and Line
for testing.
LtePlusChnnelPrompt Determines whether the 0 = No 0 = No
Active user is allowed to enter an
1 = Yes
LTE ID and Channel for
testing.
TnPromptActive Determines whether the 1 = Yes 0 = No
user is allowed to enter a
1 = Yes
Telephone Number for
testing.

ExpandedComman The following path contains registries that enable/disable the specified
dSet commands.

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/customerOptions/
ExpandedCommandSet

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
BTCOMBOActive Determines whether user is 1 = Yes 0 = No
allowed to select
1 = Yes
BTCOMBO as test request.
GRMActive Determines whether user is 1 = Yes 0 = No
allowed to select GRM as
1 = Yes
test request.
LOC1Active Determines whether user is 1 = Yes 0 = No
allowed to select LOT1 as
1 = Yes
test request.
LRMActive Determines whether user is 1 = Yes 0 = No
allowed to select LRM as
1 = Yes
test request.

10-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Registry Settings

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
MEASTONEActive Determines whether user is 0 = No 0 = No
allowed to select Wideband 1 = Yes
Measure Tone
(MEASTONE) as test
request.
METActive Determines whether user is 1 = Yes 0 = No
allowed to select MET as 1 = Yes
test request.
OPENActive Determines whether user is 1 = Yes 0 = No
allowed to select OPEN as
1 = Yes
test request.
RESPONDActive Determines whether user is 0 = No 0 = No
allowed to select Respond 1 = Yes
as test request.

LanguageEngine The following path contains registries that determine the characteristics of the test
to speech voice characteristics.

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/customerOptions/
LanguageEngine

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
Pitch The pitch of the audio 5 1 (low) to 9
messages. (high)
Speaker Simulates different voices. 1 = Female 1 to 9

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-11

System Administration Guide Administering IVR
Registry Settings

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
SpeakRate Determines speed of the Between 1 1 (slow) to 9
audio messages. and 3, (fast)
depending
on the
language
use Determines whether the IVR 0 = No 0 = No
application uses the
1 = Yes
customer options.
Volume Volume of the audio 5 1 (softest)
messages. to 7
(loudest)

RetainAccess The following path contains registries that determine the retention of access after
a user hangs up.

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/customerOptions/
RetainAccess

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
CableToneRetainDefa Default allowable time in 10 1-60
ult minutes for retaining Tone
after hangup.
CableToneRetainMax Maximum allowable time in 30 1-60
minutes for retaining Tone
after hangup.
CableToneRetainMin Minimum allowable time in 1 1-60
minutes for retaining Tone
after hangup.

10-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Registry Settings

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
OpenRetainDefault The default time in minutes 5 1-60
for holding OPEN after
logging off the IVR System.
This value is used when a #
sign is pressed when IVR
prompts the user for an
OPEN Duration.
OpenRetainMax The minimum allowable time 60 1-60
in minutes for holding TONE
after logging off the IVR
System.
OpenRetainMin The minimum allowable time 1 1-60
in minutes for holding OPEN
after logging off the IVR
System.
RespondRetainDefault The default time in minutes 10 1-60
for holding RESPOND after
logging off the IVR System.
This value is used when a #
sign is pressed when IVR
prompts the user for a
RESPOND Duration
RespondRetainMax The maximum allowable 60 1-60
time in minutes for holding
RESPOND after logging off
the IVR System.
RespondRetainMin The minimum allowable time 1 1-60
in minutes for holding
RESPOND after logging off
the IVR System.
RetainAccessOnHang Indicates whether to turn off 1 = Yes 0 = No
up any held access after 1 = Yes.
hangup.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-13

System Administration Guide Administering IVR
Registry Settings

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
ToneRetainDefault Default allowable time in 10 1-60
minutes for retaining Tone
after hangup.
ToneRetainMax Maximum allowable time in 30 1-60
minutes for retaining Tone
after hangup.
ToneRetainMin Minimum allowable time in 1 1-60
minutes for retaining Tone
after hangup.

Options The following path contains registries that determine the behavior of aspects of
the IVR application.

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/Options

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
DdslBusyFlag Determines whether a test 1 = On 0 = Off
should override the Stinger
1 = On
DSL Busy.
MaxTnDigits Determines the maximum 10 0 to 30
number of digits that can be
contained by a valid
Telephone Number.
MetricFlag Determines whether the 0 = No 0 = No
Metric scale is used instead
1 = Yes
of the Imperial scale..
Make sure that the
applicable parameters on
the Customer Environment
screen are set to Metric.
See Appendix F.

10-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Registry Settings

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
MinTnDigits Determines the minimum 10 0 to 30
number of digits that can be
contained by a valid
Telephone Number.
RepeatUserEntry Determines whether a 0 = Off 0 = Off
user’s entries are repeated,
1 = On
allowing the user to accept
or reject and reenter them.
RepeatUserLoginEntry Determines whether a 0 = Off 0 = Off
user’s login entries are
1 = On
repeated for validation,
allowing the user to accept
or reject and reenter them.
VolumeOption Determines whether a user 0 = Off 0 = Off
is prompted to adjust the
1 = On
volume of the voice
messages issued by the IVR
application.

i18n The following path contains registries that determine the TN format used.

HKEY_LOCAL_MACHINE/SOFTWARE/TOLLGRADE/IVR/i18n

Default Valid
Value Entries or
Registry Name Description (Delivered) Ranges
InternationalTN Determines the TN format, C = North C = North
North American or Non- American American
North American.. TN forman TN format =
On

I = Non-
North
American
TN format

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-15

System Administration Guide Administering IVR
Log Files

Log Files

Overview This section describes IVR usage log files that provide information on port and
session utilization, and failed login attempts.

These log files are maintained in the logging subdirectory under C:/Program Files/
TOLLGRADE/IVR.

Port Utilization Log The port utilization log, LCIVRPortLog2002_08_13.txt, (year_month_day),

provides the duration of time that a physical Dialogic port is in use for each
session. A new file is created at midnight each day.

Example

The following is an example of the Port Utilization Log:

DATE/TIME ;CD-PT; LOGIN ;SESSID;AP;DURA

2002/08/07:13:27:52;01-01; 111;000001;01;0070

2002/08/07:13:29:20;01-05; 123;000002;01;0069

2002/08/07:13:36:44;01-01; 222;000003;01;0042

2002/08/07:13:37:10;01-05; 123;000002;02;0070

Field Descriptions

Field Description
DATE/TIME Date and time the call started.
CD-PT The number of the Dialogic card on the PC (01 or 02)
and the location of the physical port on the Dialogic card
(01 to 12).
LOGIN Login ID of the user.

10-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Log Files

Field Description
SESSID Session ID. The Session ID is restarted at 1 each day at
midnight.
AP The total number of active ports when the call was
received (including the port where this call was
received).
DURA Duration of the port access in seconds.

The AP column provides the peak utilization of IVR ports, which may indicate that
additional IVR ports are required.

Session Utilization The session log, LCIVRSessiontLog2002_08_13.txt, (year_month_day), provides

Log information on login session utilization. A new file is created at midnight each day.

Session utilization refers to the duration of a login session. Because of retained

access, session duration may be greater than the port utilization for a particular
test session. If a tester logs back into a session, the session may span multiple
port uses.

Example

The following is an example of the Session Utilization Log:

DATE/TIME ;CD-PT; LOGIN ;SESSID;AS;DURA

2002/08/07:13:27:57;01-01; 111;000001;01;0065

2002/08/07:13:36:54;01-01; 222;000003;01;0032

2002/08/07:13:29:45;01-05; 123;000002;02;0540

Field Descriptions

Field Description
DATE/TIME Date and time the session started.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-17

System Administration Guide Administering IVR
Log Files

Field Description
CD-PT The number of the Dialogic card on the PC (01 or 02)
and the location of the physical port for the session on
the Dialogic card (01 to 12).
LOGIN Login ID of the user.
SESSID Session ID. The Session ID correlates with the Session
ID in the port log and is restarted at 1 each day at
midnight.
AS The total number of active sessions when the call was
received (including the current session).
DURA Duration of the session in seconds.

The AS column provides the peak utilization of IVR sessions. If this number
approaches 48 repeatedly, this may indicate that additional IVR systems are
required.

Failed Login Log The failed login log, LCIVRFailedPortLog2002_08_13.txt, (year_month_day),

provides information on failed login attempts. A new file is created at midnight
each day.

Example

The following is an example of the Failed Login Log:

DATE/TIME ;CD-PT; LOGIN ;AP;DURA

2002/08/07:13:27:57;02-09; 777;01;0065

Field Descriptions

Field Description
DATE/TIME Date and time the call started.

10-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Log Files

Field Description
CD-PT The number of the Dialogic card on the PC (01 or 02)
and the location of the physical port for the session on
the Dialogic card (01 to 12).
LOGIN Login ID entered by the failed user.
AP The total number of active ports when the call was
received (including the port where this call was
received).
DURA Duration of the port access in seconds.

This file provides information on failed login attempts. Too many failed attempts
may indicate that someone is trying to break into the system.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-19

System Administration Guide Administering IVR
Interruptions of IVR/LoopCare

Interruptions of IVR/LoopCare

Overview This section explains the consequences of various interruptions of the IVR
application or of the LoopCare system.

Interruptions/ The following table describes the consequences of some interruptions of IVR or
Consequences LoopCare.

Actions/Conditions IVR Sessions LoopCare Access

Stop IVR • All IVR sessions INTERACTIVE requests
are terminated. are held for the default
time.
• IVR phones keep
ringing. but IVR
does not accept
any test requests.
• All IVR sessions
are terminated.
• IVR sends X
requests to
LoopCare, except
the TONE request.
Start IVR All IVR sessions are The LoopCare server is
available. ready to accept test
requests.
Re-boot PC; Case 1 • All IVR sessions INTERACTIVE requests
are terminated. are held for the default
time.
• LoopCare does
not drop access on
the lines.
• New IVR sessions
are established.
OR

10-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering IVR System Administration Guide
Interruptions of IVR/LoopCare

Actions/Conditions IVR Sessions LoopCare Access

Re-boot PC; Case 2 Depending on the timing LoopCare does not drop
of the attempt to access access on the lines.
the IVR application, INTERACTIVE requests
are held for the default
sometimes all IVR
time
sessions are terminated.
or
IVR reports Test
Session Already Active
and logs the user out.
Stop MLT All IVR sessions are LoopCare drops access
terminated. on all lines.
IVR users receive the No
communications with
MLT/LoopCare.
Goodbye. message.
Start MLT • All IVR sessions The LoopCare server is
are available. ready to accept test
requests.
• The first attempt to
run a test request
produces a No
Communication
to LoopCare
message.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 10-21

System Administration Guide Administering IVR
Interruptions of IVR/LoopCare

Actions/Conditions IVR Sessions LoopCare Access

Lost Power; Case 1 Same as re-boot PC INTERACTIVE requests
are held for the default
time.
Lost Power; Case 2 Same as re-boot PC INTERACTIVE requests
are held for the default
time.
Lost communication • When INTERACTIVE requests
communications are held for the default
are lost, IVR time.
reports No
Communication
to LoopCare.
• After
communications
are re-connected,
and the first
attempt to run a
test request is
made, IVR reports
No
Communication
to LoopCare.
• All IVR sessions
are available.

Not Hanging up the When a user requests a TONE request but does not hang up, the TONE duration
Phone timer is not initiated.

The TONE duration timer is initiated only if the user hangs up.

Otherwise, the menu timer drops the TONE when the menu duration is reached.

10-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to
Tollgrade Test Devices 11

Contents

• Introduction 11-2
• Software Download Configuration File 11-3
• Downloading an Alternate Software Version 11-9
• Tollgrade Software Download Files 11-10
• DMU, DMU+, DWU, Ethernet Option Card Download Process 11-12
• EDGE Download Process 11-17
• HUB Download Process 11-21
• Download Status Conditions 11-24

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-1

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

Introduction

Overview LoopCare provides the capability of upgrading software on several Tollgrade test
devices:
• DMU
• DWU
• EDMU
• DigiTest Edge
• HUB

This administrative activity can be performed though either the System

Administration Mask (SAM) user interface or the SAM GUI interface The software
download feature is locked and requires the SWDLD feature (#144) to be on.

The software download feature supports

• multiple, simultaneous downloads to test devices.
• download status report commands to monitor the progress of software
downloads
• administrative commands to abort or re-enable downloads, restore or
update the boot-up module (boot block) of a test device, and restore older
versions of software

This chapter describes the procedures for executing software downloads and
related activities.

11-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
Software Download Configuration File

Software Download Configuration File

Introduction When a Tollgrade test device requires a new software download, the software files
must be copied to a software download directory. The standard directory for this
purpose is /mlt/tollgrade/dwnld.There is a sub-directory for each of the DigiTest
products: HUB, ETHERNET, DMU, DWU,ISSUE3, DWU, HUB, and EDGE,
Current software files are copied into these sub-directories automatically when the
LoopCare tape is loaded. Use the /mlt/tollgrade/dwnld/ARCHIVE sub-directory to
save older versions of the software.

You have the option of downloading an alternate software version to a DigiTest

device. The procedure is outlined later in this section.

The SWDLD.cfg file defines a number of environment variables that are required
to properly download a Tollgrade test device. A default version of this file is
delivered with the release as a model, but it must be modified, or at least verified,
prior to each software download.

Setting Up the Set up the SWDLD.cfg file as follows.

SWDLD.cfg File
Location Owner Group Perm
/base/config mlt baseadm - rw - rw- r - -

Include all necessary variables and update their content so that the proper
information for Tollgrade test device software download is contained in the file.
The information in the SWDLD.cfg file delivered in /mlt/config may be different
from the way you set up your variables.

A default file is delivered in /mlt/config with each new release and can be copied
to /base/config if required. Updates to the SWDLD.cfg file take effect immediately.
There is no need to re-start the LoopCare application. The final version of
SWDLD.cfg must be in the /base/config folder.

The configuration file provides information that determines the software files that
are downloaded to Tollgrade test devices. This information is in the form of
variables that are populated in this file. The variables, their meanings, and their
uses are shown below.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-3

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

Variable Meaning
TOLLGRADE_RELEA The directory containing the Tollgrade test device
SE_DIR software files to be downloaded. The default directory
for this variable is /mlt/tollgrade/dwnld, but you can
move the files to another directory.
The actual files that are downloaded to the test head
must be located in a sub-directory under
TOLLGRADE_RELEASE_DIR. A specific sub-directory
name is required for each test head type. The required
sub-directory names are listed below.
• DMU for the narrowband DMU software
• DWU for the wideband DWU software
• ETHERNET for Ethernet option card software
• DMU_ISSUE3 for the DMU+
• EDGE for the DigiTest Edge software
• HUB for the DigiTest HUB software

For example, if you assign /mlt/tollgrade/dwnld/

edge2.0.7 to TOLLGRADE_RELEASE_DIR, the EDGE
software download modules must be located in /mlt/
tollgrade/dwnld/edge2.0.7/EDGE. The required sub-
directory names listed above are case sensitive.
TOLLGRADE_RELEA The release version of the DMU software to be
SE_VER downloaded.
The release version is indicated in the release letter
delivered with the software and should be set
accordingly.
The release version is checked against the DMU’s
internal release to determine if the download should
continue.
TOLLGRADE_HUB_R The release version of the HUB software to be
ELEASE_VER downloaded.
The release version is indicated in the release letter
delivered with the software and should be set
accordingly.
The release version is checked against the HUB’s
internal release to determine if the download should
continue.

11-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
Software Download Configuration File

Variable Meaning
MAX_DMU_DWNLD The maximum number of simultaneous downloads for
each testhead. An EMU can consist of up to 16 DMUs
or a testhead may be associated with multiple DMU-Rs.
This variable indicates how many of those DMUs can
be downloaded at the same time.
The maximum number of simultaneous downloads that
can be run to DMUs associated with an EMU (as DMU-
C or DMU-R) or an LTS/DCTU (as DMU-R).
The current default and recommended setting is 4, but
this may be adjusted up or down based on the user's
experience of system load and performance.
MAX_LTEGROUP_D The maximum number of LTE groups that can be
WNLD simultaneously downloaded. Only one LTE per group
can be downloaded at a time.
TOLLGRADE_DMU_D The number of download attempts. A value of 1
OWNLOAD_RETRIES indicates that no download retries are attempted.
The default is 5.
TOLLGRADE_DMU_D The time, in seconds, between download attempts.
OWNLOAD_DELAY
The default is 30 seconds.
TOLLGRADE_RELEA The release version of the Tollgrade Ethernet option
SE_ETHERNET_VER card software to be downloaded.
SION
The release version is indicated in the release letter
delivered with the software and should be set
accordingly.
The release version is checked against the Ethernet
option card’s internal release to determine if the
download should continue.
TOLLGRADE_ETHER The TCP port offset of the Ethernet card from the TCP
NET_PORT_OFFSET port of the DMU.
This variable is required if the configuration of the
Ethernet DMU is not the standard EDMU access server
configuration.
For example if the DMU is located at 133.133.133.133.
port 7100 and
TOLLGRADE_ETHERNET_PORT_OFFSET=10, the
Ethernet card is on TCP port 7110.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-5

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

Variable Meaning
TOLLGRADE_EDGE_ The release version of the Tollgrade DigiTest EDGE
RELEASE_VER software to be downloaded.
The release version is indicated in the release letter
delivered with the software and should be set
accordingly.
The release version is checked against the DigiTest
Edge’s internal release to determine if the download
should continue.
TOLLGRADE_ISSUE3 The release version of the DMU+ software to be
_RELEASE_VER downloaded.
The release version is indicated in the release letter
delivered with the software and should be set
accordingly.
The release version is checked against the DMU+
option card’s internal release to determine if the
download should proceed.
BOOT_BIN This variable is included whenever the boot block file
must be downloaded as part of the DMU software
release. The instructions in the release letter will
indicate when it should be included in the SWDLD.cfg
file and what value to assign. Unless downloading a
boot block, this variable should not be included in the
SWDLD.cfg file.

This variable indicates the version of the boot block.

The value will be specified in the release letter. NOTE:
This variable should only be placed in the SWDLD.cfg
file if the Release Letter instructs you to do so.
Otherwise, this entry should be removed or commented
out. If this variable is present and its value matches the
value for the TOLLGRADE_RELEASE_VER variable in
the SWDLD.cfg file, the boot block file will be loaded to
the DMU as part of the standard software download
with the FSWDLD request.

11-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
Software Download Configuration File

Variable Meaning
DEF_APP This variable defines the version number of the default
application to be downloaded to the DMU. This variable
should only be placed in the SWDLD.cfg file if you
intend to download the DMU with default application
software located in the flash memory of the DMU. If this
variable is present, and its value matches the value for
the TOLLGRADE_RELEASE_VER variable in the
SWDLD.cfg file, it will download from the default
application area as part of the standard software
download with the FSWDLD request.
TOLLGRADE_ALTER This variable defines the download file name for
NATE_FILENAME downloading the DMU+ when a boot bin change is
required. The variable is specified as follows:
TOLLGRADE_ALTERNATE_FILENAME=$timberland.
EDGE_DOWNLOAD_ Protocol used to download the EDGE.
PROTOCOL
Valid values: L2, FTP
Default: L2

Sample SWDLD.cfg An example of the SWDLD.cfg file is shown below. Note that the BOOT_BIN
File variable should be deleted if the boot block is not required for a particular DMU
software release.

Sample SWDLD.cfg file:

TOLLGRADE_RELEASE_DIR=/mlt/tollgrade/dwnld

MAX_DMU_DWNLD=4

TOLLGRADE_RELEASE_VER=6.48.2

TOLLGRADE_EDGE_RELEASE_VER=2.0.17

TOLLGRADE_ISSUE3_RELEASE_VER=7.01

TOLLGRADE_RELEASE_ETHERNET_VER=7.00

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-7

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

Downloading an Alternate Software

Version

Use the following procedure to download an alternate software version to a

DigiTest.
• To save a particular version of downloadable software, copy the
appropriate sub-directory for the target device type (e.g. EDGE) to /mlt/
tollgrade/dwnld/ARCHIVE using a sub-directory name that contains the
product type and release number, for example, EDGE-6.24.
• To use a version in the ARCHIVE sub-directory
1. Copy the software modules to the appropriate /mlt/tollgrade/dwnld
directory. For example,
cp /mlt/tollgrade/dwnld/ARCHIVE/EDGE-6.24/* /mlt/tollgrade/dwnld/
EDGE
2. Edit the /base/config/SWDLD.cfg file.
3. Reset the SWDLD.cfg variable that identifies the correct software
version for the target product type, for example,
TOLLGRADE_EDGE_RELEASE_VER for the EDGE.

Instead of copying files, you can link the directory for the target product to the
archive sub-directory containing the release you want to download.

11-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
Tollgrade Software Download Files

Tollgrade Software Download Files

The software modules for Tollgrade test devices should be obtained directly from
Tollgrade, by calling the Tollgrade technical support number, 1-800-777-5405.
With the software, you receive a software Release Note which contains a listing of
the appropriate versions of the files in the software module.
• DMU Software Modules. These consist of the following:
— CFAPP.SYS (Standard Download Module)
— DSPAPP.SYS (Standard Download Module)
— fpga.sys (Standard Download Module)
— boot.bin (boot block)
— DEFAPP.SYS (default Application Module)
• DWU (wideband) Software Modules. These consist of the following:
— CFAPP.SYS (Standard Download Module)
— DSPAPP.SYS (Standard Download Module)
— fpga.sys (Standard Download Module)
— boot.bin (boot block)
— DEFAPP_SYS (default Application Module)
• Ethernet Option Card Software Modules. These consist of the following:
— $FLASH or $flash
• DigiTest EDGE Software Modules. These consist of the following:
— empty_<rel_no>.image
Cleans up files.
— version.cfg
Contains the release versions for each board type.
— Software modules for individual DigiTest EDGE boards:
RAC_<rel_no>.image
IMU_<rel_no>.image
SLQ_<rel_no>.image
BSO8_<rel_no>.image
BSO16_<rel_no>.image
ADSL_MODEM.BSU_<rel_no>.image
ADSL2_MODEM.BSU_<rel_no>.image
GSHDSL_MODEM.BSU_<rel_no>.image

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-9

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

ADSL_GSHDSL_MODEM.BSU_<rel_no>.image
ADSL2_GSHDSL_MODEM.BSU_<rel_no>.image
ADSL_ADSL2_MODEM.BSU_<rel_no>.image
• DMU+ Software Modules,
— $FLASH or $flash
— $timberland (or $TIMBERLAND)
Required only for boot bin changes.
• HUB Software Modules,
— version.cfg
Contains the release versions for each board type.
— Software modules for HUB boards:
$FLASH.BSU
$FLASH.TMU
$MODEM.BSU
$FLASH.SCU
$FLASH.XMU
$MODEM2G.BSU
$MODEM2A.BSU
$MODEMAG.BSU

Locating Test It is recommended that the software to be downloaded be placed in the following
Device Software directories or some alternative that includes the release number in the directory
Files path:
/mlt/tollgrade/dwnld//DMU/<rel_no>
/mlt/tollgrade/dwnld//DWU<rel_no>
/mlt/tollgrade/dwnld//ETHERNET<rel_no>
/mlt/tollgrade/dwnld/EDGE/<rel_no>
/mlt/tollgrade/dwnld/HUB/<rel_no>
/mlt/tollgrade/dwnld/DMU_ISSUE3/<rel_no>

where <rel_no> is the Release number of the test device software.

11-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
DMU, DMU+, DWU, Ethernet Option Card Download

DMU, DMU+, DWU, Ethernet Option

Card Download Process

Introduction The download process begins when you receive the Tollgrade software modules
and the Tollgrade Software Release Note document that defines the new DMU,
DMU+ or DWU software to load. The Release Letter indicates if the download will
be standard or if the boot block must be downloaded. Special directions, if any, will
be included in the Release Note from Tollgrade.

Tollgrade Release The Release Notes provides all data required in the SWDLD.cfg file. This includes
Note Contents release versions for the appropriate variables:
TOLLGRADE_RELEASE_VER
BOOT_BIN, or DEFAPP_SYS
TOLLGRADE_RELEASE_ETHERNET_VER

NOTE:
If the BOOT_BIN and DEFAPP_SYS variables are present in the
SWDLD.cfg file, those files will be loaded on the DMU as part of the
standard software download with SWDLD. Remove or comment-out the
BOOT_BIN and DEFAPP_SYS variables if they are not needed.

NOTE:
If TOLLGRADE_ALTERNATE_FILENAME=$TIMBERLAND is present in
the SWDLD.cfg file, boot bin change will be loaded into the DMU+ as part of
the standard software download with SWDLD. Remove or comment out the
TOLLGRADE_ALTERNATE_FILENAME variable if no boot bin changes
are required in the DMU+. The $flash download file will be used in this
case.

You can customize the other variables, TOLLGRADE_RELEASE_DIR and

MAX_DMU_DWNLD, to match your environment.

Verify Your Verify that the following folders exist:

Environment <directory specified by TOLLGRADE_RELEASE_DIR>/DMU
<directory specified by TOLLGRADE_RELEASE_DIR>/DWU
<directory specified by TOLLGRADE_RELEASE_DIR>/ETHERNET

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-11

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

<directory specified by TOLLGRADE_RELEASE_DIR>/

DMU_ISSUE3

Verify that the files to be downloaded are in the above DMU, DWU, DMU_ISSUE3
and ETHERNET sub-directories under TOLLGRADE_RELEASE_DIR.

Verify that the variables in the SWDLD.cfg file point to the above paths.

Verify the software release version assigned to the

TOLLGRADE_RELEASE_VER variable in the SWDLD.cfg file.

NOTE:
Changes made to the SWDLD.cfg file take effect immediately. It is not
necessary to bounce the LoopCare application for these changes to take
effect.

Performing Instructions for using the System Administrative Mask (SAM) and the System
Downloads Administrative GUI to download the DMU software are contained in the
Operations, Administration and Maintenance (OA&M) Guide for Administrators.

DMU/DMU+, DWU, and Ethernet option card software downloads may be initiated
manually or may be scheduled through the MSCHD utility just like any other SAM
request.

Back-out

A previous version of DMU/DMU+, DWU, and Ethernet option card software can
be loaded on a DMU/DMU+, DWU, and Ethernet option card if that version is still
available. It is easy to keep track of DMU releases if they each are kept in
separate directories. When needed, provide the full path of the desired version in
the TOLLGRADE_RELEASE_VER variable in the /base/config/SWDLD.cfg
directory.

The DMU/DMU+, DWU, and Ethernet option card can also be signaled to
download from its own default application area by adding the DEF_APP variable
to SWDLD.cfg and starting the download to the target DMU/DMU+s, DWUs, and
Ethernet option card. A FSWDLD request is needed to accomplish this.

11-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
DMU, DMU+, DWU, Ethernet Option Card Download

Recovery

There may be a need to reload the DMU’s boot block if the DMU download fails or
corrupts the DMU. To address this, add the BOOT_BIN variable to SWDLD.cfg
and resend the download.

Alternatively, a reload of the default application area or a second download of the

latest DMU software may clear the problem.

If the DMU does not recover after any of these steps, you may attempt to reset the
DMU through the DMU’s human interface (HADM). If you can’t communicate to
HADM, try power cycling the DMU, if practicable.

If all these steps fail, replace the DMU.

Print DMU Use the PSWDLD command to obtain status reports of current or previous DMU/
Download Report DMU+, DWU, and Ethernet option card downloads. The report can be tailored
using NPANNX and command options.

Miscellaneous The Software Download feature executed from SAM should not be confused with
Information the DMU/DMU+ download option from EMUadmin. The DMU/DMU+ software
download from SAM downloads software to the DMU/DMU+ that the DMU/DMU+
requires to operate and test. The download option from EMUadmin downloads
LoopCare database information (trunk groups, EMU IPs, etc.) to the DMU/DMU+.
These are two entirely different and separate functions.

PSWDLD Log Files A log file of every SAM software download transactions is automatically created
and placed in /mlt/reports/dwnld. The log files associated with the download SAM
transactions include such data as EMU ID, DMU ID, DATE, TIME, SWDLOAD,
VERSION, and STATUS. The log files and the SAM terminal display output have
the same format.

UNIX Download In addition to the log files produced by the PSWDLD command, there is another
Status Report report that is appended by each of the download commands.

This report is located in the file /mlt/reports/DWNLD.STAT. An example of the

file is shown below. There is only one such file and it continues to grow until
deleted by the user. At that point a new file begins.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-13

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

THID DMUID EXK DATE TIME DWNLD STATUS VERSION DMU STATUS
-----------------------------------------------------------------------------
--
952 1 724275 04-17-2002 08:55 COMPLETE 5.03
904 2 305710 04-17-2002 14:49 F-NOCONN 5.03 A
904 1 305709 04-17-2002 14:51 COMPLETE 5.03 O
904 2 305710 04-17-2002 15:18 COMPLETE 5.03
904 2 305710 04-17-2002 15:37 F-SAMEVERSION 5.03 A
904 1 305709 04-17-2002 15:37 F-SAMEVERSION 5.03 O
904 2 305710 04-17-2002 15:38 F-SAMEVERSION 5.03
904 1 305709 04-17-2002 15:39 F-SAMEVERSION 5.03
904 1 305709 04-17-2002 15:40 F-SAMEVERSION 5.03
904 2 305710 04-17-2002 15:40 F-SAMEVERSION 5.03
904 2 305710 04-17-2002 15:41 F-SAMEVERSION 5.03 A
904 1 305709 04-17-2002 15:41 F-SAMEVERSION 5.03 O
1200 1 305719 07-12-2002 12:05 F-ERROR (E)
1200 1 305719 07-12-2002 12:37 F-NOSOFT 12.00 (E)
1200 1 305719 07-12-2002 12:55 COMPLETE 12.00 (E)
---- 18 ------ 07-12-2002 13:36 COMPLETE 12.00 (E)
---- 19 ------ 07-18-2002 10:11 F-NOCONN 6.01
951 2 305712 07-24-2002 18:41 COMPLETE 6.01
1200 2 305720 07-30-2002 10:02 F-NOCONN 12.00 (E)
1200 2 305720 07-30-2002 10:44 F-NOCONN 12.00 (E)
1200 2 305720 07-31-2002 08:26 F-INVPW 6.01
1200 2 305720 07-31-2002 10:03 COMPLETE 6.01
1200 2 305720 07-31-2002 11:17 COMPLETE 12.00 (E)

Output Report The following table gives a list of the DWNLD.STAT output fields and their
descriptions.

Field Description
THID Testhead ID of EMU. Valid range is 800 - 1599. For RMU-S, the field
is filled with dashes (---).
DMU ID ID of a specific DMU-C or DMU-R, or the sequence number of a
specific RMU-S. For DMU-C, the format is EMU ID, Trunk, C (central
office),. For DMU-R, the format is EMU ID, RMU-ID (range 1-768), R
(for DMU-R). For RMU-S the format is RMU sequence number. S
(for standalone).
EXK The Exchange Key used to identify the switch tested by the test
head. For RMU-S, the field is filled with dashes (---).

11-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
DMU, DMU+, DWU, Ethernet Option Card Download

Field Description
DATE Date of the last download attempt. Given in format MM-DD-YYYY.
TIME Time of last download attempt. Given in 24 hour format HH:MM:SS.
SWDLOAD Status of software download to DMU. See the list of status
conditions on page 11-23.
VERSION The DMU software version downloaded, e.g., 1.06.
STATUS The service status of the DMU: A = Available; O = out-of-service.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-15

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

EDGE Download Process

Introduction The download process begins when you receive the Tollgrade software modules
and the Tollgrade Software Release Note document that defines the new DigiTest
Edge software to load. The Release Letter indicates if the download will be
standard or if the boot block must be downloaded. Special directions, if any, will be
included in the Release Note from Tollgrade.

Tollgrade Release The Release Note provides all data required in the SWDLD.cfg file. This includes
Note Contents release versions for the TOLLGRADE_EDGE_RELEASE_VER variable:

You can customize the other variables, TOLLGRADE_RELEASE_DIR and

MAX_DMU_DWNLD, to match your environment.

Verify Your Verify that the following folder exists:

Environment <directory specified by TOLLGRADE_RELEASE_DIR>/EDGE

Verify that the files to be downloaded are in the EDGE sub-directory under
TOLLGRADE_RELEASE_DIR. There is one image file for each EDGE board and
one for each BSU modem combination. The allboards file available in previous
releases is no longer supported. See Tollgrade Software Download Files on page
11-9 for a list of EDGE files. The BSO8 file is the non-VoIP BSU file and BSO16
supports VoIP.

Verify that the variables in the SWDLD.cfg file point to the above paths.

NOTE:
Changes made to the SWDLD.cfg file take effect immediately. It is not
necessary to bounce the LoopCare application for these changes to take
effect.

Performing Instructions for using the System Administrative Mask (SAM) and the System
Downloads Administrative GUI to download the DigiTest Edge software are contained in the
Operations, Administration and Maintenance (OA&M) Guide for Administrators.

DigiTest Edge software downloads may be initiated manually or may be

scheduled through the MSCHD utility just like any other SAM request.

11-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
EDGE Download Process

A firmware download to the EDGE initiated from the SAM GUI does not display
results.Instead, a message appears informing you that a download is in progress
and instructing you to run the SAM GUI retrieve software download status
command to monitor the progress of the download.

LoopCare downloads only those images that correspond to boards and modem
combinations actually inserted in the EDGE at the time of the download. If you
later insert a type of board or modem that was not present during the previous
download, you must manually download the appropriate image file.
‘

Upgrading from 6.2 Upgrading from 6.2 EDGE firmware to 6.3 requires two downloads of the BSO16
EDGE Firmware to image. The first download preps the BSU to accept the new 16 meg setup. The
6.3 second download actually loads the 16 meg software.

Back-out

A previous version of DigiTest Edge software can be loaded on a DigiTest Edge if

that version is still available. It is easy to keep track of DigiTest Edge releases if
they each are kept in separate directories. When needed, provide the full path of
the desired version in the TOLLGRADE_EDGE_RELEASE_VER variable in the /
base/config/SWDLD.cfg directory.

Recovery

Contact support for recommendations on back-out and recovery.

Print DigiTest Edge Use the PSWDLD command to obtain status reports of current or previous
Download Report downloads. The report can be tailored using NPANNX and command options.

edgeLog File The edgeLog.txt file, located in /mlt/reports, contains download and low level
status information for the DigiTest Edge.

Miscellaneous The Software Download feature executed from SAM should not be confused with
Information the DigiTest Edge download option from EMUadmin. The DigiTest Edge software

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-17

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

download from SAM downloads software to the DigiTest Edge that the Edge
requires to operate and test. The download option from EMUadmin downloads
LoopCare database information (trunk groups, EMU IPs, etc.) to the DigiTest
Edge. These are two entirely different and separate functions.

PSWDLD Log Files A log file of every SAM download transactions is automatically created and placed
in /mlt/reports/dwnld. The log files associated with the download SAM
transactions include such data as DMUID, DATE, TIME, SWDLOAD, VERSION,
and STATUS. The log files and the SAM terminal display output have the same
format.

UNIX Download In addition to the log files produced by the PSWDLD command, there is another
Status Report report that is appended by each of the download commands.

This report is located in the file /mlt/reports/DWNLD.STAT. An example of the

file is shown below. There is only one such file and it continues to grow until
deleted by the user. At that point a new file begins.

11-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
EDGE Download Process

Output Report The following table lists the DWNLD.STAT output fields and their descriptions.

Field Description
THID Testhead ID of EMU. Valid range is 800 - 1599. For RMU-S, the field
is filled with dashes (---).
DMU ID ID of a specific DMU-C or DMU-R, or the sequence number of a
specific RMU-S. For DMU-C, the format is EMU ID, Trunk, C (central
office),. For DMU-R, the format is EMU ID, RMU-ID (range 1-768), R
(for DMU-R). For RMU-S the format is RMU sequence number. S
(for standalone).
EXK The Exchange Key used to identify the switch tested by the test
head. For RMU-S, the field is filled with dashes (---).
DATE Date of the last download attempt. Given in format MM-DD-YYYY.
TIME Time of last download attempt. Given in 24 hour format HH:MM:SS.
SWDLOAD Status of software download to DMU. See the list of status
conditions on page 11-23.
VERSION The DMU software version downloaded, e.g., 1.06.
STATUS The service status of the DMU: A = Available; O = out-of-service.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-19

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

HUB Download Process

Introduction The download process begins when you receive the Tollgrade software modules
and the Tollgrade Software Release Note document that defines the new HUB
software to load. Special directions, if any, will be included in the Release Note
from Tollgrade.

Tollgrade Release The Release Note provides all data required in the SWDLD.cfg file. This includes
Note Contents release versions for the TOLLGRADE_HUB_RELEASE_VERSION variable:

You can customize the other variables, TOLLGRADE_RELEASE_DIR, for

example, to match your environment.

Verify Your Verify that the following folder exists:

Environment <directory specified by TOLLGRADE_RELEASE_DIR>/HUB

Verify that the files to be downloaded are in the HUB sub-directory under
TOLLGRADE_RELEASE_DIR.

Verify that the variables in the SWDLD.cfg file point to the above paths.

NOTE:
Changes made to the SWDLD.cfg file take effect immediately. It is not
necessary to bounce the LoopCare application for these changes to take
effect.

Performing Instructions for using the System Administrative Mask (SAM) to download the
Downloads HUB software are contained in the Operations, Administration and Maintenance
(OA&M) Guide for Administrators. See the HSWDLD, FHSWDLD, PHSWDLD,
and ASWDLD commands.

HUB software downloads may be initiated manually or may be scheduled through

the MSCHD utility just like any other SAM request.

11-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
HUB Download Process

Back-out

Use the FHSWDLD SAM command to download an older release.

Recovery

Contact support for recommendations on back-out and recovery.

Print HUB Use the PHSWDLD command to obtain detailed status reports of the current or
Download Report previous downloads. This command reports the status of individual boards.

hubLog File The hubLog.txt file, located in /mlt/reports, contains download and low level status
information for the HUB.

PHSWDLD Log A log file of every SAM download transactions is automatically created and placed
Files in /mlt/reports/dwnld. The log files and the SAM terminal display output have the
same format. See PHSWDLD in the OAM Guide for a description of the report
fields.

HUB Alarm Server The HUB sends alarms related to the software download to the HUB alarm server.

The LoopCare front end server that initiates downloads to the HUB must be the
same server to which the HUB reports alarms.

UNIX Download In addition to the log files produced by the PHSWDLD command, there is another
Status Report report that is appended by each of the download commands.

This report is located in the file /mlt/reports/DWNLD.STAT. An example of the

file is shown below. There is only one such file and it continues to grow until
deleted by the user. At that point a new file begins.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-21

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

The following table lists the DWNLD.STAT output fields and their descriptions.

Field Description
THID DCN ID and HUB ID: <DCN ID>-<HUB ID>.
DMU ID Not used for HUB.
EXK The Exchange Key used to identify the switch tested by the test
head.
DATE Date of the last download attempt. Given in format MM-DD-YYYY.
TIME Time of last download attempt. Given in 24 hour format HH:MM:SS.
SWDLOAD Status of software download to the HUB. See the list of status
conditions on page 11-23.
VERSION The HUB software version downloaded.
STATUS The service status of the HUB: A = Available; O = out-of-service.

11-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
Download Status Conditions

Download Status Conditions

Status Conditions

Status Term Significance

(blank field) • A blank status field is displayed as an intermediate
status if PHSWDLD is run just after the Hub software
download is initiated but before the FTP completes.
Once the FTP completes and the software download
actually begins the status is updated with a non-blank
status value, for example, IN PROGRESS.
• A blank status field is displayed as a final status for
those slots that did not participate in a HUB software
download, for example, if the download contained
software for an XMU but not for the other card types.
ADMIN-QUERY Indicates that the test head software release was updated by
a SAM administration command. The version is displayed in
the VERSION field.
COMPLETE Completed. Software downloaded and reboot was
successful.
F-ABORT Abort download. Download was aborted.
F-BADCRC File to be downloaded has a bad CRC.
F-BUSY Failed-busy. Test head in busy state or in Sanity.
F-CONFIG There is an error in the configuration download. Check
SWDLD.cfg.
F-DBASE Failed-database. The NPANNX is not in the database, or in
the case of the RMU-S, the sequence number is not in the
database.
F-DIFFVERS After the download, the software version on the test head
differs from version specified in SWDLD.cfg, or the version
on a particular EDGE or HUB card differs from the version
specified in the version.cfg file.
F-DLOAD Failed-downloading. Another download is in progress.
F-NOTEDMU Ethernet card download was attempted for a testhead
that is not a DMU+.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-23

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

Status Term Significance

F-ERROR Internal system error. Verify the release numbers assigned to
the version variables in the SWDLD.cfg file and the presence
of the version.cfg file in the download directory.
Check for error files in /mlt/error with the prefixes emuld,
dmuld, to_ld or to_ld_ftp. These files may contain a more
detailed explanation of the problem.
F-INVPW Failed-password. Disconnected because of invalid password.
F-MISC Protocol error. Download was encountering numerous
protocol errors.
F-NDLOAD Failed-not downloadable. Test head that was entered was for
an old RMU that is not downloadable.
F-NOCONN Failed-no connection. Connection could not be established or
was dropped.
F-NOSOFT The software to be downloaded is not present on LoopCare
for download.This can occur if a download is requested and
there is no software in the download directory that is
specified by the SWDLD.cfg file or there is no software for a
particular board.
F-NOTBOOT Failed-not bootable. Reboot failed. The test head cannot
reboot until it is re-downloaded
F-REBOOT Failed--reboot. Reboot failed. Could not connect after reset.
F-SAMEVERSION The current operating version of the software is the same as
the new version to be downloaded.
F-TESTING Failed-testing affected. The download failed while
downloading files to the test head. The test head has not
been reset. The test head can be reset. It will be
downloadable after a reset but testing may be affected.
F-TIME Failed-timeout. System timed out because there was no
response from the test head.
On a HUB this condition error could error if the HUB is not
sending its alarms to the LoopCare server that controls the
download. The HUB alarm server could be stopped or the
HUB could be sending alarms to a different server.
F-UNKNWN Could not identify reason for failure.
F-WIDEBAND Wideband software failed the download.
FTP OK For the HUB, the FTP portion of download has completed.
The update of individual cards in the HUB is in progress.

11-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Administering Software Downloads to Tollgrade Test
Devices System Administration Guide
Download Status Conditions

Status Term Significance

IN-PROGRESS The download has not completed but is in progress.
For the EDGE, this status does not appear for individual
cards. If the status for the EDGE is IN-PROGRESS, a dash
appears as the status for individual cards.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 11-25

System Administration Guide Administering Software Downloads to Tollgrade Test
Devices

11-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU),
RMU, RMU Offset, RMU-Tested EAIU
Group 12

Contents

• Introduction 12-2
• Entering a new Remote Terminal 12-3
• Entering a new RMU 12-5
• Determining the RMU Offset 12-9
• Adding a new RMU-Tested EAIU Group 12-14

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-1

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

Introduction

Overview This chapter describes the procedure for entering a new LTE (supported by a
Switch and an RMU), RMU, and RMU-Tested EAIU Group in the LoopCare OA&M
application.

These procedures must be performed by a user with LoopCare Administrator

permissions.

For more information about the forms and screens mentioned in this chapter, see
Chapter 5 in the Operations, Administration, and Maintenance (OA&M) Guide.

12-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Entering a new Switch-LTE

Entering a new Switch-LTE

Introduction This section describes the procedure for entering a new Switch-LTE with the
LoopCare OA&M application.

Procedure 1. Log in to the LoopCare server as mlt.

2. At the mlt: prompt, type the following command.
echo $TERM
3. Verify that the TERM variable is set to vt100.
4. If it is not, type the following command.
TERM=vt100; export TERM
5. Type the following command.
oam
The LoopCare OA&M main screen is displayed.
6. On the OA&M main menu, select the ADEF option and press <Enter>.
The ADEF menu is displayed.
7. Select the SWITCH option and press <Enter>.
The SWITCH form is displayed.
8. Enter a Switch Name.
If the Switch Name does not exist, you are prompted whether to create it.
9. Press Yes.
10. Enter appropriate values on the form.
11. When you are done entering the data on the form, press <F6> to access
the buttons at the bottom of the screen.
12. Select SAVE.
13. Press <F6> to move the cursor back into the form area.
14. Press <F10>.
The Navigation Menu is displayed.
15. Select the Switch-LTE option and press <Enter>.
The Switch-LTE page is displayed.
16. Use the down arrow key to access the first blank line on the page.
17. Enter data in the following fields.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-3

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

• LTE - user defined name up to 30 characters.

• LTE Type - must be “I.”
• Test Method - must be ‘R.’
18. Press <F6> to access the buttons at the bottom of the screen.
19. Select SAVE.
20. Press <F6> to move the cursor back into the form area.
21. Press <F10>.
The Navigation Menu is displayed.
22. Select the Switch - OE option and press <Enter>.
The Switch - OE page is displayed.
23. Use the down arrow key to access the first blank line on the page.
24. The value in the OE Type field depends on the switch type.
25. Enter the OE low and high values that define the OE range for this remote
terminals.
26. Enter the LTE name. The value must match the value you entered on the
LTE page.
27. Press <F6> to access the buttons at the bottom of the screen.
28. Select SAVE and press <Enter>.
29. Press <F6> to move the cursor back into the form area.
30. Press <F10>.
The Navigation Menu is displayed.
31. Select the MAIN option and press <Enter>.
32. The main Switch form is displayed.
33. Press <F6> to access the buttons at the bottom of the screen.
34. Select SUBMIT and press <Enter>.
35. Select QUIT and press <Enter>.
36. The OA&M main screen is displayed.

12-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Entering a new RMU

Entering a new RMU

Overview The values that uniquely identify an RMU are the Central Office EMU ID (800 in
this example), and the RMU Test Head ID (3 in this example). Before you enter
the RMU data, you must determine which CO EMU will be used in conjunction
with the RMU to perform tests at this remote site. You will also need to enter an
RMU Test Head ID that has not yet been used for this EMU.

Procedure 1. On the main OA&M screen select the ADEF option and press <Enter>.
The ADEF menu is displayed.
2. Select the RMU option and press <Enter>.
The RMU submenu is displayed.
3. Select the RMU option and press <Enter>.
The RMU TEST HEAD form is displayed.
4. Enter values in the following fields.
• RMU Test Head ID - this must be a new value
• The ID of the EMU that will be sending access commands to the switch to
allow testing at the RT.
• The DCN ID is pre populated with the same DCN ID as is associated with
the CO EMU.
5. Press <Enter>.
A message is displayed prompting whether you want to create a new RMU.
6. Press <Enter>.
7. Use the following table to populate the remainder of the form.

Field Description
Identification User-defined name.
Communication Info Select Modempool.
Dialup Group Enter the 1 or 2 digit numeric ID of the Dialup Group.
Test Head TN Enter the 7 digit TN used to dial the RMU.
Enhanced RMU Press the space bar to check the box.
Computer Password User-defined value

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-5

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

Field Description
Human Password User-defined value
Baud Rate Select Auto.

8. Press the F6 key to access the command buttons.

9. Select SAVE and press <Enter>.
10. Press <F10>.
The Navigation Menu is displayed.
11. Select the LTE - RMU option and press <Enter>.
The LTE - RMU page is displayed.
12. Enter values in the following fields.
• Switch
• LTE - this value must match the remote terminal name you entered
previously on the SWITCH/SWITCH - LTE page.
13. Press <F6> to access the command buttons.
14. Select SAVE press <Enter>.
15. Press <F10>.
The Navigation Menu is displayed.
16. Select the MAIN option and press <Enter>.
The RMU TEST HEAD form is displayed.
17. Press <F6> to access the command buttons.
18. Select SUBMIT and press <Enter>.
19. Press <F6> to access the command buttons.
20. Select QUIT and press <Enter>.
The main OA&M screen is displayed.
21. Select the UIP option and press <Enter>.
22. Press <Enter>.
The UIP MAIN MENU is displayed.
23. Enter 2 for Database Administration and press <Enter>.
24. Enter 3 for Activate and press <Enter>.
25. Enter 3 to perform the Activation and press <Enter>.
The results of the activation are displayed.

12-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Entering a new RMU

The LTE and RMU data that had been entered is now in the active area of
the database.
26. Press <Enter>.
The Database Activation menu is displayed.
27. Enter q and press <Enter>.
28. The main OA&M screen is displayed.
29. Press <Enter> twice to exit the OA&M utility.

Downloading RMU Use the following procedure to download the new RMU data to the RMU.
Data to the RMU 1. At the mlt: prompt, type the following command and press <Enter>.
mTRM 01
2. Use Ctrl-z to clear the screen.
3. Enter the following command and press <Enter>.
/FOR SAM
4. The SAM mask is displayed.
5. Use the following table to populate the SAM mask.

Field Description
SYSTEM Enter M2.
PRTR Enter the printer ID of a printer connected to the
LoopCare server.
BY Enter your initials.
REQ Enter DLOAD -M# in the REQ: field, where # is the
RMU Test Head ID you entered previously.
NPANXX Enter the NPANXX associated with the phone to be
tested.
OVER Enter the EXK associated with the Central Office EMU
that will be sending access commands to the switch to
allow testing at the RT.

6. Press <Enter> to submit the DLOAD request.

A 'REQUEST IN PROGRESS' message is displayed on the bottom of the
screen.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-7

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

The EXK field is populated with the value that you entered in the OVER:
field.
After approximately 45 seconds, the results of the download are displayed.
The RMU can now be used for testing.
7. Use Ctrl-d to exit the SAM mask.

12-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Determining the RMU Offset

Determining the RMU Offset

Overview The following procedures enable the LoopCare Administrator to determine and
configure the RMU Offset for a given remote Digital Loop Carrier (DLC) location.
The reason for setting an RMU Offset is to eliminate the footage inherent to the
metallic test path between the DigiTest test head and the cross box from
measurements returned by test requests. This results in a 0 feet "Open In" test
result at the cross box if a cable pair is not connected to the channel unit
appearance.

Only one RMU offset value is required per DigiTest test head. Multiple systems
that share the same DigiTest system use the same offset value.

Determining the Use the following procedure to determine the RMU offset value.
RMU Offset Value
Refer to Figure 12-1 for the steps in this procedure.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-9

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

T
Channel
R
Unit
Metallic Test Bus

Digital Loop Carrier - Termination Block

Protection Coils

T
MTAU* R

Digital Loop Carrier System

Cable Pairs - Termination Block
* MTAU - Metallic Test Access Unit
Lucent AnyMedia - CTU
Lucent SLC-2000 - PTU
Lucet Series-5 - CTU Cross Box
AFC UMC-1000 - MTU
R T
DMU DWU
DigiTest DigiT est
STATUS

STATUS
TOLLGR ADE

TOLLGR ADE

D i gi Tes tDigital Measurement Node

DATA

DATA

PWR

FAN
STATUS TO L L G R A D E

Tollgrade - DigiTest (If Equipped)

Digital Loop Carrier Enclosure

NID

Telephone

Figure 12-1. RMU/RMU-S Offset Diagram

NOTE:
This procedure affects service for one customer. Avoid having the cross
connect wire disconnected for a long period of time. It may be necessary to
reconnect the cross connect after Step 3. However, it will be necessary to
disconnect the jumper wire at the end of this procedure to verify that the
offset value was entered correctly. Once verified, the jumper can be
connected to its original position.

12-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Determining the RMU Offset

1. At the cross box, identify a working telephone number to be used for

setting the RMU offset value.
2. At the Digital Loop Carrier - Termination Block, remove the cross-connect
wire connecting the DLC channel unit to the outside cable pair.
3. Use the LoopCare GUI to perform a LOOPX test on the telephone number.
An "Open Out" condition with a loop length should be reported. The loop
length value is the offset value.
4. Record this value for later use.

Entering the RMU Use the following procedure to enter the RMU offset value in LoopCare.
Offset Value 1. Log in to the LoopCare server as mlt.
2. Enter the following command and press <Enter>.
echo $TERM
3. Verify that the TERM variable is set to vt100.
4. If it is not, enter the following command and press <Enter>.
TERM=vt100; export TERM
5. Enter the following command and press <Enter>.
oam
The main OA&M screen is displayed.
6. Select the ADEF option and press <Enter>.
The ADEF drop-down menu is displayed.
7. Select the RMU option and press <Enter>.
The RMU submenu is displayed.
8. Select the RMU option and press <Enter>.
9. Use Ctrl-l to bring up a list of existing RMUs.
10. Arrow down
11. Select the appropriate RMU and press <Enter>.
12. Tab down to the Offset field and enter the measured offset value.
13. Press the F6 key to access the command buttons.
14. Select SUBMIT and press <Enter>.
The new data is saved and submitted.
15. Press <F6> to access the command buttons.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-11

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

16. Select QUIT and press <Enter>.

The main OA&M screen is displayed.
17. Select the UIP option and press <Enter>.
The UIP drop-down menu is displayed.
18. Press <Enter> again.
The UIP main menu is displayed.
19. Enter 2 for Database Administration and press <Enter.>
20. Enter 3 for Activate and press <Enter>.
21. Press 3 again to perform the Activation and press <Enter>.
The results of the activation are displayed.
The offset data that has been entered is now in the active area of the
database.
22. Press <Enter> to display the Database Activation menu.
23. Enter 'q' to return to the main OA&M screen.
24. Press <Enter> twice to exit the OA&M utility.

Loading the Offset Use the following procedure to download the Offset value to the DMU.
Value to the DMU 1. At the mlt: prompt, type the following command.
mTRM 01
2. Use Ctrl-z to clear the screen.
3. Type the following command.
/FOR SAM
4. The SAM Mask is displayed.
5. Use the following table to populate the fields on the SAM Mask.

Field Description
SYSTEM Enter M2.
PRTR Enter the name of a printer attached to the LoopCare
server/
BY Enter your initials.

12-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Determining the RMU Offset

Field Description
REQ Enter DLOAD -M#
where # is the RMU Testhead ID.
NPANXX Enter the NPANXX of a phone associated with the
NPANXX.
OVER Enter the EXK that is associated with the Central Office
EMU that will be sending access commands to the
switch to allow testing at the RT.

6. Press <Enter> to submit the DLOAD request.

A 'REQUEST IN PROGRESS' message is displayed on the bottom of the
screen.

NOTE:
When you submit the request, the EXK that you had entered in the OVER:
field is moved to the EXK: field.

After approximately 45 seconds, the results of the download are displayed.

The RMU can now be used for testing.
7. Press Ctrl-d to exit the SAM mask.
8. At the mlt: prompt, type exit and press <Enter> to log off the LoopCare
server.

Verifying the RMU- Use the following procedure to verify that the RMU-S Offset was entered correctly.
S Offset Entry 1. Disconnect the cross connect jumper at the cross box.
2. Perform a LOOPX test on the phone number.
An "Open In" with 0 feet should result instead of the "Open Out" with
footage.
3. Replace the cross connect jumper to its original position.
4. You have completed this procedure.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-13

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

Adding a new RMU-Tested EAIU Group

Introduction A Tollgrade DMU configured as an RMU (that is, a DMU-R) tests lines in an EAIU
or an EAIU cluster. The DMU-R is to be connected and assigned to the Metallic
Test Bus (MTB) for one and only one Service Group for all EAIUs in that cluster.
(For more information see 19v16 SM UNIT (RC_EUAIU), Lucent Technologies
document number 235-118-256.). Disable the Diode Protocol check for the MTB
for Service Group 0 (for more information, see 5ESS Recent Change View 22v11
ISDN - EQUIPMENT (RC_RPSITE), in the same document). The MTB for Service
Group 1 is to be either disabled or deployed with MCU extensions to support
Trunk and Line Work Station (TLWS) and Automatic Line Insulation Test (ALIT)
testing.

RMUs associated with EAIUs must be assigned to equal numbers of Service

Group 0 and Service Group 1 MTBs to balance the testing traffic load. At the EAIU
site, the RMU must be connected to the MTB appearance for the same Service
Group on all EAIUs that are to be tested by that RMU. An RMU may be connected
to no more than four (4) EAIUs at a site.

NOTE:
It is recommended that each RMU be connected to only 2 EAIUs.

At large sites that have many EAIUs, the EAIUs must be placed in clusters of four
or less, and each of these clusters must be tested by a single RMU.

Procedure Use the following procedures to configure a new RMU-Tested EAIU Group.
1. Login to the LoopCare server as mlt.
2. Start the OA&M application.
3. Select the ADEF option on the main menu bar.
4. Select the SWITCH option on the ADEF drop-down menu.
5. Select the switch which is connected to the EAIU site.

NOTE:
For an EAIU, the Switch Type must be 7 or 32.

6. Press <Enter> to place the cursor in the main area of the switch form.
7. Press the <F10> key to display the Navigation Menu.
8. Select the SWITCH - LTE option.

12-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Adding a new RMU-Tested EAIU Group

The SWITCH - LTE form is displayed.

9. On a new line enter the information indicated in Table 12-1

Table 12-1. Descriptions of Fields on the Switch-LTE Form

Field Description
LTE Enter the RMU defined to support the EAIU.
LTE Type Enter “E” to indicate that the remote is an EAIU.
Test Method OA&M populates this field with “R”. This is the only valid
value if LTE Type is “E”. Do not modify this value.
All other fields Disabled when LTE Type = “E”.

10. Repeat this step for each EAIU at the site.

11. Save the changes.
12. Return to the SWITCH form and select the same switch.
13. Press the <F10> key to display the Navigation Menu.
14. Select the SWITCH - OE option.
The SWITCH - OE form is displayed.
15. On a new line enter the information indicated in Table 12-2

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-15

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

Table 12-2. Descriptions of Fields on the Switch-OE Form

Field Description
OE Type Enter "E" for EAIU.
ADEF sets the Switch OE Low Range and Switch OE
High Range format for the EAIU
Switch OE Low Range Enter the first two fields of the Switch OE (SM and AIU
numbers) associated with the EAIU.
The last two fields of the OE Low Range cannot be
changed by the user but are provided to show the
complete OE and its valid ranges.
Switch OE High Range ADEF populates the first two fields under the "Switch
OE High Range" heading with the same data from the
"Switch OE Low Range" (the last two fields of this OE
cannot be changed by the user but are provided to
show the complete OE and its valid ranges).
The first two fields of the "Switch OE High Range" must
remain the same as those in the "Switch OE Low
Range" even though they can be changed by the user.
LTE Enter the LTE identification that was entered on the
SWITCH-LTE form.
All other fields. Not used for this case.

16. Repeat the previous step for each EAIU that is tested by an RMU.
17. Save the changes.
18. Save and Submit the SWITCH changes.
19. Open the OAM/ADEF/RMU/RMU screen
20. Enter the RMU Test Head Number of the RMU at the EAIU site.
21. Enter the Test Head number of the EMU that tests the 5ESS Host switch or
RSM and the associated DCN number.
22. Enter the RMU Identification for the RMU at the EAIU site and fill in the
remainder of the fields on this screen as appropriate.
23. Fill out the RMU COMMUNICATION screen as appropriate and save the
changes.
24. On the LTE - RMU screen enter the Switch ID and the LTE ID for an EAIU
that will be tested by the RMU.
25. Repeat Step 24 for each EAIU that will be tested by the RMU.

12-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group System Administration Guide
Adding a new RMU-Tested EAIU Group

26. Save the LTE - RMU changes.

27. Save and Submit the RMU changes.

RMU Loop Length LoopCare uses the RMU length Offset for calculations of standard loop lengths on
Offset measurements done from the DMU-R at the EAIU site. The default value of this
offset is zero. The 5ESS trunk calibration data for trunks at the Host or RSM is not
be used for calculations at the EAIU/RMU site.

At installation, the RMU standard length Offset is calibrated as follows:

• On the ADEF RMU Test Head screen, set the Offset to zero (0).
Save and submit the changes. Then run a DLOAD to the RMU.
• At the EAIU/RMU site select a line that is open at the local
distributing frame or temporarily open a subscriber line at the frame.
• Run a LOOP test on the selected line and record the loop length that
is displayed.
• On the ADEF RMU Test Head screen, set the Offset to the loop
length measured in the above step. Save and submit the
changes.Then run a DLOAD to the RMU.
• Run a LOOP test on the selected line and verify that the reported
length is now close to zero and that the VER code displayed is VER
3 (OPEN IN).

If a subscriber line was used for the calibration, connect the loop back to the line
appearance on the frame.

NOTE:
In the EAIU/RMU environment, the enhanced loop length will not be used.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 12-17

System Administration Guide Entering a new LTE (Switch and RMU), RMU, RMU
Offset, RMU-Tested EAIU Group

12-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files A

Introduction to GDF Files

Overview This appendix discusses the Group Descriptor Files (GDF) for the LoopCare and
LoopCare/ISDN applications on the Front End. Following are some general
concepts about GDFs.

What is a GDF File? In an application like LoopCare, a set of related software modules are required to
perform the designated functions of the application. This set of modules is termed
a "group".

The GDF defines the modules that are members of the group. The group is
stopped and started by a process called the group manager.

In addition to listing all the modules in the group, the GDF defines the options
submitted to those modules, and the "port" names that the modules will use while
running (specific processes from which data is received or to which data is given).
The group manager will read the GDF file, interpret the instructions for each
module, and execute the functions required to start or stop the software modules -
- according to the options they are running.

Function By allowing the user to specify the options that each software module in the
application will run, the user will affect the way LoopCare testing is performed in

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-1

System Administration Guide Group Descriptor Files
Introduction to GDF Files

that operation. The GDF file, therefore, is the tool by which the application can be
tailored to the particular characteristics of the user's operation.

Structure Each line of a GDF file is structured to contain the following information:

Module The Identification of the module, utility, or process that is

to be brought up (run). For Unix Shell utilities, the
"module" is "/bin/sh". Note that "module," as used here
is not strictly limited to software modules, which are
usually compiled executable binary files. We will use the
word "module" to mean the first item on each line in the
GDF file.

The Identification of the module, utility, or process that is

to be brought up (run). For Unix Shell utilities, the
"module" is "/bin/sh". Note that "module," as used here
is not strictly limited to software modules, which are
usually compiled executable binary files. We will use the
word "module" to mean the first item on each line in the
GDF file.
Some "modules" begin with a letter followed by a colon.
These are special instructions to the Group Manager
about when the utility is executed. Following is a list of
these letters and a brief explanation of their usage.
I Bring up this process prior to other processes.
R,n Restart this process, where "n" indicates the number of
restart attempts. The "n" is optional and the default
value for all processes is one (1) if no other number is
indicated.
d Drop this process and continue with all other processes.
F Fatal the group if this process dies.
E Execute this process upon Group termination.
S Do not synch this module with the group manager, (i.e.,
the process runs independently). Note that the S: is not
user-changeable.

A-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Introduction to GDF Files

Continued on next page

Options This is the second item on each line. Options are the
arguments that are invoked when a module is brought
up, or the name of the shell utility. Although not
technically "options," this word will be used throughout
the GDF section.

The options define different features that can be

executed by the associated module or shell. More than
one option can be associated with each module.

Each option is separated by a comma, and options are

preceded by a "-" except where noted. For example,
-s, -n
would be options on a GDF line.

NOTE:
Every module in the GDF file must have an option
entered on the line. If the module has no real
functional options the "dummy" option must be
used. The dummy option is not preceded by a "-".
The option entry is required so that the system
can correctly identify the module, option, and port
name by their position on the GDF entry line.
Port The port name is the name of the channel that the
module will create and send information over. Modules
may have one or more port names associated with
them. In many cases the module and the port name are
the same, but this doesn't have to be the case.
As we will see in the section on tracing, the port name of
a module must be known to initiate tracing from the UIP.

GDF File Structure Hierarchy of GDFs

Keep in mind as you study the GDF files, that the LoopCare application on the
Front End has a total of seven possible associated groups. Each group has its

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-3

System Administration Guide Group Descriptor Files
Introduction to GDF Files

own GDF file. The hierarchy of the software groups (and thus their GDF files) is as
follows:
MLT

MDMN

MGRP

M1 M2 MPST ISDN* SDV CGRP

* MLT/ISDN is a separate feature of the Mechanized Loop Testing Sys-

tem which is used to test Integrated Services Digital Network lines. It is
not included with a standard MLT-4 platform.

What this hierarchy means is that a group can only run if the group above it is also
running. Parallel groups may run independently.

Group Fatal It is important to note that if one of the groups on the GDF hierarchy fatals, it may
Recovery be necessary to bring up groups that are located below the fataled group. For
example, if the MDMN group fatals, the MGRP, M1, M2, MPST, ISDN and CGRP
groups may need to be restarted. This depends on whether the -S option, (which
brings up the group manager in the idle mode), appears on the grpmgr line of the
gdf file.

This logic is specific to the LoopCare application. For information about BASE
fataling and the effect on the LoopCare application, see instructions in the BASE
document 450.gdf_files (or 451.gdf_files for those customers with standard UNIX
System V or later).

NOTE:
Not all possible options for each GDF file are included in these documents.
Some options are associated with security or billable features and are
addressed separately in their own documents (not in an on-line format).

A-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MLT Group

Group Descriptor File for the MLT

Group

MLT Group

Name Directory Level

MLT.gdf /base/config 1st level of
LoopCare

The MLT group is the top level group of the LoopCare application. This group is
brought up by BASE on the Front End. The MLT group includes the following main
functions:
• The RDBMS which is involved in storing LoopCare databases and includes
some LoopCare utilities.
• The communications and Mask interface processes.
• Error message handling and tracing functions.
• Brings up the MDMN group.

All other LoopCare application groups are below the MLT group. These other
groups include:
MDMN
MGRP
M2
MPST
ISDN
CGRP

Standard gdf File This Appendix describes all of the options available to the modules in this group,
Release except for those options associated with special billable features or security
options. Not all the options listed in this Appendix are required to be set up in the
gdf file. The system will be released with a MLT.gdf file which includes a standard
configuration of modules with appropriate options. It is suggested that the user run
with this standard gdf file and make adjustments only when conditions require.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-5

System Administration Guide Group Descriptor Files
Group Descriptor File for the MLT Group

Description of GDF Module I:/base/bin/shrdemon

Information
Module Port(s)
I:/base/bin/shrdemon XX

This instructs shrdemon to free any shared memory descriptors that have been
left following a fatal. This is a preprocessing line required for all group managers.
The port name (XX) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Module I:/usr/lbin/

Module Port(s)
I:/usr/lbin/ IPDEMON

This module prints information about the interprocess message queues within the
kernel address space.

The module is a BASE module that runs in the LoopCare application. For the
most recent information about the options for , refer to the document 451. in the
BASE user document.

Module I:/$MLT_BIN/chk-oracle

Module Port(s)
I:/$MLT_BIN/ chk_oracle
chk_oracle

This module checks to make certain ORACLE is running before starting the
groups. If ORACLE is not running, LoopCare will not start. There are no options to
set for this file. This module may be defined to run as part of multiple groups (i.e.,
MLT, MDMN, MGRP, etc.).

A-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MLT Group

Module I:/bin/sh $MLT_UTL/mltclean.sh

Module Port(s)
I:/bin/sh $MLT_UTL/ mcln
mltclean.sh

The mltclean.sh module backs up old error, log and monitor files and removes the
originals every time the MLT group is started. These files are:
• In $MLT_ERR, *.err
• In $MLT_TMP, pst*.log, pst*.mon, kmsmsgcnt.out (VAX) commmsgcnt.out
(HP), mltuip.out and DZ_Sendf
• In $MLT_RPT, TAF.STAT, UNTESTED.STAT, LTE.STAT, D*REPORT,
M*REPORT, m1failover, RMU.ERR, CMURMU.ERR, and HubAlarm.txt.

The original files are concatenated into the back-up files, which are prepended in
the form s0.<filename>; when these back-up files reach a user-definable limit,
they are moved to files in the form s1.<filename>, writing over the previous
contents of s1.<filename>.

You must edit the MLT.gdf file to remove the # from the beginning of the
mltclean.sh line in order to activate this feature.

Option Description
-L Sets the file size in bytes at which mltclean.sh will move
s0.<filename> to s1.<filename>. By default, this
threshold is set to 64K bytes.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-7

System Administration Guide Group Descriptor Files
Group Descriptor File for the MLT Group

Module S:$MLT_BIN/emh

Module Port(s)
S:$MLT_BIN/emh emh

The emh module covers the Error Message Handling for the system. It processes
error returns and routes error messages to the correct administrative positions.

Option Description
dummy Default Null entry.
-s,XX This option overrides the default SYSTEM name, in the
SYSTEM:XX field, on the printer output. XX may be any
one or two alphanumeric character name.
-o,<printername> This option sends emh output to the printer that you
name. If this option is not turned on, no emh output will
be printed.

Module $MLT_BIN/merUtil

Module Port(s)
$MLT_BIN/merUtil meru

The merUtil is required for the TURNSTONE CX100 feature.It assists in re-estab-
lishing Turnstone CX100 interconnects during LoopCare testing.There are no
options for this module.

Module $MLT_BIN/pingdmn

Module Port(s)
$MLT_BIN/pingdmn pingd

The pingdmn module pings the 6061 and DT4000 units on an LTCN to check for
problems.

Option Description
dummy Default Null entry.

A-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MLT Group

Module F:/base/bin/xlate

Module Port(s)
F:/base/bin/xlate XPML, MAS, MAS2, XLATE, PAK

The xlate module is a BASE module that runs in the LoopCare application. For the
most recent information about the options for xlate refer to the BASE document
451.gdf_files.

Module F:$MLT_BIN/wgrp

Module Port(s)
F:$MLT_BIN/wgrp wgrp

The purpose for the wgrp module is to watch a "core" group and to determine if it
is running. You must edit MLT.gdf file to remove the # from the beginning of the
wgrp line to activate this feature. The default group that wgrp watches is MGRP.
Wgrp serves two functions.
1. wgrp is the trigger for LoopCare failover in the ANS interface if the core
group is seen as active and then not active. wgrp sends messages to the
console after every interval that the core group is inactive. At the end of a
fixed amount of time, wgrp will fatal itself thereby stopping the base MLT
group which in turn halts the xlate process. When the xlate process is
halted, ANS is informed that LoopCare is not active. ANS in turn switches
to its backup LoopCare processor.
2. wgrp is a warning mechanism if the core group is never brought up. When
the optional -w argument is used, wgrp begins to issue warning messages
to the console that the core group is not up after a fixed amount of time.

Option Description
dummy Default Null entry.
-g,XX Set the core group. The default value is MGRP.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-9

System Administration Guide Group Descriptor Files
Group Descriptor File for the MLT Group

Option Description
-h,XX Set the time to halt wgrp. The default time is 10
minutes. The minimum time setting is 5 minutes. There
is no maximum time setting limit. (When setting a time
value of less than 10 minutes, do not use a zero in the
first position; for example, to set 6 minutes enter "-h,6"
not "-h,06").
-i,XX Set the interval period in seconds between wgrp's
query. The default interval is 30 seconds and the
minimum interval allowed is 15 seconds. There is no
maximum interval limit, however, if -i,XX and -h,XX are
set such that -i,XX > -h,XX, then the interval period will
revert to the 30 second default setting.
-w,XX Set the wait time in minutes to see the core group is
active before issuing warning messages. The default is
10 minutes and the minimum time setting permitted is 5
minutes. The MGRP will usually take up to 5 minutes to
start. There is no maximum setting limit. (When setting
a time value of less than 10 minutes, do not use a zero
in the first position; for example, to set 6 minutes enter
"-w,6" not "-w,06").

Module /base/bin/grpmgr

Module Port(s)
/base/bin/grpmgr MDMN

This is the call to the group manager that will bring up the next group in the
hierarchy- the MDMN group. For the most recent information about the options for
grpmgr refer to the document 451.gdf_files in the BASE user document. The
options for grpmgr will be the same as those for GRPMGR in BASE.

A-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MLT Group

Module d:$MLT_BIN/sigadm

Module Port(s)
d:$MLT_BIN/sigadm sigadm

This module handles Programmable DC signatures when the MLT_PDC variable

is set to ON, indicating that the user is requesting a maximum of 191 signatures.
The sigadm module processes all CVER and DVER requests from the SAM
mask. Additionally, sigadm on the master LoopCare machine is responsible for
keeping the LoopCare and LMOS applications on all other machines up to date
with the latest signature record and status updates.

Option Description
-t This option allows the user to set the tracing level
associated with the sigadm module. The correct format
is "-t,#" (where # can be 0, 1, 2, or 3). By default, the
tracing level of sigadm is set to the value of the
MLTTRACE environmental variable.
-o This option disables matching for all requests.The user
is still allowed to display the signature records and
update them (using DVER and CVER request from the
SAM mask), but no matching will be performed. Using
the "-o" option also makes the use of DVER -D and
DVER -E requests illegal. This is because these special
DVER requests are used to disable and enable
matching, but this cannot be allowed if the "-o" option is
used.
-h This option disables matching for requests from LMOS
and PREDICTOR. It works in much the same way as
the "-o" option, except that matching will still be
performed for requests from TV and CAS.
The DVER -D and DVER -E requests are also allowed,
but will not effect the matching for LMOS or
PREDICTOR requests (which have been disabled).
-s This option disables matching for requests from
PREDICTOR only. Matching will still be performed for
requests from LMOS, TV, and CAS. The DVER -D and
DVER -E requests are allowed, but will not effect the
matching for PREDICTOR requests (which have been
disabled).
dummy Default Null entry.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-11

System Administration Guide Group Descriptor Files
Group Descriptor File for the MLT Group

Module R9:$MLT_BIN/tfeat

Module Port(s)
R9:$MLT_BIN/tfeat tfeat

The tfeat module administers toggleable LoopCare features by carrying out the
following three functions:
• it analyzes all LoopCare features, on startup, and determines which are
toggleable
• it resynchronizes modules associated with each feature if the tfeat module
goes down, or if those modules should otherwise get out of sync
• it accepts feature toggle messages from a utility program and updates any
modules associated with a particular feature.

NOTE:
This module requires that the group be bounced if the mlt.feature file in the
/mlt/config directory is changed.

Option Description
dummy Default Null entry.
-trace, n Where "n" is the desired tracing level (0 - 3).

Module R9:$MLT_BIN/tipdb

Module Port(s)
R9:$MLT_BIN/tipdb tipdb

This module receives line record requests from the tip module and retrieves the
line records from LMOS thereby freeing tip from network and remote Front End
problems.

Option Description
dummy Default Null entry.
-trace, n Where "n" is the desired tracing level (0 - 3).

A-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MLT Group

Module E:/base/bin/shrdemon

Module Port(s)
E:/base/bin/shrdemon YY

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Module E:/bin/sh

Module Port(s)
E:/bin/sh dzk2

This module stops Dzmaster.

Option Description
$MLT_UTL/DZKILL This option stops Dzmaster. This is the same option
that can be executed under MDMN.gdf; the intentional
redundancy is a fail-safe feature.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-13

System Administration Guide Group Descriptor Files
Group Descriptor File for the MLT Group

Module E:/bin/sh

Module Port(s)
E:/bin/sh dmnk2

This function kills all communications processes when the MDMN group is
stopped.

Option Description
$MLT_UTL/DMNKILL This is the pathname of the kmsdmn (VAX) or
commdmn (HP) kill process. This is the same option
that can be executed under MDMN.gdf; the intentional
redundancy is a fail-safe feature.

Module d:$MLT_BIN

Module Port(s)
d:$MLT_BIN/fsckr fsckr

This is a watchdog module which checks (at the frequency that is specified with
the -f option) the size of the LoopCare file system and issues a warning message
to the console and fsckr.err error log file when the system begins to run short on
the LoopCare file system space

A-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MLT Group

By default, it also removes GUI previous test results files, leaving the most recent
100 in each GUI user directory. (See the -C, -N, -O, and -S options.).

Option Description
-t This refers to the threshold, of the LoopCare file system
disk space, at which the warning message should be
printed out to the console. There isn't any specified
threshold value but the default should be 85% (e.g. -
t,85). The recommended upper limit is 90%. If it goes
beyond 90%, then there is risk of the LoopCare system
entering into a non-functional state.
-f,n This option specifies the time interval in seconds, n, that
determines how frequently the warning message is
displayed on the console.
The default is 1200 seconds.
-d This option indicates the total disk space that is
available for the /mlt file system. For HP11I, to
determine the number of available blocks, enter df -t on
the command line. This will produce a list of all the
directories on that system. Look for the entry called "/
mlt", on the second line will be the word total; followed
by the number of blocks. (The default on the HP is
1,000,000).
For SUN Servers, use the command df -k /mlt and
specify the total number of kbytes for this option.
-i,n This option specifies the time interval in secpnds, n, that
determines the frequency of tracing.
The default is 20 seconds.
The value of this option should be a multiple of the -f
option value.
-r, n This refers to the percentage of disk space reserved for
use by the superuser in the /mlt file system (HP T500
only). To determine this value enter "df -t /mlt" on the
command line. The reported "percent minfree" value is
the percentage of reserved disk space. If not entered,
this value defaults to 10 percent.
-C,<New Dir Path> If the /mlt/reports/cgi path (for GUI test results) has
changed, this option allows you to change it on the fly.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-15

System Administration Guide Group Descriptor Files
Group Descriptor File for the MLT Group

Option Description
-N,x This option allows you to change the number of files left
in the GUI user directory from 100 to x.
-O This option turns off the default behavior of deleting or
moving excess previous result files.
-S With this option, the excess previous results files are
moved to a directory called savdir, under the GUI
tester’s directory.

Module d:$MLT_BIN

Module Port(s)
d:$MLT_BIN/killproc killproc

This utility terminates any stranded processes. It is executed as part of the

shutdown of the LoopCare application in the MLT, MDMN, MGRP, M2, MPST, and
CGRP layers/

The most common usage of killproc is the inclusion a killproc entry in each.gdf file.
For example, MGRP.gdf would include
E:$MLT_BIN/killproc -f,MGRP.gdf killproc

A parent .gdf file may also contain the killproc entries for its child group managers.
For example, the MGRP.gdf file may contain killproc entries for itself, M2, and
CGRP. In this case, M2.gdf and CGRP.gdf would not contain a killproc entry.

Whenever a .gdf file contains multiple killproc entries, each entry must use a
different port name, specified in the right most column in the .gdf file. For example:
E:$MLT_BIN/killproc -f,MGRP.gdf killproc
E:$MLT_BIN/killproc -f,M2.gdf killproc1
E:$MLT_BIN/killproc -f,CGRP.gdf killproc2

Dummy entries are not allowed.

A-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MLT Group

Option Description
-f <group name>.gdf MLT.gdf
MDMN.gdf
MGRP.gdf
M2.gdf
MPST.gdf
CGRP.gdf
-m Check for any stranded grpmgr maint processes and
terminate them.

Example of GDF file Below is an example of the MLT.gdf file

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-17

System Administration Guide Group Descriptor Files
Group Descriptor File for the MDMN Group

Group Descriptor File for the MDMN

Group

Description

Name Directory Level

MDMN.gdf /base/config 2nd level of
LoopCare

The MDMN.gdf is responsible for bringing up the different daemon processes on

the Front End. The MDMN group is the second level group of the LoopCare
application. This group is brought up either by the MLT group on the Front End, by
UIP, or by BASE UIP.

When using either UIP or BASE UIP to bring up the MDMN group, the software
first checks to verify that DKTRAM is running. If DKTRAM is not running, MLT/
BASE will prompt:
DKTRAM not running. Do you want it started (y or n)?

If NO (n) is entered, MLT/BASE will return the following messages:

The MDMN Group Cannot run without DKTRAM.
The MDMN Group will remain down.

If YES (y) is entered, MLT/BASE will notify the user that it is starting DKTRAM.
When DKTRAM has successfully started, MLT/BASE will return the message:
Wait Completed.

MDMN can then be brought up.

If DKTRAM cannot be started, MLT/BASE will return the following messages:

DKTRAM did not start within 4 minutes.
The MDMN Group Cannot run without DKTRAM.
The MDMN Group will remain down.

MDMN Group The MDMN group includes the following main functions:
Functions • Controls all daemon functions on the LoopCare machine which involve:
— Communications daemons for communications ports connected to
Dens

A-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MDMN Group

— DMZ, or DZ daemons which control dial out or asynchronous ports

— M1 daemon that communicates with LTF Controllers
• Brings up the MGRP group.

All other LoopCare application groups (except MLT) are below the MDMN group.
These other groups include:
MGRP
M2
MPST
ISDN

Standard gdf File This section describes all of the options available to the modules in this group,
Release except for those options associated with special billable features or security
options. Not all the options listed in this section are required to be set up in the gdf
file. The system will be released with a MDMN.gdf file which includes a standard
configuration of modules with appropriate options. It is suggested that the user run
with this standard gdf file and make adjustments only when conditions require.

Description of GDF Module I:/base/bin/shrdemon

Information
Module Port(s)
I:/base/bin/shrdemon XX

This instructs shrdemon to free any shared memory descriptors that have been
left following a fatal. This is a preprocessing line required for all group managers.
The port name (XX) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-19

System Administration Guide Group Descriptor Files
Group Descriptor File for the MDMN Group

Module I:/bin/sh

Module Port(s)
I:/bin/sh dmnk1

This function insures that communications daemon processes that are running
and may interfere with the normal start of this group are killed.

Option Description
$MLT_UTL/DMNKILL This is the path name of the function that will kill
unwanted communications daemon processes. This
process is repeated in the E:/bin/sh module.

Module I:/bin sh

Module Port(s)
I:/bin sh dmnkdzk11

This module stops DZmaster.

Option Description
$MLT/UTL/DZKILL This option stops DZmaster.

Module I:/$MLT_UTL/dumpenv

Module Port(s)
I:/$MLT_UTL/dumpenv dumpenv

This module creates an environment file for use by MLT DKTRAM cprocesses.

Option Description
$MLTENV This is the name of the file containing the data.

A-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MDMN Group

Module I:/bin/sh

Module Port(s)
I:/bin/sh dzst

This function insures that the daemons for DZ and DMZ ports are started on the
Front End. These daemons are used in the communication between the Front
End and CMU/RMUs.

Option Description
$MLT_UTL/DZSTART This is the path name of the module that starts DZ or
DMZ daemon on the Front End that are used to
communicate with CMUs and RMUs.

Module I:bin/sh

Module Port(s)
I:bin/sh commst

This function will make connections from vpm devices to LoopCare

communications devices. It will also download scripts and start the commdmn
processes.

Option Description
$MLT_UTL/ This is the path name for the module that will start
COMMSTART commdmn processes, download scripts, and make
comm connections.
or
$MLT_UTL/
LTCNSTART

Use the guidelines in the following table to decide whether to use COMMSTART
or LTCNSTART. If ACC-MUX hardware is installed, then the associated HP
software has also been installed with ZCOM libraries.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-21

System Administration Guide Group Descriptor Files
Group Descriptor File for the MDMN Group

HP 10.20/11.0 HP 11.0
with ACC- without ACC- 11i with ACC- 11i without
MUX MUX MUX ACC-MUX SUN
DCN COMMSTART Not Applicable COMMSTART Not Applicable Not Applicable
LTCN Not Applicable COMMSTART Not Applicable LTCNSTART LTCNSTART
DCN and COMMSTART Not Applicable COMMSTART Not Applicable Not Applicable
LTCN

Module I:/bin/sh

Module Port(s)
I:bin/sh loadfe

This module will automatically load the LoopCareFE database upon system
startup.

Option Description
$MLT_UTL/load_mltfe This is the path name for the module that will
automatically load the MLTFE database on startup.

Module I:/bin/sh

Module Port(s)
I:bin/sh ckph

This module will verify that the environment variable (PHID) contains the address
of the Front End. That address is necessary for commdmn to run. Without this the
MDMN group will not come up. When this happens an advisory message is sent
to the console.

Option Description
$MLT_UTL/checkphid This is the name of the utility that checks PHID.

A-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MDMN Group

Module d:$MLT_UTL/commmsgcnt

Module Port(s)
d:$MLT_UTL/ commm
commmsgcnt

This module counts the number of messages written into each DCN port.

Option Description
-g This option is MANDATORY. It indicates that the
commmsgcnt module must be brought up with the
group.

Module $MLT_BIN/d1_dmn

Module Port(s)
$MLT_BIN/d1_dmn d1dmn

This module is the M1 download daemon and manages LTF controller downloads.

Option Description
-m,$M1CTLS This option determines the maximum number of LTF
Controller downloads that can run at one time on the
Front End. Where "$M1CTLS" is the number of
downloads permitted. Usually this value is set to the
number of LTF Controllers on the network. The default
value for this option is 25. Use UIP to change the value
of $M1CTLS.
-t,n This option turns on tracing for the module at a
specified level. Where n is the level having values of 1,
2, or 3. The default level depends on how the group was
started.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-23

System Administration Guide Group Descriptor Files
Group Descriptor File for the MDMN Group

Option Description
-e,$MLTENV This is a MANDATORY entry for this module. It
identifies the file containing environmental variables to
be used by cprocesses. Do not change the value of
$MLTENV.
-s,n This is the Start Pause option. It determines the amount
of time this module will wait after it completes a
download to signal the Front End that a new virtual
channel to the Controller should be set up. Where n is
the number of seconds to pause. The default value for
this option is 10 seconds.
-p,n This is the Stop Pause option. It determines the amount
of time this module will wait To start a new virtual circuit
for a download. When a download request is sent the
dl_dmn module advises m1dmn to stop the existing
virtual circuit to the Controller. The dl_dmn module will
then wait n seconds before it attempts to start a new
virtual circuit. The default value for this option is 10
seconds.

A-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MDMN Group

Module $MLT_BIN/m1dmn

Module Port(s)
$MLT_BIN/m1dmn m1dmn

This module is the M1 communication manager. It manages all communications

to LTF controllers.

Option Description
-h,n The rate at which the Front End polls the LTF controller.
Where n is the number of seconds between polls. The
default is 3 seconds for this option.
-d,n This option turns on tracing for the module at a
specified level. Where n is the level having values of 1,
2, or 3. The default level depends on how the group was
started.
-v,$M1CTLS This option defines the number of virtual circuits that an
Front End can have to LTF Controllers in the network.
Normally this value should be set at the actual number
of LTF controllers in the network running off this Front
End. The default value for this option is 25. Use UIP to
change the value of $M1CTLS.
-T,n This option is a time check to determine how long to
keep a virtual circuit to an LTF Controller active after the
daemon believes that there are no more responses
coming from the controller. Where n is the number of
seconds to keep the circuit active. The default value for
n is 30 seconds, and the maximum value is 600
seconds. The -T option works with the -e option to
determine when to shut down. Both conditions must be
met.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-25

System Administration Guide Group Descriptor Files
Group Descriptor File for the MDMN Group

Option Description
-e,n This option is the Datakit delay time. Where n is the
number of seconds of the delay. The default value for n
is 10 seconds, and the maximum value is 60 seconds.

The system will maintain the Datakit virtual circuit to the

LTF controller for the specified timeout limit of the last
request sent (table defined per request) plus this
additional interval specified by this option. After this
combined time limit is exceeded, the virtual circuit will
be dropped.

Note that in no case will the time limit be reduced

because the last request has a smaller timeout limit. For
example, if n=20 seconds, and a TC (which has a 900
second timeout value) is run, the total timeout would be
920 seconds. If a DS is run next, (a 120 second timeout
plus 20 seconds from this option) this new timeout value
of 140 seconds will be compared against the existing
value of 920 seconds. The system will keep the larger
of the two values as the timeout interval.
The -e option works with the -T option to determine
when to shut down. Both conditions must be met.
-n,$MLTENV This option is MANDATORY for this module. It identifies
the files containing environmental variables to be used
by processes.
-E,n This is a time check expiration option. Where n is the
interval in seconds the Front End checks to see if the
communications link to the LTF controller is still
functioning. The default value is 10 seconds.
-r,n This is the time check DKTRAM connection option.
Where n is the interval in seconds the m1dmn will wait
for a DKTRAM connection confirmation before stopping
all communications to the LTF controller. The default
value is 30 seconds.
-s,n This option is the time interval that the Front End
checks the request queue and sends requests. Where n
is the number of seconds in the interval. The default
value is 5 seconds. Sometimes requests queue as the
system is waiting to establish a connection to the LTF
controller. To be sure that the requests on the queue are
acted upon the Front End checks this queue at regular
intervals specified by this option.

A-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MDMN Group

Option Description
-b,n This option determines whether or not requests will be
put on the queue if the system message queue is filled.
Where n has the value of either 0 (do not put request on
queue) or 1 (put request on queue). The default value
for this option is 1 (put request on queue).
-W,n This option specifies the number of message receive
errors from the reader cprocesses or other processes
allowed before the virtual circuit to the LTF controller is
dropped and the request queue is erased. Where n is
the value for the number of errors. The default value of
this option is 1.
-S,n This option specifies the number of send errors from the
m1dmn process to the m1dmn writer process allowed
before the virtual circuit to the LTF controller is dropped
and the request queue is erased. Where n is the value
for the number of errors. The default value of this option
is 1.
-A,n This option specifies the number of times this module
will attempt to establish a virtual circuit to the LTF
controller. Where n is the number of times the process
will try to connect. The default value for this option is 5.
-L,n This option specifies the maximum number of requests
that can be queued for a Controller. Where n is the
number of requests that can be queued. The default
value for this option is 20 requests.
-j,n This option identifies the time interval added to the
standard request timeout (2 or 10 seconds) that the
Front End will wait to receive a response from the LTF
controller. Where n is the value in seconds for this
interval. The default value for this option is 2 seconds.
-l,n This option specifies the time interval that the read
process from m1dmn will block on a read operation.
Where n is the number of seconds of this interval. The
default value for n is 4 seconds and the minimum value
is 2 seconds.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-27

System Administration Guide Group Descriptor Files
Group Descriptor File for the MDMN Group

Module base/bin/grpmgr

Module Port(s)
base/bin/grpmgr MGRP

This is the call to the group manager that will bring up the next group in the
hierarchy- the MGRP group. For the most recent information about the options for
grpmgr refer to the document 450.gdf_files in the BASE user document
(or451.gdf_files for those customers with standard UNIX System 5 or later). The
options for grpmgr will be the same as those for GRPMGR in BASE.

Module E:/bin/sh

Module Port(s)
E:/bin/sh dzk2

This module stops DZmaster.

Option Description
$MLT/UTL/DZKILL This option stops DZmaster.

Module E:/bin/sh

Module Port(s)
E:/bin/sh dmnk2

This function kills all commdmn processes when the MDMN group is stopped.

Option Description
$MLT_UTL/DMNKILL This is the path name of the commdmn kill process.

A-28 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MDMN Group

Module E:/base/bin/shrdemon

Module Port(s)
E:/base/bin/ YY
shrdemon

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Example of GDF Below is an example of the MDMN.gdf file.

File

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-29

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Group Descriptor File for the MGRP

Group

Description

Name Directory Level

MGRP.gdf /base/config 3rd level of
LoopCare

The MGRP group brings up the main LoopCare application processes. The group
includes the following main functions:
• Invokes the LoopCare testing interfaces (TV, TEST).
• Invokes the processes required to interact and send information through
those interfaces.
• Invokes testing and administrative processes for modules such as sam and
triger.
• Invokes training processes through the mtrain module.
• Brings up the M1, M2, MPST, ISDN, and SDV groups.

The MGRP group is the third level group of the LoopCare application. This group
is brought up by the MDMN group on the Front End. Only the 4th level LoopCare
application groups are below the MGRP group. These other groups include:
M1
M2
MPST
ISDN

Standard gdf File This section covers all of the options available to the modules in this group, except
Release for those options associated with special billable features or security options. Not
all the options listed in this section are required to be set up in the gdf file. The
system will be released with a MGRP.gdf file which includes a standard
configuration of modules with appropriate options. It is suggested that the user run
with this standard gdf file and make adjustments only when conditions require.

A-30 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Description of GDF Module I:/base/bin/shrdemon

Information
Module Port(s)
I:/base/bin/shrdemon XX

This instructs shrdemon to free any shared memory descriptors that have been
left following a fatal. This is a preprocessing line required for all group managers.
The port name (XX) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Module I:/usr/lbin/

Module Port(s)
I:/usr/lbin/ IPDEMON

This module prints information about the interprocess message queues within the
kernel address space.

The module is a BASE module that runs in the LoopCare application (Standard
UNIX only). For the most recent information about the options for , refer to the
document 451. in the BASE user document.

Module I:/bin/sh

Module Port(s)
I:/bin/sh mlti

This shell invokes some LoopCare initialization processes required to run before
the group is started. These include setsam which sets up the administrative
regions and mdfdb which sets up the MGRP

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-31

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

and MDF trunk groups.

Option Description
$MLT_UTL/mltinit This is the pathname to the mltinit shell.

Module I:/bin/sh $MLT_UTL/LCJFinit.sh

Module Port(s)
I:/bin/sh $MLT_UTL/ xxi
LCJFinit.sh

Starts the Java application (LCJF) requried for the APMAC, Test By TN, and
SOAP API features.

Option Description
-t,n Sets tracing level, where n = 1, 2 or 3.

Module I:/mlt/adsl./bin/start_wrapper dummy Wrapper

Module Port(s)
I:/mlt/adsl/bin/ wrapper
start_wrapper

This module starts the Wrapper process which also includes cleaning up
Wrapper-related files.

A-32 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/guiProxy

Module Port(s)
F:$MLT_BIN/ gproxy
guiProxy

The guiProxy module is required when the End User GUI is used.

Option Description
-t, n Sets tracing level, (n=0, 1, 2 or 3)

Module $MLT_BIN/tl1l

Module Port(s)
$MLT_BIN/tl1l tl1l

The tl1l module is used to provide the communication protocol to the AnyMedia
and all other access devices that have a TL1 interface..

Option Description
-a Maximum access time to an LTE (for example, AnyMedia, ASAM,
Litespan) in seconds.
-c Timeout in seconds for TL1 command response.
Default: 60 seconds.
-k The interval in seconds for sending the TL1 keep-alive command,
REPT-STAT.
Default: 60 seconds.
-m Sets the maximum number of RT connections.
This value must be greater than 0.
Default: 250.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-33

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Option Description
-q<number Sets the size of the message queue to 512 times the number of
of messages specified.
messages>
Without this option, the queue size is 10240 bytes.
-s Timeout in seconds for how long tl1l should wait for getting a socket
connection.
Default: 45 seconds.
-t, n Sets tracing level, (n=0, 1, 2 or 3)

Module F:$MLT_BIN/tv

Module Port(s)
F:$MLT_BIN/tv tvin, tvout, tvint,
tvtake

The tv module processes requests from the TV mask.

Option Description
-s,n Allows n terminal buffers to be in shared memory. The
default value for n is 40. This is the number of shared
memory buffers allowed.
- t,n Allows n terminals to use tv simultaneously. The default
value for n is 400. This value defines the number of
terminals allowed for this Front End.
-m,20 Increases the tv message queue for the CMU feature
thereby preventing SYSTEM BUSY messages coming
from TV. See installation instructions for LoopCare
G5i4.0.

A-34 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Option Description
-L This option determines the behavior of the LRN override
field,
With this option, when an LRN override is specified for a
TN, the test runs with the LRN override. For the next
next test, if the TN is the same, the LRN override
remains in effect for that test. If the TN changes, the
LRN override is cleared and is not in effect for that test.
Without this option, the LRN override is in effect
whether the TN changes or not and stays in effect until
it is manually cleared.
-N# This option overrides the default 60-minute timeout for
the TV Mask.
Valid range: 60 to 3600 seconds.
-trace,n Sets tracing level, {n = 1,2 or 3}.
& Forces test buffer tracing (Used for developer
debugging only).

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-35

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module R:$MLT_BIN/sam

Module Port(s)
R:$MLT_BIN/sam sam

The sam module processes requests from the SAM mask.

Option Description
-d Disables the CS -D# capability on the SAM Mask.
-E Enables the auto detection of the default option for a
SAM transaction entered without an option.
DS for example will search the nxx tables looking for
which testhead serves it. If it is an EMU, then an -E will
be applied. If it is anLTS/DCTU, then the -L will be
applied.
This only works when no options are entered and will
only switch between an -L and an -E.
If an overlay case is encountered then the following
error message is displayed.

NPANXX OVERLAYED OPTION REQUIRED

dummy Default null entry.

Module R9:$MLT_BIN/r2m

Module Port(s)
R9:$MLT_BIN/r2m r2m

The r2m module enables the DMU Load Management, DigiTest HUB, and UDLC
Overlay LTS/EMU on DCTU features.

Option Description
-t,n This option turns on tracing for the module at a
specified level. Where n is the level having values of 1,
2, or 3. The default level depends on how the group was
started.

A-36 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/test

Module Port(s)
F:$MLT_BIN/test tstin

Processes the TEST mask from the user CRT.

Option Description
-N This option will print all test results in the standard
format for the testing masks. This is the default option
for this module.
-P THIS OPTION IS ONLY VALID IN A NON-
FLOWTHROUGH LMOS ENVIRONMENT. IF
INVOKED IN A FLOWTHROUGH ENVIRONMENT IT
COULD CAUSE PROBLEMS. The -P option causes the
test process to post initial and all subsequent test
results to LMOS. An LMOS FLOWTHROUGH
environment requires only the initial LoopCare results to
be posted.
-trace,n Sets tracing level, (n = 1,2 or 3).

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-37

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module R:$MLT_BIN/snmprw

Module Port(s)
R:$MLT_BIN/snmprw snmprw

The snmprw module is the UNIX process which controls the testing activities of
the CLT.

Option Description
-B When activated this option may provide improvement in
the returned Bridged Tap results when testing with a
CLT.
When testing with a DigiTest Edge, this option validates
the loop length returned by the ATTEN test.
The -B option must be set for the
CLT_BTAP_PERCENT variable to be used. See
MGRP.env in Appendix B.
-E When activated, this option allows LoopCare to
recognize the DC Signatures of Efficient Networks
SDSL modems, where the T-R DC Resistance is
between 100KOhms and 142KOhms.
-t,n Sets tracing level, (n = 1,2 or 3).
-V Option for CLT testing on AnyMedia. If -V is set, then
Voice Detection is performed.
-b Disables Bridged Tap testing as part of the LOOP and
FULL requests for CLTs.

A-38 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/tafman

Module Port(s)
F:$MLT_BIN/tafman tafman

This module processes test results returned from the Front End and displays them
in user readable form to the TEST or TV mask.

Option Description
-a This option enables subsequent transactions to be
logged into the TAF.STAT Log: page 4-16.
-A This option enables the creation of the
OPENSLOG.STAT file in the /mlt/reports folder. See
Chapter 4.
-I This option turns on insertion loss logging.
-L This option turns on Loop Length Logging via the /mlt/
reports/LLEN.STAT file. Without the -L option, no data
is logged in the LLEN.STAT file.
-M This option turns on LRE logging

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-39

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/testout

Module Port(s)
F:$MLT_BIN/testout tstout

This module translates the test information into a user readable display for test
results returned from the LTF controller.

Option Description
-N This option will print all test results in the standard
format for the testing masks. This is the default option
for this module.
-P THIS OPTION IS ONLY VALID IN A NON-
FLOWTHROUGH LMOS ENVIRONMENT. IF
INVOKED IN A FLOWTHROUGH ENVIRONMENT IT
COULD CAUSE PROBLEMS. The -P option causes the
test process to post initial and all subsequent test
results to LMOS. An LMOS FLOWTHROUGH
environment requires only the initial LoopCare results to
be posted.
-trace,n Sets tracing level, (n = 1,2 or 3).

Module F:$MLT_BIN/tip

Module Port(s)
F:$MLT_BIN/tip tip

The tip module is the test interface process. It retrieves the appropriate line record
and application information file data to fill in the test buffer received from the
testing module.

Option Description
-d Indicates that the Front End has code that permits held
accesses across DCNs.
-n Indicates that tip will find and search the file NPANNX
data in $MLT_TBL. For any NPANNX in this file tip will
not attempt to retrieve a line record. Instead it will
proceed to test with the information in the Default
Exchange Key Data base.

A-40 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Option Description
-o Enables the Measurement of OE Response Time
feature.
-P This option directs the tip to test without line records in
the event that the tip queue is full. This option helps to
avoid a system error (VER E0) under a heavy load.
Testing with line records automatically resumes when
free entries become available in the tip internal queue.
-trace,n This option turns on tracing for the module at a
specified level. Where n is the level having values of 1,
2, or 3. The default level depends on how the group was
started.
-u,n This option determines how long the tip will wait for a
line record from NWLOOK before timing out, where n =
number of seconds and is greater than or equal to 2.
(Default = 10 seconds.)
-x,Y This option directs the tip to resync when it determines
that there is a communication problem. Y is the number
of seconds it allows to elapse without receiving any
messages.
-w,n This option determines how often tip is to be awakened
to check time outs, where n = number of seconds per
interval and is greater than or equal to 2. (Default = 3
seconds.)
-f,3 This option allows an override of LoopCare/ISDN
Feature Package 3, to allow LoopCare testing to
continue when there is a problem caused by the
ISDN.gdf file or any modules associated with LoopCare/
ISDN testing. Thus when the -f,3 option is added to the
tip line, POTS tests that may have been affected by
LoopCare/ISDN FP3 problems will proceed normally.
Note that ISDN lines can not be tested until the -f,3
option is removed. Addition or deletion of the -f,3 option
will not take effect until MGRP is bounced.
dummy Default null entry.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-41

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/mltout

Module Port(s)
F:$MLT_BIN/mltout tipmltout

This module processes test results returned from the Front End and displays them
in user readable form to the TEST or TV mask.

Option Description
-D See The -D Option: page A-44
-d This option enables the DISP request to display multiple
pre-qualification test results plus additional fields, such
as a time stamp.
-c This option is used if the Craft Access System (CAS) is
not currently on the system. It bypasses some of the
software needed for CAS.
-h This option turns off the programmable DC signature
feature for all transactions originating on the Front End.
It is useful for BOCs who wish to have the DC signature
feature turned on for LoopCare only. In other words, this
option turns off the Programmable DC signatures for all
transactions via LMOS (e.g., TE/TR, MSCHD,
RETEST, PST, PREDICTOR, MSCR, DISP). The
programmable DC signature data base is located on the
Master machine.
dummy Default null entry.
-N For environments where BMDB is activated, the -N
option avoids problems related to network delays. This
option should be used if you have BMDB on all
LoopCare servers, with the exception that in a
replicated environment, only the Master Definition site
should have this option and all Master sites should not.

A-42 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Option Description
-o This option turns off programmable DC signatures
completely. This means that you cannot enable the
feature from SAM via the DVER request. All that is
allowed to function with DC signatures are display and
change of text via the SAM DVER and CVER
transactions. This feature is useful for companies who
are preparing the text for their DC signatures, but are
not ready to run with it. In Front End environments all
updates to the DC signatures will be reflected on the
LMOS-Front End. The LMOS generic must be
compatible with the programmable DC signature
feature.
-q, # where # is between 1 and 100,000. This option controls
after how many tests mltout queries the BMDB for the
latest options. This is useful in environments that run
smaller numbers of tests.
Default = 10,000
-s This option turns off the Programmable DC Page 6
signature feature for Predictor test requests.
-F This option determines the frequency at which mltout
checks for TDIL/StarMAX timeouts. The default is 3
seconds.
-N Turns off monitoring for network delay.
-T This option sets the timeout value for the TDIL/StarMAX
requests. The default is 15 seconds.
-P This option suppresses the display of the DC Signature
ID Number on GUI test results.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-43

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Option Description
-R This option restricts the TDIL/StarMAX request to
TRAINing only.
-trace,3 turns on tracing.
-z This option turns off the display of the Additional Circuit
Information as part of the Result output for tests run
using the Circuit ID. This Circuit ID was previously
associated with a specific LTE Circuit access
information.
Example
On the GUI, a METX is run for Circuit ID: 8887771234,
besides the METX result, the following is displayed in
the Result output

Additional Circuit Information

CIRCUIT ID 8887771234
LTE ID bwdau1
Shelf C
Slot 00
Line 00

The -D Option

mltout option -D turns on the dcsig shuffle of the ordering of the dcsigs messages.

Normally the dcsig messages come out in two colums on the TV mask. In some
environments, the records are combined to make longer messages.

Example:

rec 1 rec 4
The cat in the hat ate a fat rat
-----
rec 2 rec 5
All men are created painfully
----- -----
rec 3 rec 6

A-44 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

The world is alive with the sound of music

----- -----
On the GUI display, however, the summary messages are displayed in a
single column: 1 2 3 4 5 6.
Example:
"The cat in the
All men are
The world is alive
hat ate a fat rat
created painfully
with the sound of music".
The -D option causes the messages to be displayed correctly on the GUI
page.

Module F:$MLT_BIN/mtrain

Module Port(s)
F:$MLT_BIN/mtrain mtrain

The mtrain module is used to run the LoopCare online training program that works
through the regular user interfaces using stored test results to simulate actual
trouble scenarios.

Option Description
dummy Default null entry.
-trace This option allows the user to set the tracing level
associated with the mtrain module. The correct format is
"-trace,#" (where # can be 0, 1, 2 or 3). By default, the
tracing level of mtrain is set to the value of the
MLTTRACE environmental variable.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-45

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/triger

Module Port(s)
F:$MLT_BIN/triger triger

The module that LoopCare uses to run scheduled SAM maintenance activities
through the DTIME and CTIME transactions.

Option Description
-b Breaks down the SAN request based on the types of
test heads in the region:
• Automatically run SAN -RE if there are EMU's in
the region.
• Automatically run SAN -RS if there are RMU's in
the region.
• Always run a SAN -RL after SAN-RE and SAN-
RS.
dummy This option is entered when all other options do not
apply.
-trace,n Sets tracing level, (n = 1, 2 or 3).

Module F:$MLT_BIN/DataAPISrvr

Module Port(s)
F:$MLT_BIN/ das
DataAPISrv

This module provides MLT's interface to the data services provided by

LCJF.

It is required for the APMAC and Test By TN features.

A-46 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/lcsp

Module Port(s)
F:$MLT_BIN/lcsp lcspin, lcspot

This module is required for the SOAP API

Option Description
dummy Default null option.
-t,n Sets tracing level, where n = 1, 2 or 3.

Module F:$MLT_BIN/LCJFProxy

Module Port(s)
F:$MLT_BIN/ lcjf
LCJFProxy

Option Description
dummy Default null option.
-t,n Sets tracing level, where n = 1, 2 or 3.

Module F:$MLT_BIN/tv

Module Port(s)
F:$MLT_BIN/tv tvin, tvout, tvint,
tvtake

The tv module processes requests from the TV mask.

Option Description
-trace,n Sets tracing level, {n = 1,2 or 3}.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-47

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

A-48 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/m2samo

Module Port(s)
F:$MLT_BIN/ m2samo
m2samo

This module produces output reports for administrative requests.

Option Description
-c With this option, the output of the DS -E request
contains the same details as the DS -D# request and
the CS -E command is blocked.
Without this option, the output is in LTS style and the
CS -E request is not blocked. In this case, the output
indicates the connection status of the device when DS
was run.
-F This option allows the user to specify which NPA/NNX
will be used to identify a test frame, in reports, by
changing the NPANNX field on the SAM mask. With the
-F present, m2samo will use the data from the first nnx
entry in the LTS data base. The NPANNX field for the
SAM header will be derived from the first three digits of
the lrexk field combined with the nnx entry. Without the -
F option, the NPA is derived from the mltacc.src file.
Although the -F option may be set independently in this
module, it is strongly recommended that, if it is set in
m2samo, it also be set in the tcx module. Having it set in
both modules will ensure that the output from SAM
region reports is displayed consistently and that users
will be better able to read and interpret those reports
accurately.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-49

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Option Description
-K This option allows the user to specify which EXK will be
used to identify a test frame, in reports, by changing the
EXK field on the SAM mask. With the -K present,
m2samo will derive the EXK entry from the full lrexk
field entry in the LTS data base. Although the -K option
may be set independently in this module, it is strongly
recommended that, if it is set in m2samo, it also be set
in the tcx module. Having it set in both modules will
ensure that the output from SAM region reports is
displayed consistently and that users will be better able
to read and interpret those reports accurately.
dummy Default null entry.
-trace,n Sets tracing level, (n = 1,2 or 3).

Module F:$MLT_BIN/m2sync

Module Port(s)
F:$MLT_BIN/m2sync m2sync

This module's function is to synchronize region files (all MLTREG* files in /mlt/
mlttables/region/comp) and/or LTS FS database files (not LTS.d files) among the
LoopCare machines in a network. When either a region or LTS database file is
changed and loaded on the master Front End, updates are automatically sent by
m2sync on that machine to all other Front Ends in the network. On the receiving
machine(s), the updated files are automatically loaded. If MGRP is not running on
the receiving machine when updated files are received, the files are loaded when
MGRP comes up again.

Region file updates go to all Front Ends. LTS FS database file updates can be
specified to all Front Ends or just the secondary machine, as listed in $MLT_ICT/
mltadm.src. The "-a" option on the m2sync GDF command line instructs m2sync
to update only the secondary machine for LTS FS DB synchronizations.

The following requests trigger m2sync to update LTS FS data base files to
specified machine(s):

LTS:
*DS changes in equipment status (PMUs, trunks)
*CS (same as above)

A-50 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

*DLOAD (same as above)

PTUC only when db updated for PMU status change
TC all trunk calibrations update the LTS DB
* LTS DB updates only occur under certain circumstances for these transactions.
5ESS:
ES changes in equipment status
DS (same as above) The following requests trigger m2sync
to update Region files to all LoopCare machines:
CT make Equip/Trunk threshold changes
CTIME change the time of AUTO transactions (reset trouble
counters, run DCN, LTS sanity, run trunk calibrations).

LtsStat is a program that is called by LTS diagnostics to update the status of an

LTS to show that diagnostics are running. LtsStat also triggers region file
synchronization across machines. Finally, when a LoopCare machine receives a
request to become the administrative backup for another, it clears the adm status
of all LTSs in each region served by the old primary machine and then
synchronizes regions with all other machines.

Option Description
-t This option turns on tracing for the module at a specified
level. Permissible level range = 1-3.
-a This option restricts the sending of LTS database
updates to the backup LoopCare machine only. If this
option is not invoked, LTS database updates will be
sent to all LoopCare machines in the network. When
invoked, this option has no restrictive effect on region
synchronizations which go to all Front Ends in the
network.
-w,n This option will "wake up" every (n) seconds and
attempt to synchronize information to previously
downed LoopCare machines. Default = 30 seconds.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-51

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/m2adm

Module Port(s)
F:$MLT_BIN/m2adm m2adm, m2admo

This module processes administrative transactions that require interaction with an

LTS.

Option Description
dummy Default null option.
-& Forces test buffer tracing (used for developer
debugging only).
-g This option enables the enhanced channel isolation
tests for ground start lines served by a SLC system.
This option applies to all lines.
-z1,n This option provides "n" number of concurrent
transactions that can be processed. The maximum
allowed for is 600. The default value is 50. This option is
typically used to throttle LoopCare Administrative
transactions. NOTE: For -R (region) transactions,
processing will begin only when at least one of the LTSs
designated in the region can be queued in the buffer.
-z2,n This option provides "n" number of concurrent
transactions that can be processed for any ADMIN
request, capturing any overflow on the first threshold (-
z1). In short it assures that an ADMIN transaction run
without a -R option can run while an ADMIN transaction
with a -R transaction is running.

When designating values for z1 and z2, it is important to

take into consideration several factors, such as the
number of applications running on the machine, the
number of LTSs per region, and the time of day
processes will run. For example, a Standalone running
processes at night could more readily accommodate the
maximum value of 600 than a machine with several
different applications running processes at peak hours.

NOTE:
THE VALUE FOR n in -z1 MUST BE THE SAME
AS THE VALUE FOR n in -z2.
trace,n Sets tracing level, (n = 1,2 or 3).

A-52 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-53

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/tcx

Module Port(s)
F:$MLT_BIN/tcx tcx, tcxi, tcxo

This module processes Trunk Calibration results for LTSs and CMUs. The Trunk
Calibration Retest feature allows for specific LTS trunk calibration failure reports to
be automatically retested under certain conditions.

Option Description
-B This option causes the tcx module to use a modified
SAM mask header for the TVMON transaction. This
header adds the mltorg DKAP identifier and deletes
cable and pair information. If the -B option is not used,
the standard header will appear.
-F This option allows the user to specify which NPA/NNX
will be used to identify a test frame, in reports, by
changing the NPANNX field on the SAM mask. With the
-F present, tcx will use the data from the first nnx entry
in the LTS data base. The NPANNX field for the SAM
header will be derived from the first three digits of the
lrexk field combined with the nnx entry. Without the -F
option, the NPA is derived from the mltacc.src file.

Although the -F option may be set independently in this

module, it is strongly recommended that, if it is set in
tcx, it also be set in the m2samo module. Having it set
in both modules will ensure that the output from SAM
region reports is displayed consistently and that users
will be better able to read and interpret those reports
accurately.
-K This option allows the user to specify which EXK will be
used to identify a test frame, in reports, by changing the
EXK field on the SAM mask. With the -K present, tcx will
derive the EXK entry from the full lrexk field entry in the
LTS data base.

Although the -K option may be set independently in this

module, it is strongly recommended that, if it is set in
tcx, it also be set in the m2samo module. Having it set
in both modules will ensure that the output from SAM
region reports is displayed consistently and that users
will be better able to read and interpret those reports
accurately.

A-54 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Option Description
-R This option turns TCAL RETEST feature OFF. Feature
is ON by default and invokes and logs retests to
TCX.MON files.
-z,n This option provides "n" number of concurrent
transactions that can be processed for any SAM
request run with a -R (region) option. In short, it assures
that a SAM transaction run without a -R option can run
while a SAM transaction with a -R option is running. The
maximum "n" allowed for tcx is 50; the default value is
10. This option is typically used to throttle LoopCare
transactions.

GUIDELINES FOR SETTING tcx -z:

The tcx -z option directly affects how many SAM

transactions can be processed at once and, therefore,
the speed at which tasks such as Region requests are
completed. One of the most time-consuming Region
requests is trunk calibration so the tcx -z setting will
have significant impact on that operation. When
assigning values for -z it is important to consider the
following factors:
1. The total number of TC transactions being sent
down at maximum load times - For each TC -R,
LoopCare can send down one TC request per
LTS in each region. The -z option will determine
how many simultaneous requests are actually
sent. The lower the number, the fewer
simultaneous requests will be sent, thus it will
take longer to complete a TC -R request.
However, by slowing the rate, the chance of a
bottleneck will be less, resulting in fewer TC
timeouts.
2. Total Number of DCN Port connections on the
HP -The more DCN connections there are, the
more paths are available through the hardware
and the less likely it will be for bottlenecks to
occur. The more DCN connections there are, the
higher the value of -z can be which will result in
faster request processing.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-55

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Option Description
-z,n 3. Proper Design of Hardware Configuration - The
physical layout of the connections from DCN to
(continued)
LTS can impact the effectiveness of transactions
running through the system. The goal is to avoid
configurations which direct large numbers of
transactions through a limited number of
devices. With a good, balanced design, the value
of -z can be set higher; with a limiting
configuration, -z must be set relatively low. The
document sys.dcnlinks provides guidelines for
setting up DCN communications connections, as
well as DCN to LTS connections.
dummy Default null entry.
-t,n Sets tracing level, {n = 1,2 or 3}.

Module F:$MLT_BIN/m2r

Module Port(s)
F:$MLT_BIN/m2r m2r, m2ro

This module interfaces between the TV mask and the Test Equipment (LTS,
DCTU, CMU, RMU), and creates the test buffer for a LoopCare test request.

Option Description
-trace,n Sets tracing level, {n = 1,2 or 3}.
dummy Default null entry.
-a This option allows processing of test requests when
Sanity or Diagnostics is running.
-c This option refers to a Callback Security feature. Refer
to the Facility Manager's Guide to Using the Callback
and Logging Feature for more information.
-p,e This option forces test buffer tracing for all telephone
numbers in a specific exchange key, where e = a
specified six-digit EXK. Exchange key number entries
that are not 6 digits will be ignored and an error
message will be printed in m2r.err.

A-56 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Option Description
-w Allows overriding of default wideband testing
parameters as defined in the /mlt/adsl/WBdata control
file.
-z,n This option provides "n" number of simultaneous
transactions that can be processed. The valid range
allowed for m2r is 10-1000. The default value is 150.
This option is used to throttle LoopCare transactions.
The value "n" should be set according to load; if n is set
at the low end of the range many "BUSY" messages
may be returned, if n is set at the high end of the range
there is a danger of outage due to using up all shared
memory descriptors (total 1000 available for ALL
applications on the HP).
-L Used for callback transactions. If a 10 digit callback is
entered in the CB field of the TV mask and a match is
not found in the cbprefix tables, default to 1+ (i.e. 10
digit) callbacks. Without this option the NPA is stripped
from the callback TN and the remaining 7 digits are
used.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-57

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Option Description
-M • The -M option in the m2r module of the
MGRP.gdf is functional only if one or both of the
-m options in the tser and tserc modules are ON.
The -M option enables the Enhanced MTU
Detect function to run under any of the following
conditions:
— There is no line record
— There is a POTS, KEY, UNCATALOGED
or CENTREX line record
— There is a T1, T8, T34, or T62 override on
the user interface
If the -M option is not ON in the m2r module of
the MGRP.gdf, the Enhanced MTU Detect
function runs under any of the following
conditions:
— There is no line record
— There is a POTS line record
— There is a T1 override on the user
override

In the event that you have an overlay and wish to run

Enhanced MTU Detect, set the EMU to be the primary
testhead.
-N Includes the -L option above and in addition searches
the cbprefix tables for a dialout digit (such as 9). If a
dialout digit is found, 11 digits are dialed (i.e.
91+NPA+NNX+NNNN). If a dialout digit is not found, 10
digits are dialed. See "aifdes.cbprefix" for more
information.
-T,n This option defines the number of tsers to be brought
up, where n = number of tsers. This module must match
the -T option for tser. Currently, only one tser, T,1 is
designated; T,n for multiple tsers is an option provided
for future growth. (See the description for the -T,n
option following for $MLT_BIN/tser).
-& This option forces test buffer tracing (used for developer
debugging only).

A-58 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/tser

Module Port(s)
F:$MLT_BIN/tser tser1 - tser5

This module supervises LoopCare tests. It is the testing algorithm.

Option Description
-& Forces test buffer tracing (used for developer debugging only).
-A This option is used to turn on the ADSL Transmission Unit-Central
(ATU-C) signature detection retest feature. See ATU-C Signature
Detection Retest Variables: page B-18.
-C To suppress Remote Terminal (RT) Calibration error messages
from non calibrated RTs, when the digital loop carrier lines (DLC)
Loop Calibration feature (feature 110) is active.
-g This module enables the enhanced channel isolation tests for
ground start lines served by a SLC system.
-m This option enables the MTU Detect feature for LTS/DCTU
testheads.

NOTE:
Options for enabling MTU algorithms also exist in the m2r
module of MGRP.gdf and the tserc module of M2.gdf (-m
option). It is strongly recommended that the three options be
set the same, either all three ON or all three OFF.
-h This option allows the LOOP and LIN test to bypass hazardous
potential protection and report the hazardous voltages detected.
-o The option turns off the hazardous potential detection circuit for
TONE, TONE+, TONECA, and TONEIN requests.
-f This option turns on Fast FULL. Fast FULL will reduce the
response time on a FULL request.
-T,n This option should match the -T option specified for the m2r
module. That is, the tser module should be invoked "n" times,
where "n" is the value of the -T option of the m2r module. The
value of "n" should be changed for each occurrence of the tser
module, starting from 1, up to "n" times, with a maximum value of
"n" = 5. Currently, only one tser, T,1, is designated; T,n for multiple
tsers is an option provided for future growth.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-59

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Option Description
-uX Where X = 2-255, if no -u option default value is 3. This option
allows tser to turn on PST Flow Control if the LTS informed tser "X"
times that the PMUs were busy.
-vX Where X = 2-255, if no -v option default value is 15. This option
enables tser to cause an LTS reset if the LTS informed tser "X"
times that the PMUs were busy.
-wX Where X = 2-255, if no -w option default value is 5. This option
enables tser to cause an LTS reset if the LTS detected "X"
consecutive PMU busies upon access of the line under test.
-E If this option IS used, then tser would do a "fork and exec" via the
"pstswitch" utility to send a request to "pstlts" to turn on PST Flow
Control. If this option is NOT used, then tser would send a
message directly to "pstlts" to turn on PST Flow Control.
-r The -r option permits Channel Unit Emulator (CUE) access for
non-locally switched or non-switched Extended Super POTS
(ESPOTS) and 4-wire channel units.
-L This option changes the upper allowable limit for the LCKT TR
resistance from the default value of 1500 ohms to the new value of
500 ohms.

Example

If m2r has "-T,4" option, the tser module should be invoked 4 times as follows:

Module F:$MLT_BIN/m3r

Module Port(s)
F:$MLT_BIN/m3r m3r

Option Description
-trace,n Sets tracing level, {n = 1,2 or 3}.

A-60 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/ltsear

Module Port(s)
F:$MLT_BIN/ltsear ltsear

This module processes spontaneous outputs from the LTS or DCTU.

Option Description
-& Forces test buffer tracing (used for developer
debugging only). Does not apply to tser modules.
-T,n This option sets automatic report generation interval to
n minutes. The default value is 60 minutes. Acceptable
ranges are from 1-120. Any value not in the range 1-120
is set to 60 minutes.
-g This module enables the enhanced channel isolation
tests for ground start lines served by a SLC system.
This option applies to all lines.
-trace,n Sets tracing level, (n = 1,2 or 3).

Module #R9:$MLT_BIN/admgw

Module Port(s)
F:$MLT_BIN/admgw admgw

This module is the gateway for the SAM GUI.

Option Description
-trace,n Sets the tracing level, where n = 1, 2, or 3.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-61

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module F:$MLT_BIN/admrsp

Module Port(s)
F:$MLT_BIN/admrsp admrsp

This module processes administrative responses returning from the LTS or

DCTU.

Option Description
-& Forces test buffer tracing (used for developer
debugging). Does not apply to tser modules.
-z,n This option provides "n" number of concurrent multi-
message SAM transactions (i.e., DS, DLOAD, Trouble
Count resets) that can be processed. The minimum
allowed is 20, the maximum allowed is100. The default
value is 100. This number should not be smaller than
the -z1 option on the m2adm line.

Module F:$MLT_BIN/adm5e

Module Port(s)
F:$MLT_BIN/adm5e adm5e, adm5eo

This module processes administrative requests and responses to the DCTU.

Option Description
dummy Default null option.
-& Forces test buffer tracing (used for developer
debugging). Does not apply to tser modules.

A-62 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Option Description
-z1,n This option provides "n" number of concurrent
transactions that can be processed. The maximum
allowed for is 600. The default value is 50. This option is
typically used to throttle LoopCare administrative
transactions. NOTE: For -R (region) transactions,
processing will begin only when at least one of the LTSs
designated in the region can be queued in the buffer.
-z2,n This option provides "n" number of concurrent
transactions that can be processed for any ADMIN
request, capturing any overflow on the first threshold (-
z1). In short, it assures that an ADMIN transaction run
without an -R option can run while an ADMIN
transaction with an -R transaction is running.

When designating values for z1 and z2, it is important to

take into consideration several factors, such as the
number of applications running on the machine, the
number of LTSs per region, and the time of day
processes will run. For example, a Standalone running
processes at night could more readily accommodate the
maximum value of 600 than a machine with several
different applications running processes at peak hours.

NOTE:
THE VALUE FOR n in -z1 MUST BE THE SAME
AS THE VALUE FOR n in -z2.
-trace,n Sets tracing level, (n = 1,2 or 3).

Module R:$MLT_BIN/emuadm

Module Port(s)
R:$MLT_BIN/ emuadm
emuadm

The emuadm module is used to run SAM transactions on DMUs that are
configured as EMUs or RMU-Ss.

Option Description
-t,# Sets tracing level, {# = 1,2 or 3}.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-63

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module d:$MLT_BIN/MSCHD

Module Port(s)
d:$MLT_BIN/MSCHD MSCHD

This module is run to schedule SAM transactions.

Option Description
-log Logs scheduler activities.
-dlog,/tmp Specifies which directory is to be used for the log file (/
temp).
-t,# Sets tracing level, {# = 1,2 or 3}.

Module F:$MLT_BIN/dmic

Module Port(s)
F:$MLT_BIN/dmic dmic

This module enables LoopCare top access DigiTest Edge test platforms to
perform tests.

Option Description
-o,n Optional, but highly recommended.
Set the value of n to maximum number of DigiTest
Edges.
-t,n Sets tracing on. Normally this should not be on.
-u,n The number of local modems.
The required value for this option is 1.

A-64 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module R9:$MLT_BIN/mmlmgr

Module Port(s)
R9:$MLT_BIN/ mmlmgr
mmlmgr

This module communicates with an EWSD switch via a Siemens FOS interface. It
translates a test request from its upper module to sequences of MML commands
and processes its responses..

Option Description
-trace,n This option turns on tracing for the module at a
specified level, where n is the level having values of 1,
2, or 3. The default level is set to the value of the
MLTTRACE environmental variable.
& This option forces buffer tracing to be on for all
transactions.

Module #R9:$MLT_BIN/resmgr

Module Port(s)
#R9:$MLT_BIN/ resmgr
resmgr

This module is responsible for maintaining connections between LoopCare and

the IOP ports on 5ESS switches for the OE Retrieval feature. This function allows
messages to pass back and forth between LoopCare and 5ESS switches. While
holding the connection, it waits for messages from a LoopCare process and writes
the request out to the remote end. Consequently, it also reads responses from the

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-65

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

remote end and sends those responses to the LoopCare process that made the
request.

Option Description
-c Sets the connect timeout in seconds.
-h,n Sets the number of seconds a connection to an RTU
test head is held after the disconnect connection
command was received.

The default is 60 seconds. The default is in effect if no

option is specified.
-l Sets the link timer, which determines how long
LoopCare will wait for a message to be sent to a remote
before timing out and therefore disconnecting the link.
• For direct connections, this timer is set to 30
days and cannot be changed by the user.
• For modem connections, this timer is set to the
default value of 1800 seconds, if not defined by
ñl <time>.
-m Sets the port trouble count threshold.
-q Sets the queue size.
-r Sets the tracing level for ccmgr.
-t Sets the tracing level for resmgr.
-G Sets the GCM flag
-H,n Sets the number of seconds a connection to a Switch is
held for OE retrieval after the disconnect connection
command was received.
The default is 30 days. The default is in effect if no
option is specified.
-T Sets the timeout in seconds when waiting for a modem
to connect. Range: 10 to 300.

A-66 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module #R9:$MLT_BIN/tstmgr

Module Port(s)
#R9:$MLT_BIN/ tstmgr
tstmgr

This module is responsible for processing test requests sent to an RTU.

Option Description
-t Sets the tracing level for tstmgr.
-C Changes the QUAL/COIL/DCOIL test from LDT to
LOOP for the RTU if the LOAD _COIL feature (#114) is
on.
-D Sets the dial/touch tone timeout.
-H Sets the Howler timeout in seconds.
-N Sets digit shifting into NPA.
-R Sets the Ringing timeout in seconds.
-T Sets the Tone timeout in seconds.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-67

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module #R9:$MLT_BIN/hubalarm

Module Port(s)
#R9:$MLT_BIN/ hubal
hubalarm

This module sends HUB alarms to the main printer for each region associated
with the LoopCare server.

Option Description
dummy Default null option.
-t,n Sets the tracing level, where n = 1, 2, or 3.
-s,sec Sets the process wake up interval, where sec = the
number of seconds in the interval.The hubalarm
process checks for HUB alarms whenever it wakes up.
Range: 10 to 3600
Default: 60

Module #R9:$MLT_BIN/listmgr

Module Port(s)
#R9:$MLT_BIN/ listmgr
listmgr

This module is part of the loop detect and batch testing features. It allows you to
enter a start and end test time for a prepared list of telephone numbers (TNs), as
well as a time to begin the staging phase of testing. The staging phase allows you
to get preliminary information from the switch to speed up the loop detect and is
relevant to the one option (-p) you might adjust.

Option Description
-p Regulates the amount of time allowed for the
preliminary information to return to the switch. The
default value is 90 seconds, but you may change this if
your situation requires more or less time to do the INFO
command.

A-68 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module #R9:$MLT_BIN/mmlp

Module Port(s)
#R9:$MLT_BIN/mmlp mmlp

This module parses MML command responses from the 5ESS switch. It is used
by the OE retrieval feature.

Option Description
-t,n Sets the tracing level, where n=1,2, or 3.
-& Turns on detailed tracing.

Module #R9:$MLT_BIN/mmltranx

Module Port(s)
#R9:$MLT_BIN/ mmltranx
mmltranx

This module translates requests from the oemgr module to MML commands for
the 5ESS switch. It is used by the OE retrieval feature.

Option Description
-t,n Sets the tracing level, where n=1,2, or 3.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-69

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module #R9:$MLT_BIN/oemgr

Module Port(s)
#R9:$MLT_BIN/ oemgr
oemgr

This module queries the switch for the Office equipment number associated with a
Directory Number. It is used by the OE retrieval feature.

Option Description
-t,n Sets the tracing level, where n=1,2, or 3.
-d,s Sets the timeout duration where s = seconds.
The default is 50.

Module #R9:$MLT_BIN/tspool

Module Port(s)
#R9:$MLT_BIN/ tspool
tspool

The tspool (transaction spooler) module is used with the loop detection and the
batch testing features. It manages resources and sequencing of tests. You would
not be expected to set any of these values but might set some of them while
troubleshooting under LoopCare support direction.

Option Description
-T Turns on "master" tracing. This traces at the object
level.
-t,n Sets the trace level and turns on normal LoopCare
tracing for this module, where n=1, 2, or 3.

A-70 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Option Description
-s Acts as a fail safe against stranding queued tests. The
default is set to clean up after 3600 seconds. This
value, in seconds, allows you to override the default.
-f Directs tracing to a file, rather than the EMH module.
This should only be used under direction of LoopCare
Support.
-r,n Sets time delay, in seconds (<n>), for sending a
transaction to the same RMU. The default value is 7
seconds.

Module /base/bin/grpmgr

Module Port(s)
/base/bin/grpmgr M1

The grpmgr module is a BASE module that runs in the LoopCare application. For
the most recent information about the options for grpmgr, refer to the document
450.gdf_files in the BASE user document (or 451.gdf_files for those customers
with standard UNIX System 5 or later).

This shell is used to start the M1 group and comes with standard options that must
be run. Should you desire to bring up the M1 group idle you may insert the idle
mode option on the line. Refer to the BASE user document.

Module /base/bin/grpmgr

Module Port(s)
/base/bin/grpmgr M2

The grpmgr module is a BASE module that runs in the LoopCare application. For
the most recent information about the options for grpmgr, refer to the document
450.gdf_files in the BASE user document (or 451.gdf_files for those customers
with standard UNIX System 5 or later).

This shell is used to start the M2 group and comes with standard options that must
be run. Should you desire to bring up the M2 group idle you may insert the idle
mode option on the line. Refer to the BASE user document.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-71

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

Module /base/bin/grpmgr

Module Port(s)
/base/bin/grpmgr MPST

The grpmgr module is a BASE module that runs in the LoopCare application. For
the most recent information about the options for grpmgr, refer to the document
450.gdf_files in the BASE user document (or 451.gdf_files for those customers
with standard UNIX System 5 or later).

This shell is used to start the MPST group and comes with standard options that
must be run. Should you desire to bring up the MPST group idle you may insert
the idle mode option on the line. Refer to the BASE user document.

Module /base/bin/grpmgr

Module Port(s)
/base/bin/grpmgr ISDN

The grpmgr module is a BASE module that runs in the LoopCare application. For
the most recent information about the options for grpmgr, refer to the document
450.gdf_files in the BASE user document (or 451.gdf_files for those customers
with standard UNIX System 5 or later).

This shell is used to start the ISDN group and comes with standard options that
must be run. Should you desire to bring up the ISDN group idle you may insert the
idle mode option on the line. Refer to the BASE user document.

A-72 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

Module E:bin/sh

Module Port(s)
E:bin/sh mlte

This shell performs some cleanup processes when the groups are stopped.

Option Description
$MLT_UTL/mltend This is the path name for the mltend shell.

Module E:/bin.sh $MLT_UTL/LCJFend.sh

Module Port(s)
E:/bin.sh $MLT_UTL/ xxe
LCJFend.sh

Shuts the Java application (LCJF) requried for the APMAC, Test By TN, and
SOAP API features.

Option Description
-t,n Sets tracing level, where n = 1, 2 or 3.

Module E:/base/bin/shrdemon

Module Port(s)
E:/base/bin/shrdemon YY

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-73

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Example of MGRP Below is an example of the MGRP.gdf file.

GDF File
I:/base/bin/shrdemon -S XX

I:/base/bin/ipms -r,-S IPDEMON

I:/bin/sh $MLT_UTL/mltinit mlti

I:/$MLT_BIN/chk_oracle dummy chk_oracle

R:$MLT_BIN/sam -E sam

F:$MLT_BIN/tip -N,-q,90 tip

F:$MLT_BIN/tv -s,40,-t,400 tvin,tvout,tvnit

R9:$MLT_BIN/mltout -a,-A, mltout,mout2,msxo

F:$MLT_BIN/tafman dummy tafman

F:$MLT_BIN/mtrain -d,30 mtrain

F:$MLT_BIN/triger dummy triger

F:$MLT_BIN/triger2 -t,3 trig2

F:$MLT_BIN/m2samo dummy m2samo

F:$MLT_BIN/m2adm -k m2adm,m2admo

F:$MLT_BIN/admgw dummy admgw

R9:$MLT_BIN/emuadm dummy emuadm

F:$MLT_BIN/adm5e -v,-k adm5e,adm5eo

F:$MLT_BIN/tcx -B tcx,tcxi,tcxo

F:$MLT_BIN/m2r -k,-T,1,-M m2r,m2ro

F:$MLT_BIN/tser -o,-k,-g,-m,-T,1,-A,-trace,3 tser1

A-74 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MGRP Group

F:$MLT_BIN/ltsear -k ltsear

F:$MLT_BIN/admrsp -k admrsp

F:$MLT_BIN/m3r dummy m3r

F:$MLT_BIN/guiProxy -t,3 gproxy

d:$MLT_BIN/MSCHD -log,-dlog,/tmp,-d,$MLT_TBL/scheduler MSCHD

R9:$MLT_BIN/resmgr -G,-h,30,-l,1800,-c,60,-m,10 SLMGR

F:$MLT_BIN/dmic -o,250,-u,1 dmic

R9:$MLT_BIN/tstmgr -T,3600,-H,3600 tstmgr

R9:$MLT_BIN/mmltranx -p,SLMGR,-d,25 MMLT

R9:$MLT_BIN/mmlp dummy MMLP

R9:$MLT_BIN/oemgr dummy oemgr

F:$MLT_BIN/tspool dummy tspool

F:$MLT_BIN/tl1l -q,50 tl1l

R9:$MLT_BIN/listmgr dummy listp,listr

R9:$MLT_BIN/snmprw -E,-t,3 snmprw

/base/bin/grpmgr -r,1,-e,M2.env,-f,M2.gdf M2

/base/bin/grpmgr -r,1,-e,MPST.env,-f,MPST.gdf MPST

/base/bin/grpmgr -r,1,-e,CGRP.env,-f,CGRP.gdf CGRP

E:/bin/sh $MLT_UTL/mltend mlte

E:/base/bin/shrdemon -S YY

E:$MLT_BIN/killproc -f,MGRP.gdf killproc

E:$MLT_BIN/killproc -f,MPST.gdf killproc1

E:$MLT_BIN/killproc -f,CGRP.gdf killproc 2

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-75

System Administration Guide Group Descriptor Files
Group Descriptor File for the MGRP Group

TDIL Modifications If you are running TDIL, add the following 2 lines to the file /base/config/
MGRP.gdf:

R2:$MLT_BIN/gwbase -f,$MLT_TMP/datafifo gwbase

R2:$MLT_BIN/ -A,gwsouth,-f,$MLT_TMP/datainfo gws
gwsouth

NOTE:
Fields above are separated by 1 or more TABs. The above lines MUST be
added after the following entries (i.e., be the 4th and 5th executable lines in
the file):

I:/base/bin/shrdemon -S XX
I:/base/bin/ -r,-S IPDEMON
I:/base/bin/sh $MLT_UTL/mltinit mlti

A-76 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the M2 Group

Group Descriptor File for the M2 Group

Description

Name Directory Level

M2.gdf /base/config 4th level of
LoopCare

The M2 group brings up the processes required to test through the RMU, CMU
and EMU test equipment. This group includes the following main functions:
• Invokes the mcr module which direct test requests to the CMU or EMU.
• Invokes the mrr module which direct test requests to the RMU.
• Invokes the tserc module which includes the testing algorithms for CMUs,
EMUs and RMUs.

The M2 group is one of the fourth level groups in the LoopCare application. This
group is brought up by the MGRP group on the Front End. No other LoopCare
application groups are below the M2 group. Three other groups are at the same
level. They are:
M1
MPST
ISDN

NOTE:
If the M2 group goes down, CMU access is dropped and can't be recovered
with a warm start.

Standard gdf File This section describes the options available to the modules in this group, except
Release for some options associated with special billable features or security options. Not
all the options listed in this section are required to be set up in the gdf file. The
system will be released with a m2.gdf file which includes a standard configuration
of modules with appropriate options. It is suggested that the user run with this
standard gdf file and make adjustments only when conditions require.

Description of GDF The following modules all contain a common "dummy" option which is a default
Information null option.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-77

System Administration Guide Group Descriptor Files
Group Descriptor File for the M2 Group

Module F:$MLT_BIN/mar

Module Port(s)
F:$MLT_BIN/mar mar

This module manages transactions that test with the 5ESS SLIM. Management
functions include allocating memory, choosing the appropriate test algorithm,
initiating test access messages through ccmgr, setting time limits, and
determining verification codes.

Option Description
l,n This options overrides the transaction time limit to n
seconds.
-trace,n This option turns on tracing for the module at a
specified level, where n is the level having values of 1,
2, or 3. The default level is set to the value of the
MLTTRACE environmental variable.
z,n This option sets to n the maximum number of
simultaneous transactions that can be managed.
& This option forces buffer tracing to be on for all
transactions.

Module F:$MLT_BIN/mcr

Module Port(s)
F:$MLT_BIN/mcr mcr, mcro

The mcr module is used to create the buffers for testing CMUs and EMUs. The
module is the interface between the test and tv modules and the test equipment.
The options -h, -i, -u are for EMU connection management. See the
LoopCare Complete Guide to the Expert Measurement Unit (EMU) section
on EMU Connection Management

A-78 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the M2 Group

Option Description
-& Turns on buffer tracing (used for developer debugging only).
-trace,n Sets tracing level, {n=1,2 or 3}.
-A When this option is set and the TROUBLE RATE OVERFLOW
message appears, LoopCare takes the DMU OA.
When this option is not set and the TROUBLE RATE OVERFLOW
message appears, , LoopCare does not take the DMU OA.
-D When this option is set, LoopCare ignores DMU internal diagnostic
failures in the test request log and leaves the DMU available.
-L Used for callback transactions. If a 10 digit callback is entered in the
CB field of the TV mask and a match is not found in the cbprefix
tables, default to 1+ (i.e. 10 digit) callbacks. Without this option the
NPA is stripped from the callback TN and the remaining 7 digits are
used. See "aifdes.cbprefix" for more information
-N Includes the -L option above and in addition searches the cbprefix
tables for a dialout digit (such as 9). If a dialout digit is found, 11
digits are dialed (i.e. 91+NPA+NNX+NNNN). If a dialout digit is not
found, 10 digits are dialed. See "aifdes.cbprefix" for more
information.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-79

System Administration Guide Group Descriptor Files
Group Descriptor File for the M2 Group

Option Description
-h Enables the history byte functionality for a DMU-C (EMU). With this
option, a trouble count of failed accesses is kept. If the indicated
consecutive failures occur, the DMU-C is taken Auto OOS. DS/CS
in the SAM mask are used to put the DMU-C back in service (see
the Operations, Administration and Maintenance (OA&M) Guide). If
DMU-C access is obtained before this count reaches the indicated
number, the counter is reset to 0.

Failed accesses do not apply to network problems, such as

cannot communication with Access Server. This option
applies only to problems encountered in the handshaking with
the EMU.
Valid Range: 1 to 50
Default: 8
-i Enables the percent failures threshold functionality for a DMU-C. A
failure percentage greater than the set threshold will take the DMU-
C Auto OOS. DS/CS in the SAM mask are used to put the DMU-C
back in service (see the Operations, Administration and
Maintenance (OA&M) Guide).

Failed accesses do not apply to network problems, such as

cannot communication with Access Server. This option
applies only to problems encountered in the handshaking with
the EMU.
Valid Range: 1 to 50 (percent)
Default: 20 (percent)
-u,nnnn This option sets the number of usages (good or bad) that triggers
the trouble counter and the usage counter to be reset to 0. The
default value is 300; it can be set between 20 and 5000. EMUadmin
can also be used to reset these counters (see LoopCare Complete
Guide to the Expert Measurement Unit (EMU) for instructions on the
use of EMUadmin).

A-80 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the M2 Group

Module F:$MLT_BIN/mdr dummy

Module Port(s)
F:$MLT_BIN/mdr mdr,mdro
dummy

This module manages transactions that test Siemens EWSD subscriber loops via
the Siemens FOS interface. Management functions include allocating memory,
choosing the appropriate test algorithm, initiating test access messages through
mmlmgr, setting time limits, and determining verification codes.

Option Description
-l,n This options overrides the transaction time limit to n
seconds. The default is 240 seconds.
-trace,n This option turns on tracing for the module at a
specified level, where n is the level having values of 1,
2, or 3. The default level is set to the value of the
MLTTRACE environmental variable.
-z,n This option sets to n the maximum number of
simultaneous transactions that can be managed. The
default is 1000 transactions.
-& This option forces buffer tracing to be on for all
transactions.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-81

System Administration Guide Group Descriptor Files
Group Descriptor File for the M2 Group

Module F:$MLT_BIN/mrr

Module Port(s)
F:$MLT_BIN/mrr mrr, mrro

The mrr module is used to create the buffers for testing RMUs. The module is the
interface between the test and tv modules and the test equipment.

Option Description
-& Turns on buffer tracing (used for developer debugging
only).
-trace,n Sets tracing level, {n=1,2 or 3}.
-L Used for callback transactions. If a 10 digit callback is
entered in the CB field of the TV mask and a match is
not found in the cbprefix tables, default to 1+ (i.e. 10
digit) callbacks. Without this option the NPA is stripped
from the callback TN and the remaining 7 digits are
used. See "aifdes.cbprefix" for more information.
-N Includes the -L option above and in addition searches
the cbprefix tables for a dialout digit (such as 9). If a
dialout digit is found, 11 digits are dialed (i.e.
91+NPA+NNX+NNNN). If a dialout digit is not found, 10
digits are dialed. See "aifdes.cbprefix" for more
information.

Module F:$MLT_BIN/tserc

Module Port(s)
F:$MLT_BIN/tserc tserc

This module supervises tests run on CMUs and RMUs. It contains the testing
algorithm.

A-82 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the M2 Group

Option Description
-& Turns on buffer tracing (used for developer debugging
only).
-a This option adjusts the AC voltage used for CPE
detection.
For Vendor ID = Tollgrade, the limits are 1 >= VAC <=
127.
A test head does not have to support every voltage but
uses the nearest voltage it can and reports the actual
voltage in the response.
-f This option turns on Fast FULL. Fast FULL will reduce
the response time on a FULL request.
-g This module enables the enhanced channel isolation
tests for ground start lines served by a SLC system.
-m This option enables the MTU Detect feature for EMU
testheads.

This option must be set for the Enhanced MTU

Detection function to be active.

NOTE:
Options for enabling MTU algorithms also exist in
the m2r (-M) and tser (-m) modules of MGRP.gdf.
UIt is strongly recommended that the three
options be set the same, either all three ON or all
three OFF.
-n Change the wideband analysis mode from Data Rate
Prediction (default) to noise margin threshold.
-r This permits Channel Unit Emulator (CUE) access for
non-locally switched or non-switched Extended Super
POTS (ESPOTS) and 4-wire channel units.
-A This option is used to turn on the ADSL Transmission
Unit-Central (ATU-C) signature detection retest feature.
See ATU-C Signature Detection Retest Variables: page
B-18.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-83

System Administration Guide Group Descriptor Files
Group Descriptor File for the M2 Group

Option Description
-B This option is effective only if the Wideband testing
feature is enabled. When activated this option may
provide improvement in the returned Bridged Tap
results when testing with a Tollgrade DMU.
For the DigiTest Edge, the -B option causes the bridged
tap and loop length results from the broadband testing
to be ignored when they are significantly different from
the TG capacitance measurement of loop length. This
allows the ATTEN results to be used when they are
accurate and ignored otherwise. See the description of
the SELQLIMIT_FT variable in the M2.env file
(Appendix B of this guide).
The -B option must be set for the BTAPVAR variable to
be used. See M2.env in Appendix B.
-C To suppress Remote Terminal (RT) Calibration error
messages from non calibrated RTs, when the digital
loop carrier lines (DLC) Loop Calibration feature
(feature 110) is active.
-F Uses the values of critical noise margin and data rate
prediction values input into the /mlt/adsl/WBdata control
file for wideband data rate prediction algorithm. These
values can be adjusted by the user to fine tune the
wideband results.
-L This option enables coil tests on LOOP/FULL/BENCH
test requests. The load coil tests include splitter
detection tests when the Splitter Detection feature is
enabled.

NOTE:
Make sure that you enter a DSL override (e.g.
C90) when you submit these requests.Enabling
this option may result in incorrect load coil
detection on in service DSL lines.

A-84 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the M2 Group

Module F:$MLT_BIN/tserd

Module Port(s)
F:$MLT_BIN/tserd tserd

This module sends and receives measurement messages through mmlmgr and
processes measurement results according to the testing algorithm that is selected
by mdr.

Option Description
-trace,n This option turns on tracing for the module at a
specified level, where n is the level having values of 1,
2, or 3. The default level is set to the value of the
MLTTRACE environmental variable.

Module E:/base/bin/shrdemon

Module Port(s)
E:/base/bin/shrdemon YY

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry. The shrdemon module is a BASE module that
runs in the LoopCare application. For the most recent information about the
options for shrdemon refer to the document 450.gdf_files in the BASE user
document (or 451.gdf_files for those customers with standard UNIX System 5 or
later).

Option Description
-S Allows the shrdemon module to run silently, without
output.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-85

System Administration Guide Group Descriptor Files
Group Descriptor File for the M2 Group

Example of GDF Below is an example of the M2.gdf file.

File

A-86 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MPST Group

Group Descriptor File for the MPST

Group

Description

Name Directory Level

MPST.gd /base/config 4th level of
LoopCare

The MPST group brings up the processes required to test LoopCare through the
PST interface. This group includes the following main functions:
• Invokes the master PST process which controls the rate of inward flow of
test requests.
• Invokes the processes that control the outward flow of PST test requests to
the following LoopCare test vehicles:
— pstlts (for test requests to LTS)
— pstcmu (for test requests to CMU)
— pst_5e (for test requests to DCTU)
— psttsc (for test requests to LTF through TSC)
— pstrem (for PST on remote machines) p
— st_34 (for test requests to LTF through 11/34)
— pstsdv (for SDV test requests)

The MPST group is one of the fourth level groups in the LoopCare application.
This group is brought up by the grpmgr shell in MGRP.gdf. No other LoopCare
application groups are below the MPST group. Four other groups are at the same
level. They are:
M1
M2
ISDN
SDV

Standard gdf File This section describes the options available to the modules in this group, except
Release for some options associated with special billable features or security options. Not
all the options listed in this section are required to be set up in the gdf file. The
system will be released with a MPST.gdf file which includes a standard

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-87

System Administration Guide Group Descriptor Files
Group Descriptor File for the MPST Group

configuration of modules with appropriate options. It is suggested that the user run
with this standard gdf file and make adjustments only when conditions require.

Description of GDF Module I:/base/bin/shrdemon

Information
Module Port(s)
I:/base/bin/shrdemon XX

This instructs shrdemon to free any shared memory descriptors that have been
left following a fatal. This is a preprocessing line required for all group managers.
The port name (XX) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Module I:/bin/sh

Module Port(s)
I:/bin/sh PP

This shell invokes some LoopCare initialization processes required to run before
the group is started.

Option Description
$MLT_UTL/pstinit Shell program initiated when MPST modules are
invoked.

A-88 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MPST Group

Module F:$MLT_BIN/pstmaster

Module Port(s)
F:$MLT_BIN/ pstt
pstmaster

This module is the master PST process which controls the rate of inward flow (i.e.,
the rate of receipt) of PST test requests.

Option Description
dummy Default null option.
-mlt2 This option will direct PST to send tests to MLT-2 under
specified conditions. If this option is not set, tests will
not be sent to MLT-2 and will return results that indicate
test system error.
-trace,n This option turns on tracing for the module at a
specified level. Where n is the level having values of 1,
2 or 3.
-E,n This option determines how often certain console error
messages will be displayed (where n is between 50 and
500 inclusive, the default value is 100).
For example, if the user sets the pstmaster gdf option "-
E,200", then the console message will be displayed the
first time and then every 200 occurrences thereafter. If
the "-E,n" option is not specified at all, or is specified
with an invalid "n", then the default error interval of 100
is used. A separate error count is kept for each PST
application process.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-89

System Administration Guide Group Descriptor Files
Group Descriptor File for the MPST Group

Option Description
-P,n This option designates the number of pools for active
source processes. Where n is the number of pools, with
a possible range of 1 through 20. This value should be
set to equal the largest number of source processes
that might exist for this MPST group. To calculate this
value use the equation (X times 2) plus (Y minus 1),
where X is the number of LMOS groups configured to
send PST requests to this PST group, and Y equals the
total number of Front Ends.
-Q,n This option designates the size of each pool, where n
equals the number of test requests. The allowable
range is 1 through 200, and the default value is 200.
However, it is recommended that a smaller value be
used (e.g. 50).
-I This option is used in the form -I <process name>
<machine id>; pstmaster will ignore any messages from
the specified source process. This option may be used
to reduce the number of pools required in pstmaster. It
prevents a pool from being unnecessarily allocated for
requests from PSTL on the machine specified. Up to 10
different processes can be ignored, but you must
specify each with a separate "-I".

A-90 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MPST Group

Module F:$MLT_BIN/pstlts

Module Port(s)
F:$MLT_BIN/pstlts pstlts

This module controls the outward flow of PST testing requests to the LTS.

Option Description
-D This option sets the length of the delay (in seconds)
time before a request is sent to the LTS. The number of
seconds that can be specified range from 40 to 7200 (or
40 seconds to 2 hours), the default value is 40 seconds.
-S This option sets the length of the duration for which
Flow Control will be in effect. The number of seconds
that can be specified range from 1800 to 21600
seconds (or 30 minutes to 6 hours), the default value is
2 hours.
-trace,n This option turns on tracing for the module at a
specified level. Where n is the level having the values of
1, 2, or 3.

Module F:$MLT_BIN/pstcmu

Module Port(s)
F:$MLT_BIN/pstcmu pstcmu

This module controls the outward flow of PST testing requests to the CMU.

Option Description
dummy Default null option.
-trace,n This option turns on tracing for the module at a
specified level. Where n is the level having the values of
1, 2, or 3.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-91

System Administration Guide Group Descriptor Files
Group Descriptor File for the MPST Group

Module F:$MLT_BIN/pst_5e

Module Port(s)
F:$MLT_BIN/pst_5e pst_5e

This module controls the outward flow of PST testing requests to the DCTU.

Option Description
dummy Default null option.
-trace,n This option turns on tracing for the module at a
specified level. Where n is the level having the values of
1, 2, or 3.

Module F:$MLT_BIN/pst_84

Module Port(s)
F:$MLT_BIN/pst_84 pst_84

This module controls the outward flow of PST testing requests to the LTF off of the
11/84 Controller.

Option Description
dummy Default null option.
-trace,n This option turns on tracing for the module at a
specified level. Where n is the level having the values of
1, 2, or 3.

A-92 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MPST Group

Module F:$MLT_BIN/psttsc

Module Port(s)
F:$MLT_BIN/psttsc psttsc

This module controls the outward flow of PST testing requests to the LTF off of the
TSC Controller.

Option Description
dummy Default null option.
-trace,n This option turns on tracing for the module at a
specified level. Where n is the level having the values of
1, 2, or 3.

Module E:/base/bin/shrdemon

Module Port(s)
E:/base/bin/shrdemon YY

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

NOTE:
This line is commented out in the MPST.gdf file. Only customers purchasing
the 11/34 off Datakit VCS feature should remove the "#" before the
#F:MLT_BIN/pst_34 line.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-93

System Administration Guide Group Descriptor Files
Group Descriptor File for the MPST Group

Module F:$MLT_BIN/batchmaster

Module Port(s)
F:$MLT_BIN/ batin, batmsx,
batchmaster batalt (only for ALT
stand-alone batch)

This module controls batch testing for LoopCare's PST module. This module is
applicable for TDIL batch testing.

Option Description
dummy Default null option.
-mlt2 This option will direct PST to send tests to MLT-2 under
specified conditions. If this option is not set tests will not
be sent to MLT-2 and will return results that indicate test
system error.
- t,n This option turns on tracing for the module at a
specified level.
- w,n This option sets the time to wait between checks for
stranded packets. Default is 600 seconds.
- p,n This is the default port name. Defaults to batin.
- P,n This option determines the size of the queue of
outstanding tests. Default is 5000.
- A,n This option sets the maximum number of processes it
can talk to. Default is 2 (one for TDIL and one for ALT).
- R,n This option sets the maximum number of rejects before
giving up on a test. Default is 3. After PST rejects the
test 3 times, the test is rejected for good. Otherwise it
will try to send it to PST again.
ALT stand-alone batch options:
-I This option selects ALT style logging.
- s,n This option sets the spool interval, the wait between
checks of the database. Default is 60 seconds.
- S.n This option sets the spool size which is the number of
tests to spool from each list. Default is 10.
-L This option turns on the ALT stand-alone batch option.
Default is off.

A-94 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the MPST Group

Example of GDF File

Below is an example of the MPST.gdf file.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-95

System Administration Guide Group Descriptor Files
Group Descriptor File for the ISDN Group

Group Descriptor File for the ISDN

Group

Description

Name Directory Level

ISDN.gdf /base/config 4th level of
LoopCare

The ISDN group brings up processes required to test LoopCare/ISDN lines. Three
modules are ISDN-specific, (i.e., they are not used in LoopCare testing on lines
that are not ISDN). These modules are:
mir
tseri
tipi

The ISDN group is on the fourth level of the LoopCare application. This group is
brought up by the grpmgr shell in MGRP.gdf. No other application groups are
below the ISDN group. Three other groups are at the same level. They are:
M1
M2
MPST

Standard gdf File This section describes all of the options available to the modules in this group,
Release except for some options associated with special billable features or security
options. Not all the options listed in this section are required to be set up in the gdf
file. The system will be released with an ISDN.gdf file which includes a standard
configuration of modules with appropriate options. It is suggested that the user run
with this standard gdf file and make adjustments only when conditions require.
Note that the ISDN.gdf file is to be used only with LoopCare/ISDN Feature
Packages 2 and 3.

NOTE:
If imgr and tllmgr are present in the ISDN.gdf, one of the following features
must be enabled for your environment:

TL1 DMS
or
TL1 ESWD

A-96 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the ISDN Group

Description of GDF All of the modules listed below contain a common "dummy" option which is a
Information default null option.

Module I:/base/bin/shrdemon

Module Port(s)
I:/base/bin/shrdemon XX

This instructs shrdemon to free any shared memory descriptors that have been
left following a fatal. This is a preprocessing line required for all group managers.
The port name (XX) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Module I:/bin/sh

Module Port(s)
I:/bin/sh isdni

This module performs any functions that need to be done prior to the LoopCare/
ISDN modules start-up.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-97

System Administration Guide Group Descriptor Files
Group Descriptor File for the ISDN Group

Module F:$MLT_BIN/mir

Module Port(s)
F:$MLT_BIN/mir mir, miro

This module processes test request data and routes that data to the test vectors.

Option Description
-z,n This option provides "n" number of simultaneous
transactions that can be processed. The valid range
allowed for mir is 10-1000. The default value is 150.
This option is used to throttle LoopCare transactions.
The value "n" should be set according to load; if n is set
at the low end of the range many "BUSY" messages
may be returned, if n is set at the high end of the range
there is a danger of outage due to using up all shared
memory descriptors (total 1000 available for ALL
applications on the VAX).
-trace,n This option turns on tracing for the module at a
specified level, where n is the level having values of 1,2,
or 3. The default level depends on how the group was
started.
-& Forces test buffer tracing (used for developer
debugging only).
-T,n This option defines the number of tsers to be brought
up, where n = the number of tsers.
-L Used for callback transactions. If a 10 digit callback is
entered in the CB field of the TV mask and a match is
not found in the cbprefix tables, default to 1+ (i.e. 10
digit) callbacks. Without this option the NPA is stripped
from the callback TN and the remaining 7 digits are
used. See "aifdes.cbprefix" for more information.
-N Includes the -L option above and in addition searches
the cbprefix tables for a dialout digit (such as 9). If a
dialout digit is found, 11 digits are dialed (i.e.
91+NPA+NNX+NNNN). If a dialout digit is not found, 10
digits are dialed. See "aifdes.cbprefix" for more
information.

A-98 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the ISDN Group

Module F:$MLT_BIN/tseri

Module Port(s)
F:$MLT_BIN/tseri tseri

The tseri (Test Series for ISDN) module contains the test vectors themselves. This
module provides the interface between LoopCare/ISDN and the associated test
hardware.

Option Description
-C To suppress Remote Terminal (RT) Calibration error
messages from non calibrated RTs, when the digital
loop carrier lines (DLC) Loop Calibration feature
(feature 110) is active.
-h This option enables clamp bypass testing.
-o This option disables hazardous potential detection for
certain transactions.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-99

System Administration Guide Group Descriptor Files
Group Descriptor File for the ISDN Group

Option Description
-& Forces test buffer tracing (used for developer
debugging only).
-T,n This option defines the number of tsers to be brought
up, where n = the number of tsers.
-p,nC or -p,nR The -p option defines the data rate pattern to be used
for digital loopbacks from Integrated Services Test
Facilities (ISTFs), where nC and nR = the kilobit rate
and pattern (Clear or Restricted). Entries are made in
the following forms:
For 64Kb Clear -p,64C -p,64c
For 64Kb Restricted -p,64R -p,64r
For 56Kb Restricted -p,56R -p,56r

If the -p option is not defined in the tseri line of the

ISDN.gdf file, the default value used is 56Kb Restricted.
After an entry is made, the /base/config/ISDN.gdf file
should be updated by running the /mlt/ubin/confg_sh
program.

NOTE:
The 64Kb Clear option should be used ONLY if
there are no Remote Switching Modules (RSMs)
or if ALL umbilicals are at 64C. The 64Kb
Restricted option should be used ONLY if all
umbilicals are at 64R.

Module F:/isdn/bin/tipi

Module Port(s)
F:/isdn/bin/tipi tipi

The tipi module functions as the interface between LoopCare or LMOS/WM and
LoopCare/ISDN. It responds to requests sent from the tip module for ISDN line

A-100 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the ISDN Group

testing. Tipi obtains line specification information, performs validity checks, and
processes overrides and line record data in response to the requests it receives.

Option Description
-trace, n This option turns on tracing for the module at a
specified level, where n is the level having values of 1,
2, or 3. The default level is set to the value of the
MLTTRACE environmental variable.

Module E:/base/bin/shrdemon

Module Port(s)
E:/base/bin/shrdemon YY

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-101

System Administration Guide Group Descriptor Files
Group Descriptor File for the ISDN Group

Example of GDF file

Following is an example of the ISDN.gdf file.

A-102 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the CGRP Group

Group Descriptor File for the CGRP

Group

Description

Name Directory Level

CGRP.gdf /base/config 4th level of
LoopCare

The CGRP group brings up processes required for the LoopCare CORBA
Application Programming Interface (API). Three modules are CGRP-specific.
These modules are:
corbaGWbase
corbaGWN
corbaGWS

In addition, the cgrpinit module, a shell script, brings up additional processes.

The CGRP group is on the fourth level of the LoopCare application. This group is
brought up by the grpmgr shell in MGRP.gdf. No other application groups are
below the CGRP group. Four other groups are at the same level. They are:
M1
M2
MPST
ISDN

Standard gdf File This section describes all of the options available to the modules in this group,
Release except for some options associated with special billable features or security
options. Not all the options listed in this section are required to be set up in the gdf
file. The system will be released with an CGRP.gdf file which includes a standard
configuration of modules with appropriate options. It is suggested that the user run
with this standard gdf file and make adjustments only when conditions require.
Note that the CGRP.gdf file is to be used only with LoopCare/CORBA API feature.

Description of GDF All of the modules listed below contain a common "dummy" option which is a
Information default null option.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-103

System Administration Guide Group Descriptor Files
Group Descriptor File for the CGRP Group

Module I:/base/bin/shrdemon

Module Port(s)
I:/base/bin/shrdemon XX

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Module I:/usr/lbin/

Module Port(s)
I:/usr/lbin/ IPDEMON

This module prints information about the interprocess message queues within the
kernel address space.

The module is a BASE module that runs in the LoopCare application. For the most
recent information about the options for, refer to the document 451. in the BASE
user document.

Module I:$MLT_UTIL/cgrpinit

Module Port(s)
I:$MLT_UTIL/cgrpinit cgrpinit

This script invokes initialization processes required to run before the group is
started. In addition, it brings up the following processes:
• /opt/BDP/bin/osagent
Visibroker smart agent on HP-UX 11i and Solaris 8 only.
• $ORBIXDIR/bin/orbixd
Orbix agent on HP-UX 10.20 only.

A-104 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the CGRP Group

• $MLT_BIN/mltDataChannelSrv
Supports the MDataChannel.idl as a server. It provides a data channel
factory to create data channels for the distribution of test results to CORBA
API clients. For HP 10.20 systems, LoopCare can start multiple
mltDataChannelSrv processes, increasing the number of data channels
supported. Use the CGRP_DC_OPTS environmental variable defined on
page B-47 to set the options on start up.

Option Description
-s <suffix> This option specifies the suffix for the trace file
(dcstrace<suffix>), IOR reference file (dcf<suffix>.ref),
and the Orbix server name (MdataChannelSrv<suffix>.
This option applies to HP 10.20 systems only.
-t <number threads> This option specifies the number of threads to create.
This number should be at least twice the number of
data channels required.
-z If this option is specified, the reference file will not
include the header MtestRequestObj= before the
mlt.ref IOR file.
-P <file> This option specifies the full path to the Visibroker
properties file.It applies to HP 11i and SOLARIS
systems only. The properties file is used to set the TCP
port for the server. If not supplied, the system selects
the port.

• $MLT_BIN/dgChannelSrv
Listens on a UDP port for IOR requests and returns the contents of the
corresponding IOR reference file.

Option Description
-t <level> This option specifies the trace level.
-z <UDP port> This option specifies the listening UDP port.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-105

System Administration Guide Group Descriptor Files
Group Descriptor File for the CGRP Group

• $MLT_UBIN/CGRP.monitor

Option Description
-s <suffix> This option specifies the suffix for the trace file
(dcstrace<suffix>), IOR reference file (dcf<suffix>.ref),
and the Orbix server name (MdataChannelSrv<suffix>.
This option applies to HP 10.20 systems only.
-t <number threads> This option specifies the number of threads to create.
This number should be at least twice the number of
data channels required.
-z If this option is specified, the reference file will not
include the header "DataChannelFactory=" before the
IOR.
-P <file> This option specifies the full path to the Visibroker
properties file.It applies to HP 11i and SOLARIS
systems only. The properties file is used to set the TCP
port for the server. If not supplied, the system selects
the port.

Monitors the group on HP 10.20 systems only.

Module F:$MLT_BIN/corbaGWbase

Module Port(s)
$MLT_BIN/ cGWB
corbaGWbase

The corbaGWbase module manages the test results from LoopCare for clients of
the CORBA API. It supports the MDataChannel.idl and the CallBack.idl as a
client. If Call Back method is used, then the results are sent to the Call Back
server which is indicated by the IOR that is supplied by the user. If Data Channel

A-106 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the CGRP Group

is used, then the results are sent to the data channel in mltDataChannelSrv
process indicated by the IOR that is supplied by the user.

Option Description
-c Use the local call back IOR reference file /mlt/mlttables/
callback.ref for returning all call back results rather than
the IOR supplied by the client.
-q Speeds up the CORBA interface between LoopCare
and Telcordia's AAI system.
-r This option is available for HP 10.20 only.
On call back connect failures, retry once.
If the option is not supplied, there is no retry.
-t,n This option sets the trace level to n, 0 to 3.

Module F:$MLT_BIN/corbaGWN

Module Port(s)
$MLT_BIN/corbaGWN cGWN

The corbaGWN module supports the ALANS.idl as a CORBA client. This process
is the Data Requester interface to NSDB to obtain line records.

Option Description
-h,n This option specifies the number of threads (i.e.
simultaneous data requests), n.
-s,n This option specifies the CORBA server name, n.
-t,n This option sets the trace level to n, 0 to 3.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-107

System Administration Guide Group Descriptor Files
Group Descriptor File for the CGRP Group

Module F:$MLT_BIN/corbaGWS

Module Port(s)
$MLT_BIN/corbaGWS cGWS

The corbaGWS module supports the mtestreq.idl and the mltSession.idl as a

server. It receives requests from CORBA API clients and distributes them to
LoopCare for processing.

Option Description
-p,n This option specifies the port name of corbaGWbase, n.
This is usually cGWB.
-s,n This option specifies the server name supplied to Orbix,
n, used to register the server.
-t,n This option sets the trace level to n, 0 to 3.
-z If this option is specified then the reference file will not
include header "MtestRequestObj=" before the IOR.
-P,n This option specifies the full path to the Visibroker
properties file, n. This option applies to HP 11i and
SOLARIS systems only. The properties file is used to
set the TCP port for the server.
If not supplied, the system selects the port.

Module I:/bin/sh

Module Port(s)
I:/bin/sh cgrpend

This module starts the cgrpend script when the group is stopped. This script
performs cleanup and stops the processes that the cgrpinit module brought up.

A-108 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Group Descriptor Files System Administration Guide
Group Descriptor File for the CGRP Group

Module E:/base/bin/shrdemon

Module Port(s)
E:/base/bin/shrdemon YY

This instructs shrdemon to free any shared memory descriptors when the group is
stopped. This is a preprocessing line required for all group managers. The port
name (YY) is a default null entry.

The shrdemon module is a BASE module that runs in the LoopCare application.
For the most recent information about the options for shrdemon refer to the
document 450.gdf_files in the BASE user document (or 451.gdf_files for those
customers with standard UNIX System 5 or later).

Example of GDF file

Following is an example of the CGRP.gdf file.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 A-109

System Administration Guide Group Descriptor Files
Group Descriptor File for the CGRP Group

A-110 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental
Variables B

System Environmental Variables and

Paths

Overview Since each LoopCare site has a highly unique configuration, the software needs
to be sensitive to these individual site differences. The way LoopCare finds out
the many site-specific parameters is through environmental variables. These are
shell variables which may be set via the User Interface Program (UIP). The
software will use the values in these variables to change the functioning of
LoopCare.

! WARNING:
Do not use vi or any other means except UIP to modify these environmental
variables; an improperly formatted entry can cause major system problems.
The UIP System Administration menu option, Set Environment, allows you
to enter only user-settable values and properly formats that data.

Of the many environmental variables defined, only a handful can be set by the
user. The majority of the environmental variables are preset by the system
programmers. Out of the many user-definable variables, only a few MUST be set
prior to bringing up LoopCare. These will be set during the installation process.
Other variables are optional, and an appropriate default value will be used if not
defined by the user.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-1

System Administration Guide User-Definable Environmental Variables
System Environmental Variables and Paths

Another important set of variables are those that define the directory structure,
called environmental path names. These path names should be used rather than
the many "hard coded" path names that are currently being used.

The Update Process In a new installation of LoopCare, the default values for environmental variables
are stored in the following path:
/mlt/config/<GROUP_NAME>.env

On initial startup of LoopCare, these files are saved to the following path:
/base/config/<GROUP_NAME>.env

When a user uses the UIP option in OA&M to modify user-settable variables,
LoopCare loads /mlt/config/<GROUP_NAME>.env and the user-set values in
/base/config/<GROUP_NAME>.env into the buffer. The changes are saved in
/base/config/<GROUP_NAME>.env. The /mlt/config/<GROUP_NAME>.env files
are never changed.

During release upgrades, the /mlt/config/<GROUP_NAME>.env files are updated.

To apply the new values of non-user-settable variables to the /base/config/
<GROUP_NAME>.env files, the UIP option in OA&M must be used.

The /mlt/config/<GROUP_NAME>.env files should never be changed. If a user

wants to edit an environmental variables file manually, the /base/config/
<GROUP_NAME>.env file should be edited.

System Table B-3 describes the fields used in the following descriptions of each
Environmental environmental variable.
Variable Table
.

Table B-3. User Definable System Environmental Variables

Field Description
NAME The name of the environmental variable.
GROUP The group with which the variable is associated.
C/O A "C" will be in this field if the user MUST define this
variable (Compulsory). An "O" will be present if the
setting is Optional.

B-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
System Environmental Variables and Paths

Table B-3. User Definable System Environmental Variables

Field Description
B/I "B" means the group (in the GROUP column) must be
brought down and up again for the new value to take
effect. An "I" means the new value takes effect
immediately.
DEFAULT Default values for variables. A "-" means there is no
default.
DESCRIPTION This is a short definition of what the variable controls.
REFERENCES This field will list any modules that explain in greater
detail the meanings of terms used in the definition.

The hierarchy of the software groups (and thus their GDF files) is as follows:
MLT

MDMN

MGRP

M2 MPST ISDN*
* MLT/ISDN is a separate feature of the Mechanized Loop Testing Sys-
tem which is used to test Integrated Services Digital Network lines. It is
not included with a standard MLT-4 platform.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-3

System Administration Guide User-Definable Environmental Variables
MLT.env

MLT.env

Introduction The following sections describe the customer-definable variables in the MLT.env
file and their options.

ADEF_INS Optional

Options
• :l
— ADEF_INS enables or disables the :I command.
• :i
— ADEF_INS=ON enables :i which allows the ADEF user to run the
install shell for a mask directly from the mask.
— ADEF_INS=OFF disables :i requiring the ADEF user to quit out of
ADEF and then run the install shell.

Default: ON

ADEF_MRGN Default: 10

ADEF_TSC Default: 60

APPRECOVERTI This variable defines the amount of time in minutes that must elapse before the
ME primary server starts re-directing logins to the secondary server and vice versa.It
applies only to the Hot Standby feature.

Usage

RECOVERY_INTERVAL=X, where X is 2 to 60.

Default: 5

B-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MLT.env

MAXCONN This variable supports TDIL. It informs the gwsouth process of the maximum
number of permitted TDIL connections.

MLT_LIST_DIR Sets the the directory name where loop detect input files are located. Each of
these files contains a list of telephone numbers to be tested during a loop detect
batch run.

Default: /mlt/list.

MLT_RMVWEBFI Determines the retention duration in days of files in the /mlt/webgui/results.

LES
Valid values: N or an integer.
• N indicates that the files in the /mlt/webgui/results directory are not to be
removed by LoopCare. The customer has their own procedure for dealing
with these files.
• An integer indicates the interval in days after which the files should be
deleted.

See the "Testing Activity Feature (TAF)" section of Chapter 4 of this Guide.

MLT_WEBFILES Used by cgiReportsClean.sh for determining the path to be used by mltclean for
removing old files in the /mlt/webgui/results folder.

MLT_WEBFILES is set to $SRCNODE/webgui/results, where $SRCNODE = mlt.

See the "Testing Activity Feature (TAF)" section of Chapter 4 of this Guide.

MNWID This variable supports TDIL. It is the TCP/IP address of the TDIL connection.

NFE Optional

Description

The LMID of the LMOS/WM Front End from which LoopCare retrieves line
records.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-5

System Administration Guide User-Definable Environmental Variables
MLT.env

Modification requires that the group (in the GROUP column) be brought down
and up again for the new value to take effect.

Default: 59

ORACLE_HOME Default: /oracle/app/oracle/product/8.1.7

PINGDMNPRT Determines if messages should be sent to the Facilities Manager printer.

Messages are sent only if PINGDMNPRT=1.

UIP_PG Default: ON

B-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MDMN.env

MDMN.env

Introduction The following sections describe the customer-definable variables in the

MDMN.env file and their options.

BASECONT The BASECONT environmental variable represents the base value of TCP
destination port ranges that Loopcare will use when opening socket connections
to DT6061 network processors for the purpose of receiving status information
from LTCNs. The exact TCP destination port that is used is determined by the
value of BASECONT + LMID – 49.

Ths variable is used for the LTCN application to allow users to get connections to
the LTCN when they have Front Ends with the same LTE ID.

This should normally not be the case and the recommendation is that this variable
should never be used.

Default: 31000

BASEHOST The BASEHOST environmental variable represents the base value of TCP
destination port ranges that Loopcare will use when opening socket connections
to DT6061 network processors for the purpose of exchanging data to and from
LTCNs. The exact TCP destination port that is used is determined by the value of
BASEHOST + LMID – 49.

Ths variable is used for the LTCN application to allow users to get connections to
the LTCN when they have Front Ends with the same LTE ID.

This should normally not be the case and the recommendation is that this variable
should never be used.

Default: 30000

COMMSTATMET Optional
HOD
Options
• R

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-7

System Administration Guide User-Definable Environmental Variables
MDMN.env

— The reader process is used to determine the OPEN or CLOSED

status of the communication to the equipment. With this option, the
status is determined more quickly. With this option, the status is an
indication of the state of the socket connection between commdmn
and the LTCN.
• W
— The writer process is used to determine the OPEN or CLOSED
status of the communication to the equipment. With this option, the
status is an indication of the ability of commdmn to accept test
requests from application processes.
—

Default: W

COMMSTATOPT Optional

COMMSTATOPT should be set if you wish to display service name information if

you when using LCN or LTCN.

Options
• D
— Enter the D option if you have DCN only.
• M
— Enter the M option if you have a mixed DCN/LCN/LTCN.
• L
— Enter the L option if you have LCN only,.
• T
— Enter the T option if you have LTCN only.

Default: D. The setting for DCN only. The setting controls the output on the
commstat utility. (See the end of this section for an example of the commstat
variable with a M option.)

See the Communication Ports UIP option in the OAM Guide, chapter 7, for
information on running the commstat utility directly on a UNIX command line.

B-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MDMN.env

Examples
a. Variable not set or set to anything except M or L:

b. Variable set to M:

DZNEWOPTS Compulsory

The group must be brought down and up again for values to take effect.

Options
• -a #
— default read() alarm
• -B #
— blocking
• -d #
— The -d option is applicable to Directly Connected DMUs deployed as
part of a CO EMU or to a Direct Connect DMU deployed as an RMU
or RMU-S. The value of # indicates the number of seconds that the
Direct Connect (TCP/IP or Access Server) is to be held after test
completion.
Range: 2 to 1679 seconds (28 minutes)
Default: 30.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-9

System Administration Guide User-Definable Environmental Variables
MDMN.env

NOTE:
For a DMU deployed as an RMU, the hold time (for Modem Dial and Direct
Connect) needs to be longer due to the extra time used by the CO test unit
to complete the test and drop access to the line. Due to this extra time, the
hold time needs to be at least 10 seconds to allow for another test to come
in. Customers who want the option to hold access on a Modem Dial or
Direct Connect RMU need to change the values of both the -d and -z
options (see below) to 15 seconds or greater. A side result of this will be
that the access will be held longer than necessary on Direct Connect EMUs
and RMU-Ss (which should not be a problem since they do not use a
limited resource such as a modem) and on Modem Dial RMU-Ss (which will
end up utilizing Modems longer than required if Batch testing is not being
done).

• -e
• env file for addenv()
• -E #
— Controls the wait time in seconds between login attempts for direct
connect access server based connections. This setting should be
tuned to your network using the nodial utility.
Range: 2 to 20
Default: 5
• -f
— HP tty dialout format /dev/cul#p#
• -G #
— Specifies the number of seconds LoopCare waits for a socket
connection to any test unit is accessed through DZmaster, i.e. the
DMU, RMUS, or RMU. LoopCare times out after the specified
number of seconds and ends the connection attempt.
The default timeout value for a socket connection is a UNIX based
parameter and varies among operating systems. In some operating
systems, it takes 75 seconds for the system level timeout to occur.
LoopCare cannot wait this long. Use this option to break the socket
connection attempt after a shorter timeout value.
Default: 10
• -i #
— Indicates how long to allow an idle socket before dropping it.
• -j #

B-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MDMN.env

— Controls the number of login attempts for modem based

connections.
Setting j to 0 or 1 results in 1 attempt.
Setting j to 2 results in 2 attempts.
Setting j to 3 results in 3 attempts.
Default: 3
• -J#
— Controls the number of login attempts for direct connect access
server based connections.
Setting J to 0 or 1 results in 2 attempts.
Setting J to 2 results in 4 attempts.
Setting J to 3 results in 6 attempts.

Default: 0
• -k #
— For subsequent reconnect attempts on an established connection
experiencing a spurious drop. @ is the number of reconnect
attempts (0-n).
The -k option does not work with the -q option as defined for the -j
Option above. The number of retries on a lost connection is limited
by the value of -k.
Default: 3
• -L #
— trace levels
• -m #
— The -m # option is used to set the time the modem is connected to
the DMU-C Central Office test head after test access is dropped.
The XX is the time in seconds access is held, between 2 and 1679
(28 minutes).
Default: 30.
Only set the -m option if the modem is dedicated to a DMU-C test
head located in the central office. Do not set this if modem pools are
used.
• -o #
— The # is the total number of DMZ- 32/DHU-11 ports with directly-
connected modems, plus the expected maximum number of
concurrent Datakit connections.
• -p #

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-11

System Administration Guide User-Definable Environmental Variables
MDMN.env

— Controls the alarm wake up call when waiting for a password

prompt. For modem based connections this value is always 9.
seconds. For direct connect access server based connections this
value is settable.
Range: 3 to 9
Default: 5
• -P
— pulse dialing via local modems
• -q #
— Controls the number of attempts to connect for both modem based
connections and direct access server connections.
This option interacts with the -j option. The -q option restarts a new
draw process the number of times specified by the -q option. Each
time the draw process is spawned, it reiterates the number of
connection attempts specified by the -j option.

Values Result
q=0 or 1 and 3 connect attempts.
j=3
q=2 and j=3 6 connect attempts.
q=3 and j=3 9 connect attempts.

Default: 2
• -r #
Controls the wait time in seconds between login attempts for modem
based connections.
Access servers require as much as15 seconds before accepting
new socket connections after a socket has been closed. This
requirement is independent of the type of test head used (DMU-C or
an RMU).

Default: 15
• -R #
— Wait time for socket interface DZmaster
The -R option determines the number of seconds DZmaster queues
a new request after a previous disconnect. A disconnect from a test
unit may take around 5-20 seconds, depending on the type of

B-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MDMN.env

connection, modem or direct access. During this time, a new

request for this test unit may arrive. This option sets the amount of
time the new request will wait for the test unit to become accessible
again.
• -t #
— local modem ports
• -T
— trace file
• -w #
— Wait for Connect time for socket interface
The time to wait for modem CONNECT string.
Only used for access server modem pools.
This value is dependent on the modem connection speed not on the
type of test head, RMU or EMU.
Default: 30 seconds.
• -z #
— controls the retention time for RMUs and RMU-Ss connected via
modem. The # is the number of seconds the access is held after test
completion, between 1 and 1679 (28 minutes) seconds.
Default: 5 seconds.
See the Note pertaining to the -d option.

By adjusting the values of the -q, -j, -k options the user can determine how many
initial and reconnect attempts are made for failed connections to testheads that
use DZmaster.

Supported Modems

Table B-4 provides a list of supported modem types along with the alpha character
used to represent each modem. Using the alpha character when designating DZ
ports is optional for the first five modem types listed; using the alpha character
when designating DZ ports is required for the last three modem types listed.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-13

System Administration Guide User-Definable Environmental Variables
MDMN.env

Table B-4. Supported Modems

Modem Type Alpha Character

Lucent Technologies A or a
4000
Dataphone II D or d
NEC N or n
Penril P or p
Ventel V or v
Lucent Technologies D or d
2224CEO
Lucent Technologies D or d
4024
Ventel 2400-43 V or v

DZOPTIONS Optional

The group must be brought down and up again for the new value to take effect.

Options
• -d
— Defines the hold time in seconds that DZmaster holds a connection
up after a request finishes. Default: 10 seconds.
• -F
— The -F to look for device files in the format /dev/culXpY on the HP
only.
• -G
— The -G sets the timeout value of the socket connect() system call. A
value of 10 seconds is recommended. The option is needed to
generate the VER codes FP and FR for communication problems.
• -P
— The -P for pulse-dial Dzadmin modems

B-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MDMN.env

NOTE:
The -T option has been discontinued. The tracefile is now always either
$MLT-TRC/dz-w.trc or $MLT-TRC/dk-rwN.trc.

Default: ""

DZPORTS Optional

The group must be brought down and up again for the new value to take effect.

Description

Indicates which compdes ports are to be used for directly connected modempool.

Default: ""

LATIME Optional

When this variable is modified, the changes take place immediately.

Description

Specifies the duration of a hardwire looparound that is run as part of DCN

diagnostics or LTS diagnostics through an LTCN.

Options

The only valid options are blank, 30 or 60 seconds.

Default: 30

M1CTLS Optional

The group must be brought down and up again for the new value to take effect.

Description

Maximum number of M1 controllers.

Default: 25

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-15

System Administration Guide User-Definable Environmental Variables
MDMN.env

MLT_NPALT Indicates whether the LTCN will alternate the ranges for the HOST and
CONTROL channels established between LoopCare and the DT-6061. LoopCare
will add 10 to the initial values and then alternate between the initial and +10
values.

MLT_NPALT=N indicates that LoopCare should not alternate ranges

MLT_NPALT=Y indicates that LoopCare should alternate ranges.

DEFAULT: Y

The absence of the variable from MDMN.env is equivalent to the default of Y.

MLT_NPDEL Indicates the duration in seconds that LoopCare should retry attempts to re-
connect to the HOST and CONTROL channels between LoopCare and the DT-
6061.

MLT_NPDEL=7200 - LoopCare should retry connecting to DT-6061 for 7200

seconds or 2 hours.

DEFAULT: 3600 seconds (1 hour).

The absence of the variable from MDMN.env is equivalent to the default of 3600
seconds.

NP_ASTYPE A newer build of the DT-4000 supports a TCP port of 1023 instead of 23. This
variable determines which port LoopCare tries first for downloading the DT-4000.

Valid values:
• When this variable is set to 4000, LoopCare tries port 23 first, then port
1023.
• When this variable is set to any other value or there is no value after the =
sign, LoopCare tries port 1023 first, then port 23.

Default: 4000

B-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MDMN.env

NP_POLL_SEC The frequency in seconds that the LoopCare system polls for a status to the DT-
6061 equipment when it detects no data traffic from that equipment.

VALID VALUES: 15 - 3600 (1 hour)

DEFAULT: 20 seconds.

The absence of the variable to the default of 20 seconds.

SANCHKL3 Default: "n"

TSCBCCO Optional

The group must be brought down and up again for the new value to take effect.

Description

TSC controllers have been observed to return a block check of TPAD when it
should be zero. By adding "TSCBCC0=1", m1dmn will not reject such a message
from the TSC or 11/34. (That is a ZERO, not the letter "O", as the last character of
TSCBCC0). This option will improve timeouts to TSC controllers.

TSCSELECT Optional

The group must be brought down and up again for the new value to take effect.

Description

Adding "TSCSELECT=D" (where D is time in seconds) will cause m1_writer to

add a "D" second delay to the bisync protocol. Without "TSCSELECT=D", the poll
message is sent without delay; this could cause the TSC to lose track of the
preceding test request. AT&T recommends an initial setting of "TSCSELECT=3".
Do not set "D" to < 2.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-17

System Administration Guide User-Definable Environmental Variables
MGRP.env

MGRP.env

Introduction The following sections describe the customer-definable variables in the

MGRP.env file and their options.

ANYMEDIA_ISDN This environmental variable determines whether the 5ESS ISDN Status
Verification Feature is activated.

The feature is activated by the following entry.

ANYMEDIA_ISDN=YES

The format is case sensitive and specific. All the following cause the feature to be
inactivated.
• ANYMEDIA_ISDN=
• ANYMEDIA_ISDN=NO
• ANYMEDIA_ISDN=yes
• ANYMEDIA_ISDN=Y

NOTE:
The MGRP.gdf file does not have this line. You must enter the variable to
activate the feature.

Default: The line is omitted, turning the feature off.

ATU-C Signature If the ADSL Transmission Unit-Central (ATU-C) signature detection retest feature
Detection Retest is enabled (see Module F:$MLT_BIN/tser: page A-59, and Module F:$MLT_BIN/
Variables tserc: page A-82), a retest occurs when one of the following conditions is met:
• An ADSL signature is found.
• The tested line is clear of shorts and ground faults - essentially the line
tests OK.

Two environmental variables determine the thresholds within which a retest is

considered successful. Perform the following procedure to change the values of
these variables from the defaults in the table below.
1. Using a Terminal Simulator, login to the system as mlt. Type:
su - mlt

B-18 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

2. Change directories to /base/config. Type:

cd /base/config
3. Using a vi editor, edit the file. Type:
vi MGRP.env
4. Once the file appears in the vi editor screen, insert the following lines at the
end of file:
ATUC_RETEST_LL=xxx
ATUC_RETEST_UL=yyy
Where xxx and yyy are resistance values in Kohms.
5. Save the file and exit the vi editor.

ATUC_RETEST_L Optional
L
The group must be brought down and up again for the new value to take effect.

Description

A retest measurement that falls below this threshold indicates a false or phantom
signature.

Default: 105 KOhms

ATUC_RETEST_U Optional
L
The group must be brought down and up again for the new value to take effect.

Description

A retest measurement that falls above this threshold indicates a false or phantom
signature.

Default: 181 KOhms

ATUR_DATARATE This variable enables the display of the speedbin data rate table generated for a
FULL or LOOP test request when ATUR Detect feature is on and that you connect
the loop to a detectable ATUR.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-19

System Administration Guide User-Definable Environmental Variables
MGRP.env

Valid values:
• Y or y
Display data rate display for FULL or LOOP test when an ATU-R is
detected. The data rate is based on loop length speed bins.
• N or n
Suppress data rate display for FULL or LOOP if an ATU-R is detected.

Default value: N

CAP_BAL_THRES The CAP_BAL_THRESHOLD variable defines the threshold that separates good
HOLD and marginal capacitive balance.

Usage

CAP_BAL_THRESHOLD=X, where X is 98-99.

Default: 98

CLT_BTAP_PERC The CLT_BTAP_PERCENT variable provides a correction factor to compensate

ENT between potential differences in capacitive loop length and loop length measured
on Stingers through wideband test parameters (BTAP length). The value indicates
the percentage difference between the two length measurements that is required
before the correction algorithm is applied.

If the difference between the two length measurements is greater than the value
set for CLT_BTAP_PERCENT, the capacitive loop length is used for data rate
prediction and displayed on test results.

Normally there should not be any significant difference between the two types of
length measurements. However, these options provide a conservative fallback
position from which to base calculations that depend on loop length.

The CLT_BTAP_PERCENT variable must be used in conjunction with the –B

option on the snmp line in MGRP.gdf.

Example

If the CLT_BTAP_PERCENT variable is set to 15, and the difference between the
capacitive and BTAP length is less than 15%, no correction is applied.

Usage

B-20 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

CLT_BTAP_PERCENT=X, where X is 1-99.

Default: 25

CLT_DSHORT_TH Optional
RESH
Description

The default setting for this variable only measures the distance to short on up to
10,000-foot loops.

This variable should be set when the user wants to detect shorts with resistance
values over 700 Ohms. Set the variable to the appropriate resistance value.

Default: OFF

CLTTONEPERIOD This variable allows the user to set the timeout value for theTONE request when it
is used with the CLT/CLT-EX on the Lucent Stinger.

If this variable is not set, and a Stinger to CLT/CLT-EX is used, a VER Code F5 is
returned.

By default, TV has a 60-minute timeout on TONE. TV should therefore use the -N

option of the tv module in the MGRP.gdf file to march the new CLTTONEPERIOD
value to prevent any unexpected test result. If CLTTONEPERIOD is set to 15 and
the -N option is not set, the tone on the line stops after 15 minutes, but the tone
access is available for 60 minutes.

Default = OFF. Maximum = 20.

ccmgrwait This variable is used for increasing the hardcoded timeout value for switch
responses during the switch login process. For example, ccmgrwait=30 adds 30
seconds each time LoopCare waits for a switch response.

DATARATE_DISP This variable determines how data rates are displayed.

LAY
Valid Values
1 = Data Rate Range

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-21

System Administration Guide User-Definable Environmental Variables
MGRP.env

2 = Low Rate Only.

3 = High Rate Only

Default: 1

DAU_DEFAULT_D This variable sets the default value for the DSL type field on the Circuit Test page
SL_TYPE for Telaccords/DAUs. If not set or set incorrectly, the variable defaults to ADSL.

Valid Values
ADSL, adsl, any value starting with either a capital or lower case A = ADSL
L_ADSL, l_adsl, any value starting with either a capital or lower case L =
G.Lite ADSL
SHDSL, shdsl, any value starting with either a capital or lower case S =
SHDSL
GSHDSL, gshdsl, any value starting with either a capital or lower case G =
G.SHDSL
POTS, pots, any value starting with either a capital or lower case P= POTS
only

Default: ADSL

DLU_NT1_THRES This variable sets the capacitance threshold in micro Farads for NT1 detection on
H ISDN lines.

Range: Greater than 0.0

Default: .80

DLU_RINGER_TH This variable sets the capacitance threshold in micro Farads for CPE detection on
RESH pots lines.

Range: Greater than 0.0

Default: .20

B-22 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

DMUSAN_MAX Optional

The group must be brought down and up again for the new value to take effect.

Description

This variable supports Resource Monitoring. Change the maximum number of

DMU-C/DMU-R Sanity processes to run simultaneously. In LoopCare software
this number is set to 3 as the default, which represents 30% of the current total
DZmaster virtual channels.

DMUSAN_TIME Optional

The group must be brought down and up again for the new value to take effect.

Description

This variable supports Resource Monitoring. Change the DMU sanity testing time;
that is, the maximum time allowed for a sanity request to process, and after which
a time out of the request will occur. This time is set to default value of 60 seconds
in the software.

DSL_MODEM_RE Gives the range of resistances for which broadband testing is to be allowed to
SISTIVE_SIGNAT continue. This feature is supported for the Sunrise CLT/CLT-EX only.
URE_RANGE
Some modems have a DC resistance between Tip and Ring. If the
DSL_MODEM_RESISTIVE_SIGNATURE_RANGE variable is not set, when
LoopCare sees this DC resistance, it aborts broadband testing and returns only
the voiceband metallic test results.
1. When a T-R resistance is found that is within the range defined by the
environmental variable, LoopCare continues with broadband testing and
displays the following summary message:
LOW RESISTANCE DETECTED - POSSIBLE DSL MODEM
Broadband testing including data rate prediction and optimization continue
as if no T-R resistance was found.
2. The resistance range is expressed as two colon-separated numbers with
the units of Ohms. The lower number of the range appears first.

NOTE:
LoopCare recommends an initial resistance range of 10000:250000 Ohms.
The use of a resistance less than 100000 Ohms may reduce the accuracy

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-23

System Administration Guide User-Definable Environmental Variables
MGRP.env

of some of the broadband test results, especially data rate prediction and
optimization,. A resistance less than 50000 Ohms may disable rate
prediction because a valid loop length may not be measurable.

3. If only one number is provided to the left of the colon, it shall be used as the
lower limit with the upper limit being infinity (that is, broadband testing is
performed for all resistances above the lower limit).
4. If two numbers are provided but the first is greater than the second, the
feature is turned off.
5. If the environmental variable is not defined, the feature is turned off.

As the default, the environmental variable is not defined (the feature is turned off).

The following signatures are already identified by LoopCare and are not affected
by this environmental variable.
• 100 Kohms to 142 Kohms for CLT/CLT-EX only (set via MGRP.gdf snmprw
-e)
• 13 Kohms to 18 Kohms for CLT only (hardcoded)
• 2 Kohms to 4 Kohms for CLT-EX only (hardcoded)

Users are also free to uniquely identify modem resistive terminations through the
use of the LoopCare Programmable DC Signature feature.

DZSAN_CONNEC This variable determines the number of threads created to handle DMU
TS connections.

Valid values are 1 - 500.

Default: 50

Using the default value is recommended, since the server configuration

sometimes limits the maximum value.

ENAB_VER_0B Controls the display of VER 0B for the Break-Through CPE Detection feature. See
the System Description for more information. If you disable VER 0B, VER 0C is
displayed.

To enable VER 0B, include the following line in the MGRP.env file:
ENAB_VER_0B=Y

B-24 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

To disable VER 0B, include the following line in the MGRP.env file:
ENAB_VER_0B=N

The default is Y.

ENH_LENGTH_BE This variable enables/disables the Loop Length Accuracy Enhancement algorithm
NCH for the BENCH test request.

To enable the feature for the BENCH test request, ensure that the following line is
entered in the MGRP.env file:
ENH_LENGTH_BENCH=Y

N or a Null value disable the feature for this test request.

EWSD_HUNT_GR This environmental variable applies to OE retrieval from EWSD switches. If the
OUP_TYPE EWSD switch returns MULTI-LINE HUNT GROUP in response to an OE retrieval
request and
EWSD_HUNT_GROUP_TYPE=c

LoopCare ignores the hunt group and processes the OE. If this variable is not
defined or defined with any other value, LoopCare displays an error,
VER MH: MEMBER OF MLHG

EXTRA_ENH_LEN This variable enables/disables the Loop Length Accuracy Enhancement algorithm
GTH_CMDS for the DCOIL, FULL, LCOIL, LOOP, and MET test requests.

To enable the feature for the FULL, LCOIL, DCOIL, LOOP, and MET test requests,
ensure that the following line is entered in the MGRP.env file:
EXTRA_ENH_LENGTH_CMDS=Y

N or a Null value disable the feature for these test requests.

EMUADM_MAX_P When Sanity tests are performed on a group of DMUs, such as a region, the
ER_REQUEST number of DMUs that can be tested simultaneously is limited by the size of the

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-25

System Administration Guide User-Definable Environmental Variables
MGRP.env

modem pool used to access the DMUs. Requests to DMUs in excess of the
number of modems return the message Resources Unavailable.

Setting the value of the EMUADM_MAX_PER_REQUEST variable equal to or

less than the size of the smallest modem pool in the system prevents these false
messages. For more details, see the Guide to Tollgrade Testheads.

EMUADM_TIMEO This variable is used to increase (by the specified percentage) configured
UT_FACTOR timeouts specified for emuadm transactions for EMUs and RMU-Ss. On receiving
a request, emuadm calculates a worst case of how much time the entire
transaction should take. If the calculation proves too short, add 30% to the
calculated amount.

Valid Range: 0 to 200.

Default: 30 (This is the default if the variable is not entered in the MGRP.env file.)

EMU_TPG Description
This variable determines how EMUs are used for emu/lts overlays when the line
has testable pair gain.

All EMU trunks that are used to test lines on DLC systems must be wired through
a Pair Gain Test Controller (PGTC). If the EMUs are not wired through a PGTC,
the associated DLC lines cannot be tested by the EMU, and tests are done by the
LTS or DCTU instead. The indication that EMUs are not wired through a PGTC is
given by the EMU_TPG environmental variable.

NOTE:
By forcing LoopCare to never use the EMU for testable pair gain, you lose
remote wideband testing for such lines.

Options
• N
— Never use EMU for emu/lts overlay when line has testable pair gain
if line record indicates SLC or if there is no line record and the 3034
feature is enabled.
• S

B-26 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

— Use EMU as secondary for emu/lts overlay when line has testable
pair gain. A value of "S" means send to the LTS first and overflow to
the EMU if the LTS is busy.

ENH_MTU_DET This environmental variable determines whether the Enhanced MTU Detection
function is turned on.

ENH_MTU_DET=Y turns enhanced MTU detection on.

ENH_MTU_DET=N turns enhanced MTU detection off

Default: ENH_MTU_DET=N

ENH_MTU_EXT This environmental variable determines whether the Enhanced MTU Detection
function is turned on for the BENCH, FULL, LOOP, and MET requests.

NOTE:
ENH_MTU_DET=Y is required for ENH_MTU_EXT to be functional.

ENH_MTU_EXT=Y turns on the Enhanced MTU Detection for the BENCH, FULL,
LOOP, and MET requests.

ENH_MTU_EXT=N turns off the Enhanced MTU Detection for the BENCH, FULL,
LOOP, and MET requests.

Default: ENH_MTU_EXT=N

ENH_MTU_FPOS The value of this environmental variable determines whether the Enhanced MTU
Detection feature is enabled when the original MTU detection algorithm detects
an MTU.

Valid Values
• y/Y - If the Enhanced MTU Detection algorithm is ON, a value of y/Y for the
ENH_MTU_FPOS variable enables the Enhanced MTU Detection
algorithm to run under all applicable conditions.
• n/N - If the Enhanced MTU Detection algorithm is ON, a value of n/N for the
ENH_MTU_FPOS variable disables the Enhanced MTU Detection
algorithm from running when the original MTU algorithm detects an MTU.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-27

System Administration Guide User-Definable Environmental Variables
MGRP.env

Default: y/Y

By default, if the Enhanced MTU Detection algorithm is ON, it always runs in all
applicable conditions defined by the feature and environment variables.

If this variable is not in the MGRP.env file, the default value (y/Y) is assumed.

GUI_DISPATCH This variable enables the display of the GUI dispatch recommendation messages.

Valid Values
Y or y = LoopCare displays the GUI dispatch recommendation messages.
N or n = LoopCare does not display the GUI dispatch recommendation
messages

Default: N or n

The absence of this variable is equivalent to the default value.

IGNORE_SPOTS_ The value of this environmental variable determines whether a line is tested as
COIN_SIG POTS or DLC under very specific conditions. If all the following criteria are met
and the variable is set to y/Y, the line is treated as a POTS line. If all the following
criteria are met and the variable is set to n/N, the line is treated as a DLC line. If
one or more criterion is not satisfied, the line is treated as a DLC line regardless of
the setting of this variable.
• There is either no line record or a line record that does not indicate a DLC
termination.
• The DC signature of the line matches that of a DLC COIN or SPOTS
channel unit.
• The result of the Pair Gain Bypass test returns a minor alarm condition,
specifically a bypass failure.

Valid Values:
• y/Y - Lines that meet the all the criteria described above are assumed to be
POTS and are treated as such by the test analysis process. A DC
signature that looks like a COIN or SPOTS DLC signature is treated as a
resistive fault(s).

B-28 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

• n/N - Lines that meet the all the criteria described above are assumed to be
DLC and are handled as a DLC bypass failure.
• Default: n/N

If this variable is not in the MGRP.env file, the system assumes the default value
(n/N).

INHIBIT_WIDEBA When the value of this variable is Y/y or YES/yes, the display of wideband graphs
ND_GRAPHS (BTAP, TDR, NOISE and NOISE Margin) is inhibited for FULL or LOOP.

Graphs are displayed only for the particular requests which run them (WNOISE,
TDR and BT). DC results, rate prediction; optimization still appear.

ITBM_DEFAULT_ This environmental variable provides the ability to set a default DSL type for
DSL_TYPE Nicotra via a GDF option.

Format: ITBM_DEFAULT_DSL_TYPE=’X’

Where X has the following valid values:

G, g = G.SHDSL

S, s = SDSL

L, l = ADSL Lite

P, p = No DSL Type - POTS service

A, a = ADSL

U, u = ADSL2

Default: If this variable is not set, the default value is ’ADSL.’

KEEPALIVE_OVE The DigiTest Edge BSO POTS Keep-Alive capability allows BSO test requests to
RRIDE be executed on the subscriber line without disrupting voice band POTS service.
To disable the POTS Keep-Alive capability, include

KEEPALIVE_OVERRIDE=y

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-29

System Administration Guide User-Definable Environmental Variables
MGRP.env

or

KEEPALIVE_OVERRIDE=Y

in the MGRP.env file. With the POTS Keep-Alive capability disabled, LoopCare
does not prevent the disruption of voice band POTS service when a BSO test is
executed.

Excluding this variable from the MGRP.env file or including

KEEPALIVE_OVERRIDE=n

or

KEEPALIVE_OVERRIDE=N

maintains the POTS Keep-Alive capability. In this case, you can override the
POTS Keep-Alive capability for specific test requests by checking the Disable
POTS Keep Alive check box on the BSO General Parameters screen. See the
Test Request Users Guide.

LDETMON Compulsory

Description

The Loop Detection Environmental variable controls the initial access mode when
using the LOOP DETECT feature in AnyMedia direct access mode. The default
value is no, meaning that initial access is split, LOOK-OUT. This means that Busy/
idle detection is not performed and the request will drop any conversation in
progress.

Options

The values can be entered in upper case.

• n (= no)
— LoopCare will not look for speech, busy, etc
• y (= yes)
— The initial access mode is bridged (if the channel unit allows such)
and busy/idle detection will be performed. LoopCare will check to
see if there is speech, busy, etc.

Default: no

B-30 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

LOADLIST_DELA During loop detect testing, this variable determines the number of seconds
Y LoopCare sleeps after transmitting a number of packets defined by the
LOADLIST_MULTPLIER environmental variable.

Valid values are 1 to 59 seconds.

Default: 1 second.

LOADLIST_MULT During loop detect testing, this variable determines the number of packets
IPLIER LoopCare sends before applying the delay defined by the LOADLIST_DELAY
environment variable.

Valid values are 0 to 999.

Default: 10.

LR_PRIMARY_LO Compulsory for the NSDB feature.

CATION
Description

This variable defines the primary source of the line record.

LR_SECONDARY_ Compulsory for the NSDB feature.

LOCATION
Description

This variable defines the secondary source of the line record.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-31

System Administration Guide User-Definable Environmental Variables
MGRP.env

LTS_ROHDEL_GD Sets the ROH delta for a 5ess with a GDX compensator.
X
Applies to the LTS and DCTU.

Range: 105 to 250

Default: 150

LTS_ROHDEL_NG Sets the ROH delta for a non 5ess with a GDX compensator.
DX
Applies to the LTS and DCTU.

Range: 50 to 150

Default: 70

LTS_ROH_LIMIT Sets the maximum TR short that triggers an ROH check

Applies to the LTS and DCTU.

Range: 3400 to 25000

Default: 25000

DMU_ROHDEL_G Sets the ROH delta for a 5ess with a GDX compensator.
DX
Applies to the DMU, DMU+, EDGE, and HUB.

Range: 105 to 250

Default: 150

DMU_ROHDEL_N Sets the ROH delta for a non 5ess with a GDX compensator.
GDX
Applies to the DMU, DMU+, EDGE, and HUB.

Range: 50 to 150

B-32 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

Default: 70

DMU_ROH_LIMIT Sets the maximum TR short that triggers an ROH check

Applies to the DMU, DMU+, EDGE, and HUB.

Range: 3400 to 15000

Default: 15000

MARG_BAL_THR This variable defines the threshold that separates good and marginal longitudinal
ESHOLD balance. The specified value is in dB.

Usage

MARG_BAL_THRESHOLD=X, where X is 0 or higher.

Default: 60

MARG_RES_THR This variable sets the threshold that determines whether a resistive fault is
ESHOLD considered marginal or non-fault. The specified value is in ohms.

Usage

MARG_RES_THRESHOLD=X, where X greater than 300000.

Default: 1000000

If X is 300000 or lower the default is assumed.

MAXQUALDISP This variable sets the maximum number of DSL types for which pre-qualification
results are displayed in QUALX or QQUAL results.

Usage

MAXQUALDISP=X, where X is 1 to 4.

Default: 4

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-33

System Administration Guide User-Definable Environmental Variables
MGRP.env

MaxRmuSTests This environmental variable regulates the number of simultaneous tests that can
be active on the RMU-Ss in an environment when the Batch and Loop Detect
features are activated.

For assistance with tuning this variable for your environment, contact LoopCare
Customer Support.

Default: None. The variable must be added to the MGRP.env file.

MLTSERVER Required if the customer is using the EU GUI.

The group must be brought down and up again for the new value to take effect.

Description

The MLTSERVER is the LoopCare machine's location on the Internet (expressed

either as its IP address, or as its domain name).

Option
• Internet Address of LoopCare Machine.

MLT_RMDIR Optional

The group must be brought down and up again for the new value to take effect.

Description

This variable supports Resource Monitoring. Sanity testing results will be stored
for the EMU if this environmental variable is defined located in /base/config/
MGRP.env file. If a Region contains both LTSs and EMUs, Sanity results will not
be stored for the LTSs. The Sanity file will be stored in the following format:

$MLT_RMDIR/region#/sanity/month-day-year-hour:min:sec

where:
Region # = 1-15
month = 1-12
day = 1-31
year = 4 digits

B-34 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MGRP.env

hour = 00-24
min = 00-59
sec = 00-59

Example
MLT_RMDIR=/mlt/exec/sanresults

NEWTAFFORMAT This variable determines the format and content of the TAF.STAT and
LARGE.STAT file.

Valid values
• Y/y
The DCN, MLT and PORT columns do not appear in the TAF.STAT report.
The LOOP column is large enough to accommodate a 5 digit RMU-S
sequence number.
• N/n
The DCN, MLT and PORT columns appear in the TAF.STAT report.
The LOOP column is large enough to accomodate only a 3 digit RMU-S
sequence number. If a sequence number contains more than 3 digits, ***
indicates overflow.

Default: N/n
The absence of this variable or the assignment of any other value beside
Y/y is equivalent to the default.

Set this variable to Y/y if your system has RMU-S sequence numbers containing
more than 3 digits.

NTT_RETRY This environmental variable sets the number of times the system retries NTT
access for a HUB or an EMU.

Default: 2

NODCN This environmental variable is useful in environments that do not use DCNs.

If no DCN is present, set this parameter to "YES".

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-35

System Administration Guide User-Definable Environmental Variables
MGRP.env

If DCNs are used, comment out this parameter in the MGRP.env file.

tafx The value of this environmental variable determines whether the following test
requests are logged in the TAF.STAT and LTE.STAT files: X, XCB and XTONE.

Valid Values
• y/Y - The X, XCB and XTONE test requests are logged in the TAF.STAT
and LTE.STAT files.
• n/N - The X, XCB and XTONE test requests are not logged in the
TAF.STAT and LTE.STAT files.

Default: n/N

If this variable is not in the MGRP.env file, the default value (n/N) is assumed.

U6_OVERRIDE This environmental variable allows the execution of DLC without Line Records
feature functionality even if the test request included a Central Office 'C' override,
such as C40 or C44.This capability disables the VER Codes U6 and 52. Setting
this variable to any value except null enables this functionality.

Valid Values:
• Y or any other value except null
Enables this functionality.

B-36 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
M2.env

M2.env

Introduction The following sections describe the customer-definable variable in the M2.env file
and their options.

ACTST2_VAC This variable is used to determine the voltage that is used with the ACTST2
primitive.

The valid range is 1 to 127 VRMS. If no value is specified, the default is 50.

NOTE:
It is recommended that you consult LoopCare Customer Support before
changing the value of this variable.

BTAPVAR The BTAPVAR variable provides a correction factor to compensate between

potential differences in capacitive loop length and loop length measured through
wideband test parameters (BTAP length). The value indicates the percentage
difference between the two length measurements that is required before the
correction algorithm is applied.

If the difference between the two length measurements is greater than the value
set for BTAPVAR, the capacitive loop length is used for data rate prediction and
displayed on test results.

Normally there should not be any significant difference between the two types of
length measurements. However, these options provide a conservative fallback
position from which to base calculations that depend on loop length.

The BTAPVAR variable is used in conjunction with the –B option on the tserc line
of M2.gdf. This variable is not used if the –B option for tserc is not set.

Example

If the BTAPVAR variable is set to 15, and the difference between the capacitive
and BTAP length is less than 15%, no correction is applied.

Usage

BTAPVAR=X, where X is 1-99.

Default: 25

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-37

System Administration Guide User-Definable Environmental Variables
M2.env

BTAPVAR2 The BTAPVAR2 variable determines when BTAP length adjustment is performed
in cases where BTAPs are detected. The value indicates the percentage
difference between the BTAP Loop Length and the ACTST Capacitance Loop
Length that is required before the BTAP Loop Length is replaced by the ACTST
Capacitance Loop Length.

NOTE:
This variable works properly only with TG (Tip Ground) loop lengths. If the
Loop Length Accuracy Improvement feature is enabled, TR (Tip Ring) loop
lengths may be used. If the TR loop length is used, the displayed difference
between the two loop lengths could vary significantly.

Example

If the BTAPVAR2 variable is set to 10, and the difference between the BTAP Loop
Length and the ACTST Capacitance Loop Length is greater than 10%, the ACTST
Capacitance Loop Length replaces the BTAP Loop Length.

Usage

BTAPVAR2=X, where X is 1-99.

Default: 20

COIL_ASIG_CHK This environmental variable determines whether or not the first load coil detected
as part of a load coil test is ignored if a signatured splitter is detected,

Valid Values:
• Y/y
The first load coil detected is ignored if a signatured splitter is detected.
• N/n
The first load coil detected is not ignored.

Default: Y

B-38 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
M2.env

COSETT Determines the amount of settling time in milliseconds (Amount of time it waits for
a line to settle down before it makes a test.) used for every measurement
performed by a DMU as a CO test head.

Default: 500

FDR_FAULT This variable determines whether or not the Frequency Domain Reflectometry
(FDR) fault locator test is run when an active DSL modem is detected.

Valid Values:
• N/n
The FDR fault locator test is not run.
• Y/y
The FDR fault locator test is run.

Default: N/n

HATTERAS_CPE_ The measured TR capacitance must be greater than the ground capacitance
CAP specified by this variable (in farads) in order to detect a Hatteras CPE.

Range: 0.0 to infinity

Default: 0.00000025

HATTERAS_CPE_ The measured TR DC resistance must be less than the number of ohms specified
HIGHR by this variable in order to detect a Hatteras CPE.

Range: 0.0 to infinity

Default: 6000.0

HATTERAS_CPE_ The measured TR DC resistance must be greater than the number of ohms
LOWR specified by this variable in order to detect a Hatteras CPE.

Range: 0.0 to infinity

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-39

System Administration Guide User-Definable Environmental Variables
M2.env

Default:1950.0

LC_SPLTR_PLUS This environmental variable applies to the DMU+ and HUB XMU and determines
whether or not
• A load coil test is executed even if a ADSL Maintenance Signature splitter
is detected.
• Load coil results are displayed even if a Non-signatured splitter is detected.

Valid values:
• Y
Run a load coil test if an ADSL Maintenance Signature splitter is detected
or display load coil test results if a Non-signatured splitter is detected.
• N
Do not run the load coil test or display load coil test results.

Default: N

LC_WITH_SPLTR This environmental variable determines whether are run if a signatured splitter is
detected.

Valid Values:
• Y/y
Load coil tests are run if a signatured splitter is detected.
• N/n
Load coil tests are not run if a signatured splitter is detected.

Default: Y

LIL_LEN_CHK Determines if the following condition is tested: TR loop length is greater than the
ground length by a factor of 2*qualP2 or 2*qualP1. The default values of qualP2
and qualP1 is 10%. The qualP2 value applies to terminated loops and qualP to
opens. If this condition is tested and the result is true, the LIL result is discarded.

The LIL value is logged in stat files in either case.

Valid values:

B-40 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
M2.env

• Y
The specified condition is tested and LIL results are discarded if it is true.
• N
The specified condition is not tested.

Default: N

LIL_THRU_COIL This environmental variable determines whether Loop Insertion Loss is measured
if a load coil is detected.

Valid Values:
• Y/y
Loop Insertion Loss is measured.
• N/n
Loop Insertion Loss is not measured.

Default: Y

LIL_THRU_SPLT This environmental variable determines whether Loop Insertion Loss is measured
R if a signatured splitter is detected.

Valid Values:
• Y/y
Loop Insertion Loss is measured.
• N/n
Loop Insertion Loss is not measured.

Default: Y

LIL_THRU_NS_SP This environmental variable determines whether Loop Insertion Loss is measured
LTR if a non-signatured splitter is detected.

Valid Values:
• Y/y

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-41

System Administration Guide User-Definable Environmental Variables
M2.env

Loop Insertion Loss is measured.

• N/n
Loop Insertion Loss is not measured.

Default: Y

LOSSFREQ_KHZ This is the DigiTest Edge SLQ loop attenuation (insertion loss) in dB at a
frequency in KHz. This is displayed by the LOOP(X) and FULL(X) tests. If this
option is not defined, the information is not displayed.

MIN_LOOP_CAPA This variable determines the minimum capacitance value, in units of nF, used in
CITANCE determining loop length. If the TG and RG capacitance is less than this value,
loop detect testing results in a VER LE condition This condition indicates that the
loop is too short and that alternative methods should be used to determine if the
loop has an ADSL Splitter or is connected to a Universal DLC. If this variable is
not set, the VER LE condition does not occur during loop detect testing.

MON4CT When MON4CT is set to ON, DMUs configured as CO Testheads monitor for cut-
through during NTT accesses instead of waiting a set amount of time. The
advantage of setting MON4CT to ON is that less time is required for NTT
accesses.

Default: OFF

OPEN_AC_VOLTA This variable is used to define the voltage that is used on the second ACTST
GE primitive that is run.

Default: 80v

NOTE:
It is recommended that you consult LoopCare Customer Support before
changing the value of this variable.

B-42 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
M2.env

RMSETT Determines the amount of settling time in milliseconds (Amount of time it waits for
a line to settle down before it makes a test.) used for every measurement
performed by a DMU as a remote test head.

Default: 700

SELQLIMIT_FT If the loop length as measured by capacitance is greater than SELQLIMIT_FT, the
ATTEN testcode won't be sent as part of the LOOP transaction. Rate prediction
will be based on capacitive loop length.

If the ATTEN testcode is sent and the -B option is set for tserc in M2.gdf, the loop
length as determined by the model that best fits the returned attenuation values
will be compared against the capacitive loop length. If the model length differs
from the cap loop length by more than the percentage as determined by
SELQVAR_PCT in M2.env, the model will be discarded and rate prediction will be
based on capacitive loop length.

Default: 20000

SELQVAR_PCT This variable is used in conjunction with the SELQLIMIT_FT, above.

Default: 25

UNALERT_AC_V This variable is used to define the voltage that is used on the first ACTST primitive
OLTAGE that is run.

Default: 20V

NOTE:
It is recommended that you consult LoopCare Customer Support before
changing the value of this variable.

UNALERT_COIL_ This variable is used to control source voltage of first actst run in DCOIL or LCOIL
VOLTAGE transaction

Default: 20V

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-43

System Administration Guide User-Definable Environmental Variables
M2.env

NOTE:
It is recommended that you consult LoopCare Customer Support before
changing the value of this variable.

XDSL_MODEM This variable specifies the modem (located at the subscriber’s premises) for which
LoopCare will perform data rate optimization.

Valid Values:
• CELLPIPE or cellpipe
• SPEEDTOUCH or speedtouch

The value of the XDSL_MODEM value must be compatible with the values set on
the ADSL Modem Parameters form. See Chapter 9 of the Operations,
Administration, and Maintenance Guide. The recommended settings are listed in
Chapter 1 of the Wideband Services Configuration Guide.

B-44 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
MPST.env

MPST.env

Introduction Currently there are no customer-definable variables in the MPST.env file.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-45

System Administration Guide User-Definable Environmental Variables
ISDN.env

ISDN.env

Introduction Currently there are no customer-definable variables in the IDSN.env file.

B-46 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

User-Definable Environmental Variables System Administration Guide
CGRP.env

CGRP.env

Introduction The following sections describe the customer-definable variables in the

CGRP.env file and their options.

MLT_UTL=/mlt/ubin
MLT_IDLS=/mlt/idls
CALLBACK_TIMEOUT=

NSDB Variables The environmental variables required for correct operation of the NSDB feature
must be configured in consultation with the AAI administrator. See Appendix E of
this guide for more information.

CGRP_DC_OPTS This environmental variable specifies the options passed to the

mltDataChannelSrv module on start up. This module and its options are defined
on page A-105. If this option is not specified or it is set to "", the default value is
passed to mltDataChannelSrv.

Example
CGRP_DC_OPTS="-P /mlt/config/data.properties""

Default:
"-P /mlt/config/data.properties"

Revision Q (p/n 040-0362) Release 2.15, December, 2006 B-47

System Administration Guide User-Definable Environmental Variables
CGRP.env

B-48 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

NPADEF Template C

NPADEF Template

Overview This appendix contains the NPADEF file that is referenced in the NPA Split
procedures in chapter 2 of this guide.

NPADEF.template # @(#) NPADEF revision 2.6 last mod on 05/15/95 at 14:38:32 (project dba/valid)
##############################################################################
# #
# This file contains NPA Split shell variables that are used by the #
# conversion programs. #
# #
##############################################################################

# the list of database ids on this HCFE that are converting

DBLIST=""

# variables defining split type for each database: 'T' = total, 'P' = partial
DBxx=T
DBxx=P

# the old and new NPA values

OLDNPA=xxx
NEWNPA=xxx

# the NPA Split root directory

NPAROOT="$BASE/npasplit/"

# directory where the criteria files are located

Revision Q (p/n 040-0362) Release 2.15, December, 2006 C-1

System Administration Guide NPADEF Template
NPADEF Template

INPREFIX="${NPAROOT}def/"

# directory where "sed" script files will be written

OUTSEDPREFIX="${NPAROOT}sed_scripts/"

# directory where FSVAL script files will be written

OUTVALPREFIX="${NPAROOT}fsval_scripts/"

# directory where FSVAL shells will be written

OUTSHELLPREFIX="${NPAROOT}shells/"

# loadutil input file

LOADINPUT="${NPAROOT}loadutil/NPASPLIT"

# input files, one per database, suffixed with ".<DBID>"

WCS=${INPREFIX}wcs
NNXS=${INPREFIX}nnxs
EXKS=${INPREFIX}exks
UNITS=${INPREFIX}units

# global input files, one per machine

GLOBALWCS=${INPREFIX}wcs.global
GLOBALEXKS=${INPREFIX}exks.global
GLOBALNNXS=${INPREFIX}nnxs.global

# maximum size of "sed" script files

SPLITSIZE=70

# output files containing "sed" scripts

AAMSTR=${OUTSEDPREFIX}aamstr
AADIST=${OUTSEDPREFIX}aadist
ALARM=${OUTSEDPREFIX}alarm
SUPV=${OUTSEDPREFIX}supv
CRAFT=${OUTSEDPREFIX}craft
TRKMC=${OUTSEDPREFIX}trkmc
SWMOR=${OUTSEDPREFIX}swmor
PDI=${OUTSEDPREFIX}pdi
PST=${OUTSEDPREFIX}pst
NNXF=${OUTSEDPREFIX}nnxf
DEFEXK=${OUTSEDPREFIX}defexk
MLTACC=${OUTSEDPREFIX}mltacc
CMUACC=${OUTSEDPREFIX}cmuacc
WC2FTN=${OUTSEDPREFIX}wc2ftn
WC2XTC=${OUTSEDPREFIX}wc2xtc
CMU=${OUTSEDPREFIX}cmu
LTS=${OUTSEDPREFIX}lts
LU1NM=${OUTSEDPREFIX}lu1nm
ALPHAID=${OUTSEDPREFIX}alphaid
NPAWC=${OUTSEDPREFIX}npawc
NPANNX=${OUTSEDPREFIX}npannx
GNNXT=${OUTSEDPREFIX}gnnxt

# output files containing FSVAL scripts; will be suffixed with ".<DBID>"

ALMAPAUDIT=${OUTVALPREFIX}almapaud
ALMAPEDIT=${OUTVALPREFIX}almaped
LRFAUDIT=${OUTVALPREFIX}lrfaud
LRFEDIT=${OUTVALPREFIX}lrfed

C-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

NPADEF Template System Administration Guide
NPADEF Template

SECIDAUDIT=${OUTVALPREFIX}secidaud
SECIDEDIT=${OUTVALPREFIX}secided
SSDAUDIT=${OUTVALPREFIX}ssdaud
SSDEDIT=${OUTVALPREFIX}ssded
TPFAUDIT=${OUTVALPREFIX}tpfaud
TPFEDIT=${OUTVALPREFIX}tpfed
UTFAUDIT=${OUTVALPREFIX}utfaud
UTFEDIT=${OUTVALPREFIX}utfed
DPAAUDIT=${OUTVALPREFIX}dpaaudit
DPAEDIT=${OUTVALPREFIX}dpaedit
TNDAUDIT=${OUTVALPREFIX}tndaudit
TNDEDIT=${OUTVALPREFIX}tndedit
ALIASAUDIT=${OUTVALPREFIX}aliasaudit
ALIASEDIT=${OUTVALPREFIX}aliasedit

# output files containing FSVAL shells; will be suffixed with ".<DBID>"

ALMAP=${OUTSHELLPREFIX}fsval.almap
LRF=${OUTSHELLPREFIX}fsval.lrf
SECID=${OUTSHELLPREFIX}fsval.secid
SSD=${OUTSHELLPREFIX}fsval.ssd
TPF=${OUTSHELLPREFIX}fsval.tpf
UTF=${OUTSHELLPREFIX}fsval.utf
DPAPREP=${OUTSHELLPREFIX}fsval.dprep
DPAD=${OUTSHELLPREFIX}fsval.dpad
TND=${OUTSHELLPREFIX}fsval.tnd
ALIAS=${OUTSHELLPREFIX}fsval.alias

# master conversion shell; will be suffixed with ".<DBID>"

RUNSHELL=${OUTSHELLPREFIX}convert

# MLT3 related env variables

AICTBL=/mlt/mlttables/adef/ictables
AMLTTBL=/mlt/mlttables/adef/mlttables
ICTBL=/mlt/ictables
MLTTBL=/mlt/mlttables
SEDDIR="${NPAROOT}sed_scripts"

##############################################################################
#
# #
# End of NPA Split shell variable definitions. #
# #
##############################################################################

Revision Q (p/n 040-0362) Release 2.15, December, 2006 C-3

System Administration Guide NPADEF Template
NPADEF Template

C-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Setting Up Printers D

Introduction

Overview This appendix describes the step-by-step procedure for adding line printers to the
LoopCare configuration. Once the printer has been set-up, it will accept normal
LoopCare print outputs (for example, from TV) or can be used to print manually
directed printouts.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 D-1

System Administration Guide Setting Up Printers
Required Software Changes for Adding a Printer

Required Software Changes for Adding a

Printer

Overview In order to print LoopCare reports, it is necessary to iidentify the new line printer in
the BASE and LoopCare software. The following procedure steps you through all
of the necessary changes to the relevant software files.

In order to set-up a new line printer in the LoopCare configuration, both hardware
and software changes must be made. To set-up hardware options for specific
types of printers, see the manufacturer's documentation.

The required software changes for BASE and LoopCare, described in this
document, will be the same for any printer that is added to the LoopCare Perform
the following procedure to identify the printer to BASE and LoopCare.

NOTE:
The following procedure is required for all LoopCare servers.

1. Add a new printer line to /base/ictables/gplt.src. You must first

su - base
Use the vi editor to add a new line for the printer you are adding. Example:

pn ln dev lm
-- -- --- --
2010 1 1 01

Example for non-ANS mode:

pn ln dev lm
-- -- --- --
A001 103 103 97

By entering a line number from 99 < ln < 128, a device number from 99 <
dev < 128, you can redirect the printer output to the screen, a file, or a
network (TCP/IP) printer (instead of sending the output to an ANS printer).
For detailed information on the .src file field entries, see 451.gplt.

NOTE:
Steps 2-3 are required for HP11i LoopCareservers.

2. Add a new printer line to /base/ictables/send.src.

D-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Setting Up Printers System Administration Guide
Required Software Changes for Adding a Printer

Use the vi editor to add a new line for the printer you are adding. using the
printer number that was entered in gplt.src.
Sample entry for sending to a printer
prt option
2010 cat $1 > lp -dchina -c>/dev/null 2>&1
If using the non-ANS printing options as described in step 1 above, refer to
the following examples:
Sample entry for printing to a file:
prt option
A001 cat $1 > /tmp/printerOutputFile
Sample entry for routing the printer output through some process and then
to a real printer:
prt option
A002 cat $1 | postprint | lp -dmltmac -c >/dev/null 2>&1
Sample entry for sending the output to a terminal screen, assuming the tty
port ID for the terminal is /dev/dk0496x:
prt option
A003 cat $1 > >>/dev/dk0496x
3. Add the following line to the BASE.gdf file located in /base/config.
F:$BASE/bin/Daemon -d DAE.

NOTE:
The following steps are required for all LoopCare servers.

4. When you have added the new lines to gplt.src and send.src, the files must
be compiled and loaded via RTSadmin. Use the following commands to do
this:
RTSCOMPILE gplt.src
RTSCOMPILE send.src
RTSLOAD gplt.src
RTSLOAD send.src

The installation is complete and the printer is ready for use.

See the NCR 6417 Printer Setup Guide for detailed instructions for putting the
printer on-line and preparing it to receive output.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 D-3

System Administration Guide Setting Up Printers
Required Software Changes for Adding a Printer

Setting Up the Introduction

Printer Daemon
The Printer Daemon allows information to be sent to the printer by means of an
LoopCare transaction without ANS being part of the environment.

The daemon can be set up to print to the screen, to a file, or routed to a printer if a
path is available. This section describes user set up needed to run the tool.

The $BASE/bin/Daemon is used for HP11i servers whereas the Daemlt module is
used for HP10.20 and SUN servers.

Procedure

Files and Modules

The following files and modules need to be set up for the Printer Daemon:

File Description
Daemlt Usually stored in /mlt/bin, this is the main printer
daemon code.This module replaces /base/bin/Daemon
and must be entered in the BASE.gdf file.
PRINTERS Usually stored in /mlt/exec, this is the file that maps the
specific action to be taken with an output file per printer
Output File Usually specified in the PRINTERS file, this is selected
and set up in the directory of choice by the user.

Set Up

Follow the steps below to configure the system to use the Printer Daemon.
1. Move the module Daemlt into the /mlt/bin directory. See the directions
above about locating a proper Daemlt module either from the appropriate
machine.

MODULE LOC PERM OWNER GROUP

Daemlt /mlt/bin 777 mlt baseadm

2. Create a file PRINTERS in the /mlt/exec directory. Make the permissions

666.
3. Edit the BASE.gdf file located in /base/config.
• Comment out the following line if it exists:
F:$BASE/bin/Daemon -d DAE
• Replace it with the following line:

D-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Setting Up Printers System Administration Guide
Required Software Changes for Adding a Printer

F:/mlt/bin/Daemlt dummy DAE

4. Check the file gplt.src in /base/ictables. This file lists the valid printer
names, their line and device, and the associated LM id. Select a printer or
printers from the list and record the associated LM id.
An example of the gplt.src table is shown below:

Printer Name Line ID Device Id Logical Machine

A002 2 3 73
Z003 7 7 07
-
-
-
W020 20 20 86

To select the printer ID of Z003 as the entry for your TV and SAM mask
outputs, then the LMID of 07 is what you want to record. This same
information will be used later when editing the PRINTERS file.
5. Go to the /mlt/exec directory and edit the file PRINTERS. Enter the
following data for the printer(s) you want to use:
[LMID of printer] cat XX >> [action to take]
Where LMID is the value you recorded from the gplt.src file.
cat XX is the command that cats the ascii output
located in the file XX.

NOTE:
XX is a variable name that the system will substitute with the real file name
at the time of execution.

>> will take the cat output and append it to the file or printout you specify in
the action to take part of the message. You can also use | (the pipe
symbol) to pipe output though some processes.

The action to take can be any string or command that you can put together
to route the output. For example it could be to a terminal window. It could
be to a file, or to some other commands that will format or forward the ascii
output to say another printer.

An example of a line entry in the PRINTERS file looks like this:

Revision Q (p/n 040-0362) Release 2.15, December, 2006 D-5

System Administration Guide Setting Up Printers
Required Software Changes for Adding a Printer

07 cat XX >> /mlt/exec/pitch/PRINT.OUT

This line would be invoked on a printer that has an LMID of 07 (remember
Z003 had an LMID of 07). It would cat the ascii output and append it to the
PRINT.OUT file in:
/mlt/exec/pitch

An example of using the action section to route the output through some
processes and then to a real printer somewhere is shown in the example
below:

07 cat XX | postprint | lp -dmltmac -c > /dev/null 2>&1

Sending the output to a terminal screen requires the tty of that terminal
screen. This can be done by running the tty command from the prompt and
recording the returned tty value. Take this value and use it in the action to
be take section.

If the tty port ID, for example, is /dev/dk0496x, then the line in PRINTERS
to send this to a terminal screen would be:

07 cat XX >> /dev/dk0496x

However, remember that when you send to a terminal screen the tty can
change every time you logon or open a window. So if you intend to send
information to a screen you always have to make sure the tty is correct in
the PRINTERS file or your output may be going to someone else's screen.
6. To make the above entries take effect you must bounce BASE.
The PRINTERS file MUST exist before Daemlt is running. You cannot have
Daemlt running and then create the PRINTERS file and have it work. This
is because Daemlt must be able recognize the existence of the PRINTERS
file at initialization. If you create a PRINTERS file while Daemlt is running,
then Daemlt will not recognize PRINTERS and you will not receive any
printouts.

Either BASE (specifically Daemlt) has to be down when you create

PRINTERS in which case it will recognize PRINTERS when it starts up- or
if BASE (specifically Daemlt) is running when you create PRINTERS then
you must bounce BASE for Daemlt to recognize the PRINTERS file. Once
Daemlt has recognized the PRINTERS file on initialization (Daemlt is
running) then you can make new entries to PRINTERS file and have them
take effect immediately. You DO NOT have to bounce BASE again to have
these changes take effect.

D-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA APIE

Introduction

Overview This appendix describes the procedures you must perform if you have the
CORBA Test Requester API and Data Requester API features enabled for your
environment.

Before You Begin To perform these procedures, you must be logged in as mlt. To modify the files,
use a text editor such as vi.

Have the following document available: The Administration Guide for Telcordia
Advanced Application Interface, available from Telcordia Technologies.

To complete the changes to the CGRP.env file, you will need the assistance of the
AAI System Administrator.

List of Procedures The following table lists the procedures that apply to each CORBA API feature.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-1

System Administration Guide Additional Procedures for CORBA API
Introduction

API Procedure and Page

Test Requester Verify Test Requester API Features: page E-3
Configure IOR Files Without Headers: page E-4
Data Requester Modify the MGRP.env File: page E-12
For interfacing with the
Modify the CGRP.env File: page E-13
Telcordia
Technologies Network Verify Data Requester API Features: page E-15
Systems Database
(NSDB) application
only.

E-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA API System Administration Guide
Verify Test Requester API Features

Verify Test Requester API Features

Overview Verify that the following entries exist in the mlt.feature file:

API_TESTREQ CORBA API Test Request

TRTDIL TDIL TestRequester Slice
TRITDIL TDIL TestRequester Slice
(Interactive)

If one or more of these entries are missing, contact your LoopCare Customer
Support person.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-3

System Administration Guide Additional Procedures for CORBA API
Configure IOR Files Without Headers

Configure IOR Files Without Headers

Overview The LoopCare default is to generate IOR files with a header. This procedure is
required only if you are using a version of the Telcordia Technologies Work Force
Administration (WFA) applicaation which requires that IOR files not have a
header.

To generate IOR files for Test Requester without a header, add the -z option to the
specified lines in the following files.

MGRP.gdf

$MLT_BIN/corbaGWS -t,3,-s,corbaGWSsrv.-p,cGWB,-z cGWS

cgrpinit

nohup $MLT_BIN/mltDataChannelSrv -t250 -z>>$MLT_TRC/

dcStart.trc 2>&1&

dChanSrv_sh

nohup $MLT_BIN/mltDataChannelSrv -t250 -z>>$MLT_TRC/

dcStart.trc 2>&1&

E-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA API System Administration Guide
Configure Servers for Fixed TCP Ports

Configure Servers for Fixed TCP Ports

Introduction For LoopCare systems that use Visibroker as the CORBA ORB (hp11i and Sun),
an additional configuration option is available in order to specify a particular TCP
port number for each LoopCare API server. If this configuration option is not
specified, the TCP port is selected by the ORB and is random. Specifying a
particular TCP port is helpful in installations that require configuring firewalls.

Configuration In the /mlt/mlttables directory, there are two additional text files, dcf.properties and
gws.properties. These files are copies of the Visibroker properties template file.
They allow the user to configure various options in the CORBA servers.

By default, both files will have all the various options commented out with the
exceptions dealing with the TCP port. Operating environments can designate an
appropriate TCP port but the recommended changes already are made in these
files. All other options in the file are commented out and do not affect the server
installation.

For the "gws.properties" file, the following options are enabled and can be re-
configured as necessary.
• Port number that is used with the host name property. 0 means the
system will pick a random port number.
vbroker.se.iiop_tp.scm.iiop_tp.listener.port=14005
• Proxy port number that is used with the proxy host name property. 0
means the system will pick a random port number.
vbroker.se.iiop_tp.scm.iiop_tp.listener.proxyPort=0

For the "data.properties" file, the following options are enabled and can be re-
configured as necessary.
• Port number that is used with the host name property. 0 means the
system will pick a random port number.
vbroker.se.iiop_tp.scm.iiop_tp.listener.port=14007
• Proxy port number that is used with the proxy host name property. 0
means the system will pick a random port number.
vbroker.se.iiop_tp.scm.iiop_tp.listener.proxyPort=0

In the selected options outlined above in the "gws.properties" file, the listener.port
is used to specify the desired TCP port which in this case the port is 14005. If the
value is 0 then the TCP port is selected by the ORB and is random. Similarly, the
selected options outlined above in the "data.properties" file, the listener.port is

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-5

System Administration Guide Additional Procedures for CORBA API
Configure Servers for Fixed TCP Ports

used to specify the desired TCP port which in this case the port is 14007. If the
value is 0 then the TCP port is selected by the ORB and is random. The TCP port
must differ between the settings in the "gws.properties" and "data.properties".

To use the properties file, there are configuration changes required to the
LoopCare system. There is an additional command line option (-P) for
mltDataChannelSrv and corbaGWS modules (processes). The "corbaGWS"
process is the CORBA server that receives test requests from the client. The
"mltDataChannelSrv" process is the CORBA server that supports data channels.
The client requests the creation and deletion of data channels and pulls (retrieves)
test responses from this server. If the client is using call back to obtain test results
then the data channel server is not used.

The "corbaGWS" process can be found in CGRP.gdf file. Because upgrades of

the LoopCare system will re-install these property files, it is recommended that a
copy of these files be made to designated area. As for the "mltDataChannelSrv"
process, it is started through the CGRP application layer when the "cgrpinit" script
is launched. Configuration changes for these processes to use a locally
designated properties file is accomplished with the following procedure:
1. Login as "mlt"
2. Copy property files:
cp /mlt/config/gws.properties /mlt/mlttables/gws.properties
cp /mlt/config/data.properties /mlt/mlttables/data.properties
3. Set permissions for property files:
chmod 664 /mlt/mlttables/gws.properties
chmod 664 /mlt/mlttables/data.properties
4. Reference the property file in the CGRP.gdf file:
cd /base/config
Edit /base/config/CGRP.gdf in order to make the following change:
$MLT_BIN/corbaGWS -t,3,-s,corbaGWSsrv,-p,cGWB,-P,/mlt/
mlttables/gws.properties cGWS
5. Reference the property file in the cgrpinit file:
cd /mlt/ubin
Edit /mlt/ubin/cgrpinit in order to make the following change:
nohup $MLT_BIN/mltDataChannelSrv -t 250 -P /mlt/mlttables/
data.properties >>$MLT_TRC/dcStart.trc 2>&1 &

If the option is absent in either the of the above configuration files, then the TCP
port is selected by the ORB and is random for that process.

E-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA API System Administration Guide
Configure Servers for Fixed IP Address or Host Name

Configure Servers for Fixed IP Address

or Host Name

Introduction For LoopCare systems that use Visibroker as the CORBA ORB, HP11i and Sun,
an additional configuration option is available for specifying a particular IP
address or host name for each LoopCare API server. If you do not use this
configuration option, the ORB selects the IP address of the first network interface
displayed by the ifconfig -a UNIX command. Usually, this default configuration is
sufficient. However, if there are two or more network interfaces or if it is preferable
that the host name appear in the IOR rather than the IP address, you can use the
configuration option described below in conjunction with the configuration of the
fixed TCP port.

Configuration Two text files in the /mlt/config directory, data.properties and gws.properties, are
copies of the Visibroker properties template file. These files enable you to
configure various options for the CORBA servers.

By default, all the options in these files are commented out with the exception of
those entries for configuring the TCP port.

In the gws.properties file, uncomment the following option and set it to the
desired value.
vbroker.se.iiop_tp.scm.iiop_tp.host=<IP address>
or
vbroker.se.iiop_tp.scm.iiop_tp.host=<host name>

For example,
vbroker.se.iiop_tp.scm.iiop_tp.host=10.2.12.202
or
vbroker.se.iiop_tp.scm.iiop_tp.host=myServerName

In the data.properties file, uncomment the following option and set it to the
desired value.
vbroker.se.iiop_tp.scm.iiop_tp.host=<IP address>
or
vbroker.se.iiop_tp.scm.iiop_tp.host=<host name>

For example,
vbroker.se.iiop_tp.scm.iiop_tp.host=10.2.12.202
or

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-7

System Administration Guide Additional Procedures for CORBA API
Configure Servers for Fixed IP Address or Host Name

vbroker.se.iiop_tp.scm.iiop_tp.host=myServerName

If the value of this option is null, the system uses the default IP address. If host
name is specified, the CORBA API client must be configured to map the host
name to the correct IP address. For example, on UNIX, this mapping can be
specified in the /etc/hosts file.

The instructions on using the properties files are located at the end of Configure
Servers for Fixed TCP Ports: page E-5.

Environmental Include the following CPRG.env variable. See Appendix B of this guide for a
Variable description of this environmental variable.
CGRP_DC_OPTS="-P /mlt/mlttables/data.properties"
export CGRP_DC_OPTS

E-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA API System Administration Guide
IOR Reference Files

IOR Reference Files

Upon successful start of the CGRP, there are several IOR reference files
generated under /mlt/mlttables.
pwd
/mlt/mlttables

ls -tl *ref
-rw-rw-r-- 1 mlt baseadm 581 Aug 29 15:26 mlt.ref
-rw-rw-rw- 1 base baseadm 589 Aug 29 15:26 session.ref
-rw-rw-r-- 1 mlt baseadm 656 Aug 29 15:26 dcf.ref

In the event that the contents of these files need to be decoded for the purposes
of troubleshooting CORBA issues, the following command can be executed, for
example:
. /opt/BDP/bin/vbroker.sh

NOTE:
If the "-z" option is not used in the configuration of the CGRP.gdf and the
cgrpinit files modified in the procedures above, there is header information
generated in the IOR reference files provided above. Copies of these IOR
reference files will need to be made with the header information removed
so that only the IOR information is specified. In other words, the following
needs to be remove from the mlt.ref file: MtestRequestObj=. As for the
dcf.ref file the following needs to be removed: DataChannelFactory=

Afterwards, the printIOR utility can properly parse the file and provide the
following indication for the ports used:
/opt/BDP/bin/printIOR /mlt/mlttables/mlt.ref |grep -i port
port: 14007
/opt/BDP/bin/printIOR /mlt/mlttables/dcf.ref |grep -i port
port: 14005

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-9

System Administration Guide Additional Procedures for CORBA API
Visibroker Variables

Visibroker Variables

The following variables required by the Visibroker software for HP11i and Sun
Solaris are defined in the CGRP.env file. It is necessary to modify these variables
only if you use different directories, etc.
#Visibroker Administration Path
VBROKER_ADM=/opt/BDP/var/vbroker/adm
export VBROKER_ADM

#Visibroker Enterprise License Path

BES_LIC_DIR=/opt/BDP/var
export BES_LIC_DIR

#Visibroker Enterprise Tracing for License

# to check possible license problems turn on tracing (uncomment)
#BES_LIC_TRACE=100
#export BES_LIC_TRACE

#Visibroker Enterprise License Directory

BES_LIC_DEFAULT_DIR=/opt/BDP/license
export BES_LIC_DEFAULT_DIR

#Visibroker Enterprise OSAGENT Port

OSAGENT_PORT=14000
export OSAGENT_PORT

#Visibroker Enterprise Parent Directory

VBROKERDIR=/opt/BDP
export VBROKERDIR

#Visibroker Enterprise Executables should be included in PATH

# the apache2 paths are used only by the Borland Enterprise Server
# complete install
PATH=/opt/BDP/bin:/opt/java1.3/bin:/opt/BDP/bin/apache2:${PATH}
export PATH

#Visibroker Enterprise Shared Library Should be included in Library Path

E-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA API System Administration Guide
Visibroker Variables

#either LD_LIBRARY_PATH or SHLIB_PATH (depends on hp11i or Sun

Solaris)
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/BDP/lib
export LD_LIBRARY_PATH

SHLIB_PATH=$SHLIB_PATH:/opt/BDP/lib
export SHLIB_PATH

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-11

System Administration Guide Additional Procedures for CORBA API
Modify the MGRP.env File

Modify the MGRP.env File

Procedure Use the following procedure to define the primary source of the line record in the
MGRP.env file.
1. At the system prompt, type the following command:
cd /base/config
2. Add the following entries to the MGRP.env file:
LR_PRIMARY_LOCATION=NSDB
LR_SECONDARY_LOCATION=

E-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA API System Administration Guide
Modify the CGRP.env File

Modify the CGRP.env File

What You Need To perform this procedure you need the following:
• The Administration Guide for Telcordia Advanced Application Interface,
available from Telcordia Technologies.
• Assistance from the AAI System Administrator to determine the values of
the following fields in the AAI configuration file (or the JCL file):
— NSDB_STOREID
— RACF
— AAPI User ID
— PASSWORD
— USERGROUP

Table 5-1. Impact of the RACF Field on the CGRP.env file

If the value of the RACF field
is then
I Only the NSDB_USERID field is required
N Values in the following fields in the CGRP.env file are not
required:
Y Values in the following fields in the CGRP.env file are
required:
NSDB_USERID
NSDB_PASSWORD
NSDB_USERGROUP

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-13

System Administration Guide Additional Procedures for CORBA API
Modify the CGRP.env File

Procedure Add the following entries to the CGRP.env file:

Entry Notes
NSDB_STORED= The value of this field is based on the value of the
NSDB_STOREID field in the AAI configuration file.
Example:
If the ID is PT, then
NSDB_STOREID=NSDBPT
NSDB_CLIENTNAME
=LoopCare
NSDB_USERID= See the information about the value of the RACF field in
Table 5-1.
If entered, the value of this field must match the AAPI
User ID.
NSDB_PASSWORD= See the information about the value of the RACF field in
Table 5-1.
If you enter a value in this field, obtain the value of this
field from the AAI Administrator.
NSDB_USERGROUP See the information about the value of the RACF field in
Table 5-1.
If you enter a value in this field, obtain the value of this
field from the AAI Administrator.
NSDB_DEBUG To Enter
Generate an NSDB trace file 1
Generate full debugging and a buffer file 127
Turn off the NSDB tracing and debugging 0
data

E-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for CORBA API System Administration Guide
Verify Data Requester API Features

Verify Data Requester API Features

Overview Verify that the following entries exist in the mlt.feature file:

DRAPI Data Requester API

If one or more of these entries are missing, contact your LoopCare Customer
Support person.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 E-15

System Administration Guide Additional Procedures for CORBA API
Administering Multiple NSDBs

Administering Multiple NSDBs

Introduction This section describes the procedures needed to administer multiple NSDB
servers.

LoopCare and AAI LoopCare communicates with NSDB via the Telcordia AAI CORBA interface. The
Functions LoopCare administrator must therefore coordinate with the AAI administrator to
ensure that LoopCare queries to an NSDB server for line records are routed
correctly.

Information to The LoopCare administrator must coordinate the following information with the
Coordinate AAI administraotr.
• What NSDB(s) LoopCare needs to communicate with

NOTE:
A LoopCare environment is able to commuicate with up to 10 NSDB
servers.

• What AAIs are connected to those NSDB(s)

• What are the DSID's that LoopCare needs to specify in the
ALANSdatastoreID field
• What LoopCare boxes need to get the necessary data
• The AAI Admin will probably set up automated jobs to "PUT" the
appropriate IORs to the appropriate LoopCare boxes
• The LoopCare Admin has to set up reference data needed for LoopCare to
use the correct IOR and DSID

E-16 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The Customer Environment Screen F

Introduction

Overview This appendix describes the purpose and use of the Customer Environment
screen.

! CAUTION:
Changes made on the Customer Environment screens impact the behavior
of all aspects of LoopCare including the accuracy of test results. Some of
the changes will modify End-User GUI displays and may require re-training
of end-users. Consult with LoopCare Customer Support before making any
changes.

Purpose The Customer Environment screen allows you to set environment variables that
control the type of data values and labels displayed on the user test-result
interface. The type of display will be either standard North American or
international. The variables include distance measurements, label notation (for
conductors, ground, and gauge), Telephone number format, and language. This
mainly impacts information in detailed results and distance values that appears in
summary messages.

This screen is only part of the tools required to setup a uniform display format that
conforms to specific user display requirements. The other elements include
bflx.tbl files and errnum files.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 F-1

System Administration Guide The Customer Environment Screen
Introduction

F-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The Customer Environment Screen System Administration Guide
Usage

Usage

Overview This section explains how to use the Customer Environment Screen.

Screen Navigation Navigation and selection of values on the Customer Environment screen is the
same as on the ADEF screens. See Chapter 2 of the Operations, Administration,
and Maintenance (OA&M) Guide for Administrators.

Access To access the Customer Environment screen, you must be logged in as mlt.
1. At the system prompt, type the following command:
custenv <Enter>
The Customer Environment screen is displayed.

Figure 6-1. Customer Environment Page

2. Complete the fields on the screen. Refer to Table 6-1.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 F-3

System Administration Guide The Customer Environment Screen
Usage

3. When you have completed entering data, press the <F6> button to access
the command buttons at the bottom of the screen.
4. Select one of the following buttons:
— Save - Save your changes but do not leave the screen.
— Default - Clear any unsaved changes on the screen and display the
current system default values.
— Cancel - Exit the screen without saving any changes since the last
save.
— Quit - Exit the screen without saving any changes since the last
save. You will be prompted whether to save any unsaved changes.
5. To enter additional data, press the <F10> key.
The Navigation Menu is displayed.

Figure 6-2. Customer Environment Page Navigation Menu

6. Select the Additional Custenv Info option.

The additional Customer Environment page is displayed. See Figure 6-3
on page F-9.

Screen Fields Table 6-1 lists and describes the fields on the Customer Environment page.

Table 6-1. Customer Environment Page Fields and Descriptions

Field Values Effect on Displays and Reports

Length Unit Imperial Lengths will be displayed in feet in
detailed results.
See the note
after this table. Metric Lengths will be displayed in meters in
detailed results.
Calculations will be performed in feet
and then converted to meters.

F-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The Customer Environment Screen System Administration Guide
Usage

Table 6-1. Customer Environment Page Fields and Descriptions

Field Values Effect on Displays and Reports

Harris Length Imperial See Impact of Length Unit and Harris
Unit Length Unit Values: page F-7
Metric
Cable Gauge American AWG Cable Gauge will be designated in
Notation American Wire Gauge: for example, 24
GA and 26 GA.
Metric MWG Cable Gauge will be designated in
Metric Wire Gauge: for example, 0.5
mm and 0.4 mm.
Ground Enter the number of When the capacitance used for
Capacitance / μF/nF to be used for calculating loop length is the T-G/R-G
Length the unit length. capacitance, the "Ground Capacitance
The label after the / Length" is be used to calculate the
numeric value loop length. This applies to everywhere
varies depending on this calculation is done in LoopCare.
the type of length
unit selected in the
first field:
(μF/Miles) for
Imperial
(nF/KMs) for Metric
The default for
Imperial is .083 μF/
Miles
The default for
Metric is 51.6 nF/
KMs

Revision Q (p/n 040-0362) Release 2.15, December, 2006 F-5

System Administration Guide The Customer Environment Screen
Usage

Table 6-1. Customer Environment Page Fields and Descriptions

Field Values Effect on Displays and Reports

T-R Capacitance Enter the number of When the capacitance used for
/ Length μF/nF to be used for calculating loop length is the T-R
the unit length. capacitance, the "T-R Capacitance /
The label after the Length" isl be used to calculate the
numeric value loop length. This applies to everywhere
varies depending on this calculation is done in LoopCare.
the type of length
unit selected in the
first field:
(μF/Miles) for
Imperial
(nF/KMs) for Metric
The default for
Imperial is .083 μF/
Miles
The default for
Metric is 51.6 nF/
KMs
If Cable Gauge
Notaion is Metric
MWG, "T-R" is
changed to "A-B".
TN Format North American Telephone Numbers will be displayed
in NPA/NXX/LLLL format.
Non-North Telephone Numbers will be displayed
American as one field according to local format,
which is handled by the software
specific to the local environment.
Default The list of supported Determines the language used for
Language languages is display elements.
release-specific.
DCN Display Checkbox A check causes DCN ID to appear as a
key field on the RTU form along with
the THID field.
Variant User-created Displays user-defined messages
supplement to instead of defaults.
language facilities.
For the use of this parameter, consult
your LoopCare Customer Support
representative.

F-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The Customer Environment Screen System Administration Guide
Usage

NOTE:
If the value selected for the Length Unit is Metric, then verify that the
following line is present in the MGRP.gdf file

I:$MLT_UTL/dumpenv $MLTENV dmpenv

If this line must be added to the MGRP.gdf file, you must bounce MGRP.
For further details, see the User Interface Program (UIP) Guide.

NOTE:
If the value selected for the Length Unit is Metric and IVR is deployed, set
the MetricFlag registry to 1.

NOTE:
Always rerun trunk calibraction after cahnging the T-R capacitance on the
custenv form. QUAL is the only request that computes loop length from T-R
capacitance.

Impact of Length The Harris test unit has its own display variable for measurement values. This is
Unit and Harris the METRIC variable found in the SYS table. When METRIC is set to NO, the test
Length Unit Values unit presents values to LoopCare in standard Imperial measures (feet, μF/Mile,
etc.). When METRIC is set to YES, the test unit presents values to LoopCare in
metric format (meters, μF/KM, etc.). LoopCare must know which mode the Harris
test unit is using to present values so that LoopCare can make the appropriate
conversions.

Examples

System-Wide
Length Unit Harris Length Unit Results
Imperial Imperial Harris test results used as-
is by LoopCare; displayed
as feet.
Imperial Metric Harris test results
converted to Imperial
before performing
calculations; displayed as
feet.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 F-7

System Administration Guide The Customer Environment Screen
Usage

System-Wide
Length Unit Harris Length Unit Results
Metric Metric Harris test results
converted to Imperial
before performing
calculations; then
displayed as meters.
Metric Imperial Harris test results used as-
is for performing
calculations; and then
converted to Metric before
being displayed.

F-8 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The Customer Environment Screen System Administration Guide
Additional Customer Information Page

Additional Customer Information Page

Introduction The additional Customer Environment page allows you to configure additional
environment variables.

This page is accessed from the Navigation Menu on the Customer Environment
page.

Figure 6-3. Additional Customer Environment Page

1. Complete the fields on the screen. Refer to Table 6-2.

2. When you have completed entering data, press the <F6> button to access
the command buttons at the bottom of the screen.
3. Select one of the following buttons:
— Save - Save your changes but do not leave the screen.
— Default - Clear any unsaved changes on the screen and display the
current system default values.
— Cancel - Exit the screen without saving any changes since the last
save.
— Quit - Exit the screen without saving any changes since the last
save. You will be prompted whether to save any unsaved changes.
The Customer Environment page is displayed.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 F-9

System Administration Guide The Customer Environment Screen
Additional Customer Information Page

Screen Fields Table 6-2 lists and describes the fields on the additional Customer Environment
page.

Table 6-2. Customer Environment Page Fields and Descriptions

Field Values Effect on Displays and Reports

Line Records Determines whether If the Yes option is selected, LoopCare
the tip module attempts to find a line record prior to
sends for line record running the test request.
information.
If the No option is selected, LoopCare
does not attempt to find a line record.
Likewise, the message TESTED
WITHOUT LINE RECORDS is not
displayed with test results.
Metallic Results • MLT Classic MLT Classic indicates that Metallic
Heading Test Results areas are to be labeled as
• LoopCare
follows:
Modern
• Craft: DC Signature
• DC Signature
• AC Signature
LoopCare Modern indicates that these
Metallic Test Results areas are to be
labeled as follows:
• 2-Term DC Model
• 3-Term DC Model
• 3-Term AC Model
Display AC • Yes • Yes indicates that AC
Capacitance Capacative Data is to be
• No
Data displayed in the Test Results on
the GUI.
• No indicates that AC Capacative
Data is not to be displayed in the
Test Results on the GUI.

F-10 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The Customer Environment Screen System Administration Guide
Additional Customer Information Page

Table 6-2. Customer Environment Page Fields and Descriptions

Field Values Effect on Displays and Reports

DC Signature • On • "On" indicates that the raw data
Raw Data returned by a Stinger "CLT/CLT-
• Off
EX only is to to be displayed on
the user GUI, removing the limits
on the displayed data for DC
Signature, AC Signature, and
Longitudinal Balance data.
The User Gui displays 2 decimal
places for voltage values.
The CLT and CLT-EX return
"999999999" for resistance
values greater than 5000 Kohms
to indicate an over range
condition. When the resistance
value returned from the CLT or
CLT-EX is "999999999", the
string ">5000" is displayed on
the GUI.
When the CLT or CLT-EX is
returning real numbers, the Craft
Signature (2-Term DC
Signature) is calculated using
those numbers without any limits
applied. When the CLT or CLT-
EX returns "999999999", 5000
KOhms is used to do the
calculations.
• "Off" causes DC resistances
above 3500 KOhms to be
displayed as ">3500" or "3500"
and voltages below 1 volt to be
displayed as 0 volts.
Default: Off.
Setting the DC Signature Raw Data to
"ON" has no effect on tests that do not
use a CLT or CLT-EX.
Filtered Noise • US In the U.S., use C-Message Noise filter
Units and display units of dBrn.
• Europe
In Europe, use Psophometric Noise
filter and display units of dBm.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 F-11

System Administration Guide The Customer Environment Screen
Additional Customer Information Page

F-12 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The Customer Environment Screen System Administration Guide
Make Your Changes Effective

Make Your Changes Effective

Overview Changing values on the Customer Environment screen does not make the new
values current for LoopCare.

Procedure Use the following procedure to make the values stored for the Customer
Environment screen current for LoopCare.
1. Log in as mlt.
2. Start oam.
3. On the OAM menu bar, select the UIP option.
A drop-down menu is displayed.
4. Select the UIP option.
The MLT USER INTERFACE MAIN MENU is displayed.
5. Select option 3 (System Administration).
The System Administration menu is displayed.
6. Select option 7 (STOP).
The SYSTEM STOP menu is displayed.
7. Select option 3 (MLT Application).
The following messages are displayed:
MLT:xxxxxxx: STOPPING MLT APPLICATION
Hit <CR> to continue...:
8. Press <Enter>.
The SYSTEM STOP menu is displayed.
9. Select option 1 (Main Menu).
The MLT USER INTERFACE MAIN MENU is displayed.
10. Select option 3 - System Administration.
The SYSTEM ADMINISTRATION menu is displayed.
11. Select option 6 (Start).
The SYSTEM START menu is displayed.
12. Select option 3 (MLT Application).
The following prompt is displayed:
Cold or warm start? [c/w/q]

Revision Q (p/n 040-0362) Release 2.15, December, 2006 F-13

System Administration Guide The Customer Environment Screen
Make Your Changes Effective

13. Select the appropriate option.

The changes you saved on the Customer Environment screen have become
current for the LoopCare system.

F-14 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Procedure to use after running basegenG

Introduction

Overview The procedure described here must be followed under the following conditions:
• You plan to run basegen
and
• Your configuration is an RBOC standalone MLT/LMOS environment
or
• Your configuration is an RBOC hybrid MLT/LMOS environment

Procedure After running basegen, do the following.

Copy/paste the following line from the /mlt/config/MLT.env file into the
section before the # Customer Definable line in the /base/config/
MLT.env file:

HOSTKEY=`grep '^HOSTKEY=' /base/bin/.trsetenv | cut -d"=" -f2`

Revision Q (p/n 040-0362) Release 2.15, December, 2006 G-1

System Administration Guide Procedure to use after running basegen
Introduction

G-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Using the mltctrl Script H

Introduction

Overview The mltctrl script is used to control the MLT and the base processes. The base
process is the application manager for LoopCare.

Options Table 1 lists the options for the mltctrl scrip ad their functions.

Table G-1. Options for the mltctrl Script

Option Function
-r start This option starts the MLT application.
-r stop This option stops the MLT application.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 H-1

System Administration Guide Using the mltctrl Script
Introduction

Table G-1. Options for the mltctrl Script

Option Function
-r status This option queries the MLT application.
-r bstart This option starts the BASE application and then the
MLT application.
The user must be logged in as base and execute the
script from the /mlt/ubin directory.
-r bstop This option brings down the MLT application and 5
seconds later the BASE application.
The user must be logged in as base and execute the
script from the /mlt/ubin directory.

Example The following is an example of the use of the bstart option of the mltctrl
script.
mltctrl -r bstart

H-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

The cgiReportsClean.sh Script I

Introduction

Overview The cgiReportsCleansh script is contained in /mlt/ubin. It removes old files in the
following directories:
• /mlt/cgi/reports
• /mlt/webgui/results

Variables The following environmental variables in the MLT.env file determine whether files
Controlling are removed.
Removal • MLT_WEBFILES
• MLT_RMUWEBFILES

Revision Q (p/n 040-0362) Release 2.15, December, 2006 I-1

System Administration Guide The cgiReportsClean.sh Script
Introduction

I-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

BASE Commands J

Managing Groups

To get into the BASE context, run base after logging in as mlt.

Once you are in the BASE context, you can run the following commands:
• start <group name>
Start the specified group and lower level groups. See Appendix A in this
guide for more information on these groups.
• stop <group name>
Stop the specified group and lower level groups.
• monitor all
Displays the contents of the log as it fills, allowing you to check for errors
on the fly.
• query
Display the status of the groups.

Run base -q <base command> to execute a BASE command without switching

to the BASE context.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 J-1

System Administration Guide BASE Commands
Managing Groups

J-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for SOAP API K

Introduction

Overview This appendix describes the procedures you must perform if you have the SOAP
API feature enabled for your environment.

Prerequisites • JAVA 1.5 is installed.

• Apache Tomcat version 5.5.16 is installed.
• You have received the appropriate xerces.gz file from Tollgrade.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 K-1

System Administration Guide Additional Procedures for SOAP API
LoopCare

LoopCare

1. Install the feature file with this feature on.

2. Install the xerces-c API file, loading the software under /usr/local.
For Solaris gunzip and tar xerces-c_2_6_0-solaris_28-cc_62.tar.gz into /
usr/local/xerces-c_2_6_0-solaris_28-cc_62.
For HP gunzip and tar xerces-c_2_6_0-hpux_11i-acc_a03.tar.gz into /usr/
local/xerces-c_2_6_0-hpux_11i-acc_a03.
3. Set the LD_LIBRARY_PATH.
For Solaris, add /usr/local/xerces-c_2_6_0-solaris_28-cc_62/lib to
$LD_LIBRARY_PATH in /base/config/MGRP.env.
For HP add /usr/local/xerces-c_2_6_0-hpux_11i-acc_a03/lib to
$SHLIB_PATH in /base/config/MGRP.env.
4. Copy and un-comment GDF lines from /mlt/config/MGRP.gdf into /base/
config/MGRP.gdf:

#F:$MLT_BIN/LCJFProxy dummy lcjf

#F:$MLT_BIN/lcsp dummy lcspin,lcspot

5. Bounce MGRP.

K-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for SOAP API System Administration Guide
Apache Tomcat

Apache Tomcat

1. Export $CATALINA_HOME (the install node of Tomcat).

2. Copy /mlt/apps/soaptester/soaptester.xml to the Tomcat directory,
$CATALINA_HOME/conf/Catalina/localhost/soaptester.xml.
3. Validate that the web server is available by entering URL into browser,
http://<server name>/ soaptester.
For example: http://lennon.tollgrade.com/soaptester.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 K-3

System Administration Guide Additional Procedures for SOAP API
Deploying SOAP Tester Services

Deploying SOAP Tester Services

1. To deploy LoopCare SOAP tester services:

cd /mlt/apps/soaptester
./deploy.sh deploy
or, for secure LoopCare servers
soaptesterport=8080 /mlt/apps/soaptester/deploy.sh deploy
2. Validate the availability of LoopCare Soap tester services by entering this
URL into a Browser: http://<server name>/soaptester.
3. Test the installation by following the procedure outlined in Testing the
SOAP Installation: page K-5.

K-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

Additional Procedures for SOAP API System Administration Guide
Testing the SOAP Installation

Testing the SOAP Installation

To test that SOAP service is installed and deployed under tomcat and that the
user can communicate through LoopCare, execute:
cd /mlt/apps/soaptester/test
./runTestSoapAPI.sh <host name> <TCP port>
The output indicates any points of failure.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 K-5

System Administration Guide Additional Procedures for SOAP API
Testing the SOAP Installation

K-6 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ASCII Text File and SOAP API for Test
By TN Feature L

Introduction

Overview This appendix describes

• The format of the text file used for mapping TNs to Circuit Access
Information.
• The procedures you must perform if you are using the SOAP API with the
Test By TN feature as an alternative to the text file.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 L-1

System Administration Guide ASCII Text File and SOAP API for Test By TN Feature
ASCII Text File

ASCII Text File

An external system is responsible for providing the initial and ongoing feeds
mapping TNs to the Circuit Access Information. This external system must place
the mapping files in a specific directory of the Primary LoopCare Server. See the
instructions on setting the inDir and outDir cache configuration variables in
chapter 16 of the Installation Guide.

A sample ASCII file is shown below. The first field is the operation, NEW,
UPDATE, or DELETE. The second field is the TN and the third, the Circuit Access
Information. Note that both the fields and the components of the Circuit Access
Information are space delimited.
NEW 14268888 ASAM-DSLAM 1 1 02 08
UPDATE 12433911 73SWEIDY120 1 1 03 06
UPDATE 11685555 73MURS116 1 02 07 10
NEW 11782555 AMAS1 1 1 03
DELETE 11783522
NEW 11678955 TELA1 0059

L-2 Release 2.15, December, 2006 Revision Q (p/n 040-0362)

ASCII Text File and SOAP API for Test By TN Feature System Administration Guide
Deploy SOAP API for Test By TN

Deploy SOAP API for Test By TN

Procedure If you have not already installed the SOAP API

1. Follow the procedures outlined in the LoopCare: page K-2 and Apache
Tomcat: page K-3 sections.
2. Bounce Apache.
3. Install the API Data Cache and the Test By TN feature. See the Installation
Guide for instructions.
4. Execute
cd /mlt/apps/soaptester
/mlt/apps/soaptester/LoopCareDataCache_deploy.sh deploy
or, for secure LoopCare servers
soaptesterport=8080 /mlt/apps/soaptester/
LoopCareDataCache_deploy.sh deploy
5. Validate the deployment of the SOAP API for the Test By TN feature.
Access http://<server>/soaptester/index.jsp from your browser.
Select List.
Verify that LoopCareDataCache is listed.

If you have already installed the SOAP API, skip steps 1 and 2.

Revision Q (p/n 040-0362) Release 2.15, December, 2006 L-3

System Administration Guide ASCII Text File and SOAP API for Test By TN Feature
Deploy SOAP API for Test By TN

L-4 Release 2.15, December, 2006 Revision Q (p/n 040-0362)