Experienced same problem yesterday on CS1000M Rls 6.00R. Saw AUD038's and AUD035's pointing to the CDR TTY. I can tell you how I cleared it, but not sure if it will come back or not. I think this might be a software bug. Just my opinion. Anyway, I added CTY to another TTY. For example, add USER CTY to the modem TTY (ADAN) in LD 17. Then add this port to CDR_DATA PORT in LD 15. Remove or X the actual CDR device TTY from LD 15 CDR_DATA, and then in LD 17 remove CTY from the CDR device TTY. Once I did this, I saw several AUD039's and AUD040's output, indicating the Call Register's were cleared. Basically I removed removed the existing CDR port programming, programmed a new one, let the system run audits and it cleared on its own. I then put the programming back they way it was previously. This is probably just a work around, but it stopped the AUD035's and AUD038's. Hope this helps.
I was working another issue with GTS Avaya Emergency Recovery. CS1000M CPIV processors where the /U drive disappears and all kinds of other edd issues, and this popped up. He was stumped so I have to get this resolved through them.
Funny thing. I posted this on the Nortel Discussion Forum and it was removed.
I had the same AUD035 and AUD038 messages scrolling last week. We are in the middle of changing IP's on our Phone system and lost connection to our TM server. The tech who cleared the messages did the work while I was offstie so I don't know what steps he took. I will ask him next week when he is back on site.
We have been experiencing the same issue. Just upgraded to 6.0 and CDR been in for years.
We removed the port from CDR data and the tty port and we get AUD000.
As soon as we program the tty back in AUD035 and AUD038 start, even before adding the port back into cdr data.
We think it caused an INI on the switch and was clear for about 8 hours before the audit errors started again.
We put a tty on the port today and it is sending good CDR data, and now the AUD035 and AUD038 stopped. Plugged it back into the datlink and is working fine. We will see how long it lasts.
We received an update in office this morning regarding a patch (MPLR30090) which is being investigated, as it is known to cause the AUD errors you are receiving.
Does this site use CDRs? The problem that this patch was designed for is as follows:
FULL PROBLEM DESCRIPTION:
Call Registers of Q records getting stuck in CDR_Q if CDR TTY is disabled
Impact of the problem :
If the CDR tty is disabled and QREC is enabled on incoming route then the Q records will get stuck in CDR_Q. If the tty never enabled then system will run out of call registers and will go for INI.
It also affects the call processing. No dial tone on sets and not able to make any calls, we can login to the overlays, however can not access any overlays. This problem has been fixed by the patch MPLR29827.
The patch MPLR29827 will not clear the CRs stuck in CDR_Q, hence prepared the patch MPLR30090. It would not affect call processing if the CDR TTY is enabled.
Remove MPLR30090 to resolve the issue. Even if the CDR is enabled and working.
Analysis: MPLR30090 was created to fix the problem where Call Registers of Q records were getting stuck in CDR_Q if CDR TTY is disabled.
Avaya has received recent reports to indicate this patch is cause for AUD038 and AUD035 messages to be printed and the CDR records being left in the regular CDR queue.
Actions: The Release 6.0 versions of MPLR30090 has been changed from GEN Released to OBS status as of today, March 8th, 2011 and removed from the Dependency Lists (dated 2011-03-08 10:15:19).
A replacement patch for Release 6.0 and 7.0 is in progress (MPLR30811).
A Root Cause Analysis (RCA) has been initiated.
Recommendations: It is recommended to remove MPLR30090 by downloading the latest DepLists and performing Refresh function. MPLR30090 can also be removed (poos/pout) via pdt Interface.
Please contact your technical support representative if further assistance is required.
Very glad to find this thread. Over the past year we have refreshed 8 sites of a financial institution from PII 4.5 to PIV 6.0. 3 of the 8 locations have experienced this problem and we have just been doing the same workaround superdaveh2000 mentions above. In looking at ESPL, it appears mplr30090 is superceded by mplr30942 but 30942 is currently in "view only" status. You guys have any new updates?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.