Do's and Don'ts

6.1. IOP RELATED PROBLEMS AND SOLUTIONS

To ensure smooth operation of the IOPs and the Exchange, some of the routine maintenance
problems along with their solutions are explained. It is expected from the maintenance personnel to
refer the specific section for a problem and strictly follow the same sequence, listed as possible
solutions of the problem. Some of the problems are listed below :
1 "CRP" fails to run on the IOP.
2. "CRP" is running but CRP command fails to execute on the IOP.
3. OOD - Report related problems.
4. Printer related problems.
6.1.1. "CRP" Fails to Run on the IOP.
In this case, the error message is to be noted and then select one of the possible solutions which
will depend on the error message.
CASE 1 : When "CRP" fails to run with error
"ERROR CASE RMID - - - - - - - - - "
Solution : IOP5X> ipcrm - Q805
CASE 2 : When "CRP" fails to run with error "CRP not found"
Solution : If "CRP" fails to run on IOP-0 with above error message but runs successfully on IOP-1
then CRP file is to be copied from IOP-1 to IOP-0.
Insert cartridge in IOP-1
IOP5D>>$TAPE
IOP5D>cd $CURREL ?
IOP5D>ls crp | cpio – ocv > $TAPE

Remove the cartridge from IOP-1 and insert it in IOP-0.

The CRP file has been copied on the cartridge from IOP-1. Now copy the same file from cartridge
to IOP-0.
On IOP-0 :
IOP5C>cd $CURREL
IOP5C>cpio -icv<$TAPE
Now remove the cartridge from the cartridge drive and run "CRP" on IOP-0.
6.1.2. OOD Related Problems
Case 1 : aood_main process is recreating again & again on the CONSOLE of one IOP with error
message:
"recreating /u/code/iopete/aood_main, 2,1,0,0"
Solution : 'aood_main' file is to be copied in this (say IOP-1) as per the procedure given below:-
Insert a cartridge in drive of IOP5C
IOP5C>>$TAPE
IOP5C> ls aood_main $ | cpio -ocv>$TAPE
Remove the cartridge from IOP5C drive and insert
in IOP5D drive Now do the following in IOP5D :
iop5d> cd $ CURREL
iop5d> cpio -icv<$TAPE
Remove cartridge from the IOP-1 drive
Case 2 : Alarms do not appear immediately after the unit fails.
Solution : In this case aood-main process has to be recreated as per
the following procedure :
On active iop, enter iop5x> prompt
iop5x> ps -ef | grep aood
following message will be displayed:
root xx . .......................................... [aood_mai]
Note down this number 'xx' next to root
iop5x > kill -9 xx
Process aood_main will be recreated in response to
the above command. Go to CRP prompt. Current alarms will start coming immediately.
Go to CRP and resume normal operations.
6.1.3. Printer Related Problems
The Report stopped coming on the printer
Solution :
Step 1 Check status of the printer using following command
iop5x> cat /etc/passwd >/dev/icc_0 (if printer is connected
on ASIO-0 of IOP VL or ASIO-1 of IOP-VH.
If the output of the file is printed on the printer, then
printer cable, printer port of IOP and printer itself are ok.
Go to Step 2.
In case output is not printed on printer, then
i) printer itself may be faulty, check by self test.
ii) printer cable may be connected on the wrong port.
iii) printer port icc_0 may be faulty.
iv) In the case of Installation Site, printer cable may
be faulty.
To isolate the problem, shutdown the IOP and bring it to
monitor prompt IOCx.x>
Now test the printer using command :
IOC x.x > print 1 10
Different characters will be printed in the response of the
above command. If it is not so, remove the printer cable
from IOP-end and put “ACIA - LOOPBACK CONNECTOR” on the corresponding port. Now test the
port by executing the command :
IOCx.x > acio1 0 10 1
It should pass. This ensures that there is no fault at IOP end and the only possibility is that
“Printer Cable” or
Printer itself may be faulty. This can be isolated by
replacing the cable first and then Printer, one by one.

However, if the ACIA loopback test fails, the printer can

