FUJ00086828
FUJ00086828
Peak Incident Management System
Call Reference PC0145617 Call Logger Deleted User -- EDSC
Release Reported In--T40 Top Ref £-0704120541 :
Call Type Cloned call Priority B -- Progress stopped
Contact Deleted Contact Call Status Closed -- Published Known Error
Target Date 03/05/2007 Effort (Man Days) 0
Summary Branch 468519 - System has frozen during a transaction
All References Type oe Value
Clone Master 'PC0145212
Powerhelp E-0704120541
: SSCKEL KEL acha2552T
Progress Narrative : :
'‘Date:30-Apr-2007 14:07:51 User:Chris Hawkes
‘CALL PC0145617 opened
(Details entered are:-
‘Summary:Branch 468519 - System has frozen during a transaction
(Call Type:C
Call Priority:B
‘Target Release:T40.
Routed to:EDSC - Chris Hawkes
Date:12-Apr-2007 12:30:29 User:_Customer Call_
‘CALL PC0145212 opened
Details entered are:-
‘Summary:pm states that the system has frozen during a transaction
ICall Type:L
(Call Priority:B
Target Release:T40
Routed to:EDSC - _Unassigned_
\Date/Time Raised: Apr 12 2007 11:58AM
Priority: B
(Contact Name: john corry
‘IContact Phone:
(Originator: Phelp
\Originator's reference: E-0704120541
roduct Type: Riposte
'Product Serial No:
‘Product Site: 468519
12/04/07 11:58 pm states that the system has frozen during a transaction
12/04/07 12:00 UK959395
Information: pm states that the system has frozen and while on line the
system has un froze it self
12/04/07 12:01 UK959395
information: pm states that this happened on saturday aswell
12/04/07 12:10 UK959395
information: pm states has happend before aswell
12/04/07 12:10 UK959395
Information: pm states everytime the pm has been advised to reboot the
F/414.1/1
pysteut
12/04/07 12:11 UK959395
(Information: * NULL TEXT SUPPLIED *
12/04/07 12:12 UK959395
\Information: pm states that the system freezes during transaction
rocessing and when the system freezes has to turn customers away,
land wants to make a complaint
12/04/07 12:13 UK959395
IAdvice: advised nbsc for complaints and need information as mucha s
ithe pm can give to send call to EDSC to look into
12/04/07 12:13 UK959395
Information: NODE: 1
USER NAME: MCO001
jTIME: 11.50
IDATE: 12/04/07
SESSION ID: Unknown
[TRANSACTION NUMBERS: unknown
AMOUNT: Unknown
‘LAST 4 OF CARD NUMBER: 9420.
TP: O1
BP:02
STOCK UNIT: AA
12/04/07 12:20 UK959395
information: other times system has had to be rebooted after freezing
iduring a transaction:
\E-0704020356
}E-0704020307
IE-0703260324
12/04/07 12:21 UK959395
‘Information: checking events
12/04/07 12:25 UK959395
information: can you please check why the system freezes during a
ransaction
12/04/07 12:26 SYSADM.
jOpen OTI: Automatic Open OTI
***Updated by Mohammed Hussain at 12/04/2007 12:26:26
12/04/07 12:26 UK959395
IREASSIGN: Call # E-0704120541 was Reassigned from Mohammed Hussain,
Group HSH2 to Group EDSCI
\Date:12-Apr-2007 12:32:42 User:Jagdeep Bhambra
‘The call summary has been changed from:-
m states that the system has frozen during a transaction
The call summary is now:~
iBranch 468519 - System has frozen during a transaction
IDate:12-Apr-2007 12:33:04 User:Jagdeep Bhambra
/Product EPOSS & DeskTop -- Counter Common added.
\Date:12-Apr-2007 12:33:14 User:Jagdeep Bhambra
(The Call record has been assigned to the Team Member: David Seddon
Progress was delivered to Powerhelp
'Date:12-Apr-2007 13:56:53 User:David Seddon
IEvidence Added - 468519 - Ctr I event logs
FUJ00086828
FUJ00086828
F/414.1/2
FUJ00086828
FUJ00086828
\Date:12-Apr-2007 14:07:49 User:David Seddon
{Start of Response]
[Besides the instance of the screen 'freezing' this morning at 11:50am I've established from previous calls that there were other
instances on 2nd April between 10 and 10:30am and also at around 10am on 26th March as well. The counter application event log
nly covers the April instances and in both cases there are a number of CNIM events written around the time indicating problems
ith the connection. Checking through the whole log there are in fact a high number of these events. Passing call through to Chris
\Hawkes so a thorough check can be done on the cause of these events.
[End of Response]
[Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Powerhelp
iHours spent since call received: 0 hours
\Date:12-Apr-2007 14:08:00 User:David Seddon
[The Call record has been assigned to the Team Member: Chris Hawkes
‘Progress was delivered to Powerhelp
IDate:13-Apr-2007 11:33:40 User:Chris Hawkes
[Start of Response]
..There WERE some problems on Saturday 7th, due to a wider issue affecting ALL the ISDN-connected offices. However this
annot explain the problems experienced on 26th March and 2nd and 12th April. Gathering some logs from the gateway counter...
{End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
iResponse was delivered to Powerhelp
IHours spent since call received: 0 hours
IDate:13-Apr-2007 13:16:05 User:Chris Hawkes
{Start of Response]
..Ditrace captured for 11:50 this morning does show an unusual (but temporary) condition on the D-Channel of the Eicon card. This
ill need some deeper investigation (i.e. I have to get the manuals out....!)
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Powerhelp
IHours spent since call received: 0 hours
\Date:17-Apr-2007 10:28:26 User:Chris Hawkes
{Start of Response]
... There were two more incidents at 09:06 and 10:24 on the 1 6th. I will collect the logs for those times and see if they match. The PMI
IAY notice the line going a bit slow while I upload the data...
[End of Response]
iResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
IResponse was delivered to Powerhelp
‘Hours spent since call received: 0 hours
(Date:17-Apr-2007 17:11:35 User:Chris Hawkes
Product General/Other/Misc -- ISDN added.
Date:17-Apr-2007 17:11:37 User:Chris Hawkes
)Product General/Other/Misc -- ISDN updated to Subject.
F/414.1/3
FUJ00086828
FUJ00086828
\Date:20-Apr-2007 15:11:00 User:Chris Hawkes
{Start of Response]
...Sorry I have not put any updates on this call for a couple of days. (Iam afraid I have been helping with some Post Offices that had
inext to no OLS at all, not just one or two problems per week!) I have been looking at the traces from the 16th, but I have not found
janything to match the previous D-channel problems yet. I have also noted that there were some more declined transactions on the
18th and 19th, so I am grabbing the traces for those incidents from the gateway counter before they are "housekept" by the system.
{End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Powerhelp
{Hours spent since call received: 0 hours
Date:24-Apr-2007 13:46:17 User:_Customer Call_
[EMPTY 24/04/07 13:43 UK959239 HSHS Information: PM called in as the system froze again during a transaction
n node 1.
IE-0704240668
Date:24-Apr-2007 13:49:50 User:_Customer Call_
IEMPTY EMPTY EMPTY OTI Astea OTI Success: An add has been sent to PINICL 24/04/07 13:48 uk959331 HSH8 Repeat Call:
IPM states she has had to reboot the gateway again and has
10 OLS 24/04/07 13:49 uk959331 HSH8 Advice: advised pm that as long as she is rebooting the gateway she
con't have OLS on node 2 24/04/07 13:49 uk959331 HSH8 Information: pm not happy and hung up
IDate:24-Apr-2007 17:58:58 User:Anne Chambers
[Start of Response]
iI think there are two interacting problems here:
i) branch appears to have some sort of intermittent comms problem - if this can be resolved it may be the fastest way to help the PM.
[There have been about 20 of these during working hours in the last 4 weeks. The failures are transient and the connection is normally
restored quite quickly.
i) when a failure does occur, on several occasions CNIM has attempted to update the OnlineStatus object but has got a Riposte lock
jerror. The counter then hangs - the timer which should timeout the NB application after 32 seconds does not kick in, After 6 or 7
jminutes CNIM appears to retry the connection. If this is ok the Request is sent (much too late!) and the counter application times out,
iRiposte locks have caused problems elsewhere in the past; I will check to see whether other branches are getting similar problems.
iCNIM code needs to be checked to see if it can behave better in this situation.
if the PM phones in again with the same problem DO NOT ADVISE HER TO REBOOT unless the counter has already been
hanging for more than 10 minutes. In most cases it will free itself within this time, and there will be less disruption than a reboot will
lcause. We are continuing to investigate. i
{End of Response]
iResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Powerhelp
IHours spent since call received: 0 hours
\Date:26-Apr-2007 09:14:36 User:Anne Chambers
iReference Added: SSCKEL acha2552T
F/414.1/4
FUJ00086828
FUJ00086828
\Date:30-Apr-2007 12:16:26 User:Chris Hawkes
Start of Response]
.-Again, sorry to leave this one so long between updates (there are a lot of "A" priorities around at the moment). I have now
analysed the first incident from the 19th and this shows that the R1 was written at 09:08:48, I can see 4 x 250 byte encrypted
imessages going out of the diehl driver between 09:08:47.903 and 09:08:48.023, (to the 4 cor servers) but no sign of a response from
he datacentre. The ISDN call, which was first established at 09:06:48.982 was hung up at 09:09:41.029 with no errors. The A3 was
ritten to the messagestore at 08:09:03 (datacentre time), but I need to try and find out how far the clocks between the branch and
the Datacentre are before being able to decide whether this was within the 32 second timeout period...
{End of Response]
iResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
[Response was delivered to Consumer
IDate:30-Apr-2007 12:22:14 User:Chris Hawkes
{Start of Response]
... Sorry, I should have also said that the fact that the A3 was written for this transaction proves that at least ONE of the 4 copies of
he RI arrived at the datacentre, and got processed.
{End of Response]
\Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
\Date:30-Apr-2007 12:53:26 User:Chris Hawkes
Start of Response]
..For the SECOND incident on the 19th, at 14:59, I canNOT see any A3 written in the messagestore. This implies that either NONE
yf the 4 RIs arrived at the datacentre, or, if they did, it was already too late to process them. In this case the R1 was written at
14:58:45, but the call, which was initiated within 500mS, did not establish a good working connection to the Datacentre (that would
carry user data) until 14:59:00 - i.e. 15 seconds later. All 4 of the R1 copies were transmitted within I second. The delay in call
jinitiation was due to slow response from the LNS router in the datacentre in setting up the IP layer. I cannot tell what caused that
ithough...
{End of Response]
iResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
\Response was delivered to Consumer
\Date:30-Apr-2007 13:09:11 User:Chris Hawkes
Start of Response]
..That ISDN call also ended without error at 15:00:00 after transmitting and receiving LOTS more frames.
End of Response]
iResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
IResponse was delivered to Consumer
Date:30-Apr-2007 13:18:12 User:Chris Hawkes
{Start of Response]
... There was an interesting bunch of incidents on the 23rd at around 10:16-22: What makes them interesting is that there were 4
ideclined transactions logged (RIs) at 10:16:11 (Node 1), 10:17:22 (Node 1), 10:18:29 (node 2) and 10:21:19 (NODE 1), but in the
iddle at 10:10:13, there was a completely SUCCESSFUL transaction (also node 1). This indicates just how intermittent the
iproblem is.
End of Response]
iResponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
F/414.1/5
FUJ00086828
FUJ00086828
\Date:30-Apr-2007 14:06:08 User:Chris Hawkes
{Start of Response]
..Again, for this series of calls, I can see (encrypted) frames that look like the 4 copies of the (1242byte) RI leaving the counter
ithin a second or so of the time it was written in the message store, so it looks as though the Rls did NOT reach the datacentre.
IHowever there are smaller packets (150-250bytes) going in both directions before and after the crtical messages. This is beginning to
look to me like a congestion issue further up the network (probably UPSTREAM of the DLE).
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
\Date:30-Apr-2007 14:07:43 User:Chris Hawkes
{Start of Response]
...Because there are 2 separate issues here - the basic congestion issue with the comms (somewhere) AND the way that the counter
‘code can lock up in certain circumstances, I am going to CLONE this call so that we can work on the two problems in parallel.
{End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
\Date:30-Apr-2007 14:07:51 User:Chris Hawkes
(Call cloned from original call:PC0145212 by User:Chris Hawkes.
IDate:30-Apr-2007 14:08:47 User:Chris Hawkes
...Anne, please can you explore the lock-up issue associated with this problem.
\Date:30-Apr-2007 14:08:55 User:Chris Hawkes
(The Call record has been assigned to the Team Member: Anne Chambers
\Date:01-May-2007 17:10:13 User:Anne Chambers
{Start of Response]
There is a problem which is causing system freezes during banking transactions at many Bronze branches if the comms are
intermittent. The system hangs for several minutes, and the clerk may decide to reboot, or be advised to by the helpdesk. The
problem just affects the gateway counters.
jThe R1 request priority message is written. The counter tries to connect to the data centre but the connection fails. The event logs
‘show several CNIM events, followed by a Riposte ‘timeout waiting for lock’ event. Then C_HV_POSCH reports that it couldn't
jupdate the WANStatus object.
IThe counter becomes unresponsive. The banking timer, which should time out the request after 32 seconds, doesn't kick in. If the
iclerk doesn't reboot, the counter usually wakes up again after 5-8 minutes. At this point the banking transaction is timed out.
{The comms problems at some Bronze branches are being investigated on call PC0145212. This call has been raised to find out why
ithe Riposte lock is being held and why the counter then hangs - and eventually recovers.
ery hard to tell when this problem started, but I think it goes back to at least Sept 2006. While it is very inconvenient for the
ffected branches, few of them are continually badly affected by it.
‘One thing I've noticed: ETopUp requests don't hit this problem, but NB and Debit Card do, whenever CNIM Failure mode is set to
lost connection when trying to send the request.
jot quite sure where this call should go. The banking EMV code may be implicated. CNIM manages the connection or failure to
onnect. C_ HV_POSCH (a counter agent) reports the failure to update the object. Riposte is holding the lock (but I suggest we only
[raise this with Escher as a last resort).
{End of Response]
iResponse code to call type C as Category 40 -- Pending -- Incident Under Investigation
F/414.1/6
FUJ00086828
FUJ00086828
IDate:01-May-2007 17:11:26 User:Anne Chambers
\Evidence Deleted - 468519 - Ctr I event logs
\Date:01-May-2007 17:12:09 User:Anne Chambers
Evidence Added - Messagestore and Ut group
IDate:01-May-2007 17:12:34 User:Anne Chambers
Evidence Added - cl application event log _
\Date:01-May-2007 17:12:57 User:Anne Chambers
Evi dded e trace 12
\Date:01-May-2007 17:13:40 User:Anne Chambers
iEvidence Added - Ext ict of messages and events for problem March/April _
\Date:01-May-2007 17:14:32 User:Anne Chambers
iThe Call record has been transferred to the team: QFP.
\Date:01-May-2007 17:14:59 User:Anne Chambers
iProduct Network Banking -- NB Counter added.
‘Date:01-May-2007 17:15:07 User:Anne Chambers
Product Network Banking -- NB Counter updated to Subject.
IDate:02-May-2007 08:03:16 User:Lionel Higman
[The Call record has been assigned to the Team Member: Mark Scardifield
iDate:02-May-2007 11:26:34 User:Mark Scardifield
{The Call record has been transferred to the team: EPOSS-Dev
(The Call record has been assigned to the Team Member: Mark Scardifield
\Date:02-May-2007 16:48:58 User:Kath Greenwood
il have discussed this with Gareth and we are unsure what is triggering the counter to wake up again after 5-8 minutes. As the 30.
second timer in the Counter Code is not triggered, the Counter development team is unable to shed any light on the matter.
[An example of the problem can be seen in the application event log at 11:51:27 on 12/04/07, where Riposte logs:
"An unexpected error occurred while attempting to modify an entry in the run map. Timeout occurred waiting for lock.
0xC 1090003)"
At the same time, Counter Call Scheduler logs:
"Timeout occurred waiting for lock."
hile attempting to write the NetworkState message to the message store.
‘e have seen the Riposte Timeout message before but are not aware of an explanation from Escher as to the root cause. I'll check
ith Mike Coon on his return next week.
\Perhaps CNIM could have a quick look at the problem to see if they are able to shed any light on what is waking up after 5-8
inutes and advise if this time is configurable.
\On Gareth's suggestion, I am returning this Peak for onward routing to CNIM.
F/414.1/7
FUJ00086828
FUJ00086828
(Date:02-May-2007 16:49:24 User:Kath Greenwood
{The Call record has been transferred to the team: QFP
[Date:03-May-2007 14:53:01 User:Lionel Higman
{The Call record has been transferred to the team: Nwks-&-VPN-Dev
[Date:08-May-2007 15:24:07 User:Peter Ambrose
The Call record has been assigned to the Team Member: Nick Johnson
IDate:14-May-2007 07:45:01 User:Chris Hawkes
..*** Note for anyone INVESTIGATING this incident: The Branch (468519) for which the original, pre-clone, incident was logged,
‘as NOT reported any further problems since I switched the Service type from Bronze (ST4 - Dial on demand) to Silver FRIACO
ST7 - "always" on).
\Date:14-May-2007 07:48:55 User:Chris Hawkes
_..** Notes for anyone considering the relative PRIORITY of this incident (RMF etc); (1) There is a VERY STRONG financial
incentive to switch as many as possible of the remaining SILVER FRIACO branches AWAY from this service (ST7) and on to a
Dial-on-demand service (ST4) NOW and during the next few months. (2) The Silver FRIACO service will be withdrawn altogether
lby September. Therefore a FIX is required by then to address the problem at any remaining ISDN DOD branches (could be as many
jas 200 potentially affected).
iDate:14-May-2007 07:50:19 User:Chris Hawkes
...** Further note for anyone INVESTIGATING the problem. If you need any more evidence, please ask SOON, as there are plans
ito bring forward the migration of THIS branch (468519) to ADSL within the next 2 weeks.
\Date:18-May-2007 15:10:49 User:Nick Johnson
can see that comms fail between 10:38 and 10:51.
iCNIM has set a test timer of 787 (13 mins 7 seconds) and will not test the line during that time. Something else causes the line to
‘come up during that time (10:57) CNIM tests the line and the ping works.
(One thing of note is the very long ping reply times which indicate poor comms.
il suspect CNIM is working as planned where it is required initially to wait 5-15 minutes before testing the line.
IDate:29-May-2007 11:03:43 User:Peter Ambrose
\Forwarding to EPOSS Dey for further investigation on the behaviour of Riposte.
\Date:29-May-2007 11:03:59 User:Peter Ambrose
{The Call record has been transferred to the team: EPOSS-Dev
F/414.1/8
FUJ00086828
FUJ00086828
\Date:30-May-2007 16:56:28 User:Mike Coon
il think that Kath Greenwood forgot to "check with Mike Coon on his return next week", not that I can shed any deep light on the
problem.
IExcept on the matter of timeouts.
1) The primary timout of 32 seconds that Anne Chambers mentions is unfortunately not independent of the Riposte "Notify" (of the
rival of the [A3]) process. The timeout period is a parameter to that call, so if Riposte hangs, possibly "waiting for lock", then
maybe the 32-second timeout is also suppressed, leading to the counter freeze. (I happen to be looking into this area for the HNG-
/Horizon hybrid with PCI per CP4305. That version won't use Notify and will therefore have an independent timer.)
2) In addition to the 32 second timeout there is a "600" (probably seconds) timeout for NBRequestReply.dll which is policed by
[BFramework.dll. This has long thought to be dodgy and though it attempts a recovery process to tidy up the transaction it may be
faulty. The ten-minute timeout is set so long to ensure that it is hardly ever allowed to expire. Steve Evans has been studying this, or
related problems under long-standing PEAK 96719 and also 128872 and 134587. However it may be the reason why the counter can
ake up several minutes after the initial freeze.
\Date:04-Jun-2007 17:23:04 User:Mark Scardifield
iI am concerned that this problem is not readily reproducible and any potential (speculative) fix is likely to be fairly invasive. The
ost obvious change would be to introduce a timer that is separate from Notify as suggested by Mike Coon above. This will change
he way that every single on-line transaction is handled so significant testing would be required. Any change to the NB Framework
has to be considered as risky.
iI would like to get a view "pre-RME" whether we would be happy to contemplate this scale of change before we invest more time
land formally propose a change via RMF.
(Date:05-Jun-2007 10:38:38 User:Mike Coon
\A possible alternative to the one suggested above by Mark Scardifield (replacing the Notify timer with an independent one) would bel
‘0 tidy up (one-line code change) NBFramework so that it does not loop when it times out a component. Then we could be justified
in reducing the configured timeout period for NBRequestReply from the present ten minutes to say one minute.
IHowever this timeout is still rather "brutal" and does not provide for any recovery actions such as resetting the PIN pad or
uggesting that the Clerk tells the customer to retrieve their ICC card. This clumsiness may be acceptable for a rare occurrence; it
ican easily be worked around and the PIN pad can be reset by subsequent actions.
{However it is not clear whether the transaction recovery is really adequate in this circumstance. This could be investigated under the
jumbrella of PCI but would have wider relevance than PCI in that it could apply to ETU transactions as well as NBS and DCS.
IBTW it is not understood in EPOSS Dev why this whole problem appears only with Banking transactions. Surely the whole Riposte
jand comms path is identical for ETU? Could it be that ETU transactions are equally implicated but are just not as apparent for some
‘eason?
IDate:06-Jun-2007 09:34:48 User:Mark Scardifield
[Routing to RMF - not for authorisation because we (Dev) haven't proposed a fix yet - but to discuss the cost/benefit and likely
timing of making a NB Framework change before committing more effort to investigating potential fixes.
\Date:06-Jun-2007 09:35:01 User:Mark Scardifield
‘The Call record has been transferred to the team: RelMngmntForum
F/414.1/9
FUJ00086828
FUJ00086828
iDate:07-Jun-2007 11:46:04 User:John Budworth
/Extracts from two mails from Mik Peach of SSC read;
1/ From Mik Peach of SSC to Release Management (for RMF)
For 145617 I accept that we are unlikely to get a fix from Escher, and even if we got one, we are unlikely to implement it. I also
agree that the "brutal" changing of timers is more likely to cause problems than to solve them - so I am in agreement with
idevelopment that they should not attempt to fix the problem. However, even though we know that we can resolve the underlying
etwork problems by switching the site to "always on", there is a cost associated with doing this, and we are trying to migrate sites to
idial-on-demand.I think that the easiest way to handle this is to agree not to produce a fix, but to flag to Graham Welsh and Alex
‘Kemp that there may be an ongoing requirement to "juggle" the networks with problem sites as a result of this decision.
}2/ From Mik Peach of SSC to Graham Welsh (Head of Service Transition) and Alex Kemp (Network Service Manager).
investigation into Peak 145212 and a clone of same (145617) has identified a problem which can cause counters to suffer an
proximate 8 minute "hang" during online transactions. The underlying root causes of this are intermittent network issues on a dial-
n-demand circuit, coupled with a Riposte timer issue. Given that we are unlikely to get a fix from Escher, and even less likely to
implement one even if we got one, and given that the only alternative in the counter code would require a counter release of a fix
described as "brutal", with possible side effects; the SSC recommendation to RMF is that we do not attempt to fix this problem. We
ave a work-round, which is currently to switch any such problem-site out of dial-on-demand to always-on; actually in the case of
ithe specific PO raising the call, we switched them to ADSL. Initial investigation has shown that the problem is affecting 10-12 Post
\Offices, who are getting the symptoms 2-3 times per week.
\For the sites which have this problem, and which remain on ISDN, we will have the alternative of switching to Silver FRIACO.
service type 7) or metered FRIACO (service type 9).
appreciate that BT and POL have been slower than anticipated in the ADSL roll-out, and I understand the pressure to switch to
idial-on-demand. However, I believe that, although there will be a cost to CS in using this workround, it would be more cost-effective}
han the alternatives.
iRouting back to EPOSS-Dev for a final response that will route call back to SSC for closure.
(Date:07-Jun-2007 11:46:41 User:John Budworth
‘The Call record has been transferred to the team: EPOSS-Dev
\Date:07-Jun-2007 14:19:43 User:Mark Scardifield
{Start of Response]
(Returning for closure as discussed above.
{End of Response]
'Response code to call type C as Category 64 -- Final -- Published Known Error
iRouting to Call Logger following Final Progress update.
[Date:16-Mar-2010 14:24:39 User:Chris Hawkes
\Defect cause updated to 7 : Design - High Level Design
iDate:16-Mar-2010 14:24:42 User:Chris Hawkes
“ALL PC0145617 closed: Category 64 Type C
Root Cause Design - High Level Design
Logger ; Deleted User -- EDSC
Subject Product Network Banking -- NB Counter (version unspecified)
Assignee Deleted User -- EDSC
Last Progress 16-Mar-2010 14:24 -- Chris Hawkes
F/414.1/10