This record shows how to remove it
Problem
Unable to remove the entry against DLOP in LD 17 CEQU_DATA
Answer
Difficulty in using slot 4 on Succession 1000S for a new software build
The only reference to slot 4 was in the CEQU_DATA (LD 17) as below
* DLOP NUM DCH FRM TMDI LCMT YALM T1TE TRSH
* PRI 04 24 ESF YES B8S FDL 0 00
Trying to OUT the DLOP entry gave SCH5589 as below
*>LD 17
*CFN000
*MEM AVAIL: (U/P): 572738 USED U P: 543942 62967 TOT: 1179647
*SCH5066
*
*DCH AVAIL: 76 USED: 4 TOT: 80
*TMDI D-CHANNELS AVAIL: 64 USED: 0 TOT: 64
*AML AVAIL: 14 USED: 2 TOT: 16
*REQ CHG
*TYPE CEQU
*DDCS
*TDS
*CONF
*DTDT
*DLOP X04
*
*SCH5589
Doing a STAT TDMI in LD 48 gave the following
*LNK000
*.STAT TMDI 4
*TMDI 4: MAN DSBL
* DITI 4 DIS PORT 0
To cease the DLOP entry - manually disable the TDMI pack for 4 and the in LD17 remove the 04 entry against DLOP
###############################################
Problem
CS1000: MSDL enable fails at release 7.50
Answer
From time to time complaints are coming in from sites that when they try to enable a TMDI or a MSDL that the enable command just hangs and will not do anything.
During lab testing and code review it was found that RESET_WAIT_UNTIL is loaded from 2 different sources depending on the command issued. Depending on the current TOD2SEC and RTCLOCK values RESET_WAIT_UNTIL may cause an extremely long wait when trying to enable after a command that loads RESET_WAIT_UNTIL with the opposite type of timestamp from what is expected. For example, the SLFT command loads the RESET_WAIT_UNTIL with TOD2SEC, but ENL FDL command expects RESET_WAIT_UNTIL to be loaded with RTCLOCK.
The problem occurs when TOD2SEC is greater than RTCLOCK, and you run the SLFT command, then try to ENL FDL the TMDI or MSDL, the RESET_WAIT_UNTIL will be such that the wait time is incredibly long before the download can start.
Currently the problem may be worked around by using the RST command since it sets RESET_WAIT_UNTIL with RTCLOCK.
However there is one case where attempting the download after the RST command sets RESET_WAIT_UNTIL with TOD2SEC again causing it to hang again.
SETUP and ACTIONS performed to cause the problem:
HARDWARE and DATA SETUP:
CS1K with MSDL and TMDI cards
ACTIONS:
1. At any time disable a MSDL or TMDI, then do a SLFT, then do an ENL FDL.
EXPECTED RESULTS:
1. Enable command starts promptly with the download
ACTUAL RESULTS:
1. At times the download never starts.
Example: On site this occurred when RTCLOCK was C487E783 and RESET_WAIT_UNTIL and TOD2SEC was 000C9886.
Notes
The patch should be used along with MGC patch MPLR31779 (included in MGCCCD03)
The problem TMDI card & DCH should be removed and recreated again after patch installation
Due to the method of operation required to create a patch back from the next release, this patch will introduce extra delay. This is normal for this patch and will be corrected in future releases by the actual fix.
After a few seconds the patch will output a message indicating that the longest wait period is started. The message is as follows and will occur several times only the first time should have the full 40 second wait time.
INFO1807 PLEASE WAIT UP TO 40 SECONDS FOR CARD RESPONSE
I think patch mplr32057 rls 7.50Q was issued to fix it.
Firebird Scrambler
Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer
Website =
linkedin