be connected to any other icc-x port.
Step 2 Check status of printer scheduler by giving following command:
IOP5x> lpstat -t
The response should be:
i) Scheduler is running.
ii) All printers (Pr1, Pr2 ..... Pr4) are enabled and
accepting requests
iii) No printer request is pending in the queue for Pr1..
If every thing is OK, then go to step 3, proceed as listed
below :
# 1 If scheduler is not running, then login into the 'lp'
account:
login : lp
Password : DSSlp
iop5x> cd /usr/lib
iop5x> lpsched

This will start printer scheduler.

log out of lp account by giving
iop5x > exit
Now go to admn account.
# 2. If printer is not accepting request then
log into 'lp' account
login : lp
Password : DSSlp
iop5x> cd /usr/lib
iop5x> accept pr1
Now log out of lp account
# 3. If scheduler is running & printer is accepting
request but printer is disabled, then do following:
login : lp
Password : DSSlp
iop5x > enable prn1
iop5x > exit
# 4. If lot of request are pending in the queue, then in
admn account itself do following:
iop5x > cancel x (x = pr1-1 etc.)
where x is the printer request pending in the
queue, as shown in response to the lpstat -t
command.
Step 3 To change printer port from icc_0 to icc_4 (say)
i) move the printer cable from ASIO-0 (icc_0) to
ASIO-4 (icc_4) for IOP VL.
ii) log into lp account
login : lp
Password : DSSlp
iop5x> cd /usr/lib
iop5x> lpshut
iop5x> lpadmin -pprn1 -v/dev/icc_4
iopx> lpsched
iop5x> enable prn1
This will enable the printer at new port icc_4.
Log out of lp account.

6.2. DO'S AND DONT'S FOR CARD HANDLING

6.2.1. Terminal Unit Interface (TUI) Cards
At the time of changing the card, it should be ensured that the card is having proper jumper
settings as per the requirement of its placement. Don't switch off power to TU during change of
any card.

6.2.2. Controller Cards (TIC, ANNC, TTC, MSC, TSC, CPU etc)
Before changing the cards with that of spares arranged from some other sites it should be ensured
that the new card is having proper S/W EPROMs compatible to the present software release
working in the exchange.
6.2.3. CPU-S04/S05 Cards
6.2.3.1. At the time of changing the CPU cards, the proper check sum of the CPU cards should be
ensured before using it in the system because of the following reasons.
* Checksum of the EPROMs of the CPU-card used in SBM-RAX/TAX is different than that the
CPUs used in MAX-L.
* Checksums of the EPROMs, of the CPU - cards used in different Base Modules of MAX-L i.e. BPU
of BM and APU and SCU of CM, are different.
6.2.3.2. At the time of changing the CPU card, also verify that same version of CPU card i.e.
either CPU-S04 or CPU-S05 are used in both the copies of the unit.
6.2.4. Message Switch Device (MSD) Card
The jumper settings of MSD card should be verified as per its placement in Base Module or Central
Module. Same MSD card is used in both the modules with different jumper settings.
6.2.5. New 16 MB Memory Card (TME) Card
At the new sites, where 16 Mb TME card is used in place of 4 Nos of 2 Mb memory card in BMs and
2 Nos of 2 MB memory card in CM, DO NOT CHANGE THE CARD IN POWER ON CONDITIONS.
Switch off the corresponding power supply unit before jack-out or jack-in of the card.
6.3. GENERAL - DO'S AND DON'TS FOR O&M ACTIVITIES
6.3.1. Take 'ed' and 'bd' back-ups daily in low traffic hours.
6.3.2. At SBM-RAX sites, take 'bc' back-ups after every 15 days against the standard procedure
of 2 months and clean the 'bc' file groups regularly to have the sufficient disk space. However, at
MAX-L sites and at those sites
where disk space is more because of the retrofitting of new Hard Disk,
standard procedure of 'bc' backups after every two months can be followed.
6.3.3. Monitor the disk space in the both the IOPs every day and ensure that disk space in / data
does not fall below less than 5000 blocks in SBM-RAX/TAX and 10000 blocks in MAX-L sites. To
monitor disk space:

IOP5x>df.
In the above display, the content against /data indicates the current available disk space.
6.3.4. A no. of new traffic reports have been implemented in 2_2_1_6 software. If the traffic
reports are enabled, delete the 'tf' file group regularly.
6.3.5. The 'old' backups (i.e. ed, bd, bc ... etc) taken in S/W release 2_1_1_1, should not be
restored in the Exchange after upgrading it to new software release 2_2_1_6.
6.3.6. While taking the display/printouts of TRUNK/ROUTE related traffic reports,
the input against parameter MOD-NO should always be “AM”.
6.3.7. It is advised, not to put more than 40 TENs in a TGP. If it is required to have more than 40
trunks in a direction, create two or more TGPs and associate them as alternate choice in TGP-CHC
parameter of a Route-Code.
6.3.8. Don't crash the IOP by resetting or switching - off the power supply. Always use CRP-
Command INIT-IOP:2, 1; and then INIT-IOP:1,1; to shutdown the IOP.
6.3.9. Do not remove the floppy and cartridges from the drives till the drive's LED is glowing.
6.3.10. Do not remove the protection devices on the MDF and ensure that all the lines are having
the protection (IPMs or GD-Tubes). If a protection device is removed for repair of the line, it
should be replaced after repair. Also it
should be ensured that IPMs/GD-Tubes make proper contact with the earthing strip of the MDF.
6.3.11. It MBM-Sites, do not create DTMF-ckts in TRUNK BMs and MF-Senders/Receivers in
Line-BMs.
6.3.12. Do not execute INIT-SYS command. In case of emergency, execute INIT MOD for the
specific modules. Also for Base-Modules, do not execute INIT MOD with INIT-LVL as PI or higher
level of initialization, as this will cause
all STD nos. to be locked.
6.4. OPERATION AND MAINTENANCE RELATED GUIDELINES
6.4.1. Restoration of BMDC
The BMDC cartridge should never be restored in day to day operation. Restoration of BMDC is
required only when complete software is being loaded in the exchange. The restoration of "ed"
backup does not require restoration of "BMDC". In case of data corruption when restoration of old
exchange data is required, only "ed" backup restoration using command “COPY-IN” is sufficient. As
and when BMDC has been restored in working exchange, "ed" as well "bd" must be copied.
6.4.2. Programming Trunk Groups in C-DOT DSS
Keeping in view the complexity of the network and multiple features being supported in the common
software release for different configurations / applications of C-DOT DSS, the following
requirements should be met at the time of creating a trunk group :
* All the incoming trunk groups from TAX or ILT should be programmed as TTAX.
* All the incoming trunk groups from the parented exchanges should be defined as ORD.
* If C-DOT DSS is configured as TAX/ILT, all the O/G trunks should be defined as ORD if going
towards a terminating exchange and TTAX if going towards a TAX exchange.
6.4.3. Calendar Programming in C-DOT DSS
To maintain consistency of alarms and reports for lines, trunks and service circuits. AUDIT with
AUDIT-SET=12 should be programmed in the calendar with daily triggers for all the days in the
current year. This programming is
required to be done only once in a year or every time when a software is loaded in the exchange.
6.4.4. Use of TSC PROMs in Different Exchange configurations
When BMs of MAX-L are being integrated with MAX-XL or BM-XL are being integrated with MAX-
L, then following care should be taken for use of TSC PROM.
* The checksum for TSC PROM will be same for BM-L as well as for BM-XL if used as SBM-RAX or
as colocated BM/RSU of MAX-L.
* The checksum for TSC PROM will be same for BM-L as well as for BM-XL if used as colocated BM
or RSU of MAX-XL.
Otherwise, we can conclude that the PROMs on TSC will depend on the type of CM i.e. CM-L or CM-
XL and it is independent of BM-type.
6.4.5. TIC Cards with Compatible Software EPROMs
The C-DOT DSS supports distinctive ringing in all the new exchanges with retrofit option for
existing sites. The software has been designed to take care of compatibility related problems. The
exchange is defined to support
“Distinctive Ringing” by setting the system parameter “SPL-RNG“ to 1. At these sites, all the PSUs
should be updated for ECNs. Also the TIC cards should be updated for compatible software
EPROM. The TIC unit will not become INS unless compatible software EPROM is not used.
6.4.6. Mandatory Execution of MOD-DAY-TYP
It should be ensured that in 1st week of January & July of every year, the command is executed to
define the day type.
6.4.7. Programming for Routing of Priority Subscriber's Call; In all the routes, priority 2 should
be allowed by defining the trunk group choice against priority 2.
6.4.8. Proper Definition of 'CRG-RTNs' for all Tariff Classes;
Charge Rate Number (CRG-RTNs) must be defined for all the tariff classes mentioned in the
definition of Day Type 1 and 2. Other wise, call may fail during such time zones for which tariff
class has not been defined in 'CRGRTN'
and this may cause system initialilzation also.
6.4.9. Precautions to be Taken While Handling Various Hardware Cards
i) With the introduction of "Distinctive Ringing" in C-DOT DSS, there are two different versions of
PSU used in Analog Terminal Unit. One with blinking LED to indicate the ringing cadence which is
used at the existing sites. The modified PSU is identified with continuous LED and used only at the
sites where "Distinctive Ringing" feature is
offered. The two PSUs can not be used interchangeably. Also in one exchange, only one version of
Power Supply can be used.
ii) The SHM cards cannot be used interchangeably with BPC and HPC in SUM. To use SHM cards at
the sites where HPC has been used as processor in SUM, ECN in the form of firmware changes are
mandatory on SHM cards.
iii) For 32 signalling links, BPC is used as processor in CCS7 Signalling Unit. For more than 32
signalling links but upto 64 signalling links,only HPC is to be used as processor.
iv) In case of 800K BHCA configurations, HMS is used in all the BMs. HMS and MSC/MSD are not
pin to pin compatible and can not be used interchangeably.
v) While changing any TUI card, proper jumper settings as mentioned in “Installation Document”
should be ensured. The same is valid for BME cards used in CCS7 signalling unit (SUM) with HPC.
Otherwise, it is same for BM, AM, CM and SUM with BPC.
vi) While changing any Processor Card in BM, CM & AM, the jumper settings and EPROM status
should be ensured.
vii) At the time of changing any controller card from some other site, PROMs of correct software
version should be ensured before jacking the card into the system.
6.4.10. O&M Changes as a Result of Feature Enhancements
(i) A subscriber data can be modified only after making it
OOS-OPR.
(ii) It is not possible to delete the subscriber in growth mode.
(iii) All the “Hunt Group” related CRP commands are possible only when IOP is ONLINE.
(iv) Due to enhanced disk partitioning, to utilise the full capacity of the disk, the boot up time for
IOP has been increased to 30 minutes or even more depending upon the IOP and disk types, used.
(v) It is not possible to go to growth mode, when IOPs are in DUPLEX.This has been done to avoid
data inconsistencies.
(vi) In case of TAX or ILT, the system has to be defined for TAX functioning by setting the
parameters XCHG-TYPE = 4 and CLI-INFO= 1. If it is not so, the exchange will not support CLI for
TAX functions in case of R2-R2 and R2-ISUP transit calls. In addition to exchange configurations,
the incoming R2 trunk groups from parented stations should have CAMA=YES with TGP-TYP=ORD.
(vii) For ISDN subscribers, even if the subscriber has subscribed for CW facility, "Call-Hold"
should also be subscribed as the facility works through "HOLD" and "RETRIEVE" messages.
6.4.11. Known Constraints and Possible Alternatives
1. While creating a trunk group, more than 40 trunks should not be given at a time. If more than 40
trunks are required in a trunk group, trunks can be added using ADD-TRK commands in the existing
trunk group.
2. The status of more than 40 trunks cannot be displayed at a time in the same command. The range
of terminals given in DISPL-TRM-STATUS should not be more than 40. Alternatively, the command
DISPL-TRCNT-OOS can be used to know the breakup of more than 40 trunks. After that, DISPL-
TRM-ALL can be used to find out the listing of trunks with a specific status.
3. In case of more than 100 trunks, MOD-TGP-CHAR does not work. Command is rejected with
suitable error message. To modify the characteristics, the no. of trunks should be reduced to <100.
After modification, the deleted trunks should be added.
4. In few cases, modification commands for subscriber or Trunk Group Characteristics may fail with
suitable error message, prompting the user for corrective measures. In such cases, the subscriber
or trunks should be attempted once again to make them out of service.