FUJ00155238
FUJ00155238
From: Birkinshaw Roy[/O=EXCHANGE/OU=ADMINGROUP1/CN=RECIPIENTS/CN=BIRKINSHAWR]
Sent: Mon 25/08/2008 9:42:00 AM (UTC)
To: Jenkins Gareth GIf
Subject: I RE: Branch 141832 Craigpark
Agreed
Roy B
From: Jenkins Gareth GI
Sent: 22 August 2008 17:34
To: Birkinshaw Roy
Subject: FW: Branch 141832 Craigpark
Roy,
Looks like we need to come up with a response to POL. It was this customer request that started the whole thing. I
suggest we discuss on Tuesday evening.
Regards
Gareth
Gareth Jenkins
Distinguished Engineer
Applications Architect
Royal Mail Group Account
hire, RG12 8SN
ip://uk. fujitsu.com
Please consider the environment - do you really need to print this email?
This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu Services
does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free.
From: Stewart Mike
Sent: 22 August 2008 15:34
To: Jenkins Gareth GI
Cc: Chambers Anne O
Subject: RE: Branch 141832 Craigpark
Gareth, Re the workshop and the response I gave to Shaun on my action about how often this incident had
occurred. My response was if you remember was that we have only seen this occur 3 times in the estate (I think
I said in the last 3 years) Twice at Craigpark (once was benign) and once somewhere else which caused a
discrepancy.
Shaun is seeking further clarification of "What is the specific action, button pressed, timing of the rolling over""
that can cause the incident. His exact words were we must have 100s of PMs who do the Roll Over into the next
TP at around 19:00 at Harvesting time, so what is specific that Craigpark have had it twice. He needs to
understand the isuue to pass it onto his Fraud department as Craigpark is being investigated about other
discrepancies???.
PS I am aware of the other Security Audit being done into this issue so have only copied you and Anne.
Regards Mike
Mike Stewart SDM On-Line Services
FUJ00155238
FUJ00155238
Royal Mail Group Account/UK Private Sector
FUJITSU
Web" hitp:/iservices fujitsucom
Fujitsu Services Limited, Registered in England no 96056, Registered Office: 22 Baker Street, London, W1U 3BW
This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu
Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free.
Jenkins Gareth GI
04 August 2008 13:19
Stewart Mike
Drake Claire; Peach Mik; Card Cheryl; Chambers Anne O
Subject: RE: Branch 141832 Craigpark
Mike,
I’ve now had a read through the PEAKs that Anne quotes.
'm slightly surprised that this problem has only occurred 3 times and twice in one branch (though in the 13" Feb
case it was benign). My understanding is that a “red event” would be generated by the problem which ought to
result in SMC raising a call (depending on exactly what KELs say for this). However it may well be that such “red
events” are generated in other circumstances and so are not that easy to spot in isolation when trawling through
the counter events (1 need guidance from SSC on this). Note also that if the bug occurs, then there would be a
Receipts and Payments mismatch which ought to result in a call to NBCS which would be passed to HSD (that
happened for the occurrence at the other branch, but not for Craigpark).
Is it practical for SSC to carry out periodic checks for this event (say a weekly query on the event database) and
in particular look for those occurring between 18:59 and 19:30 which might be a symptom of this issue? If so this
would be significantly less risky than a bug fix given the low number of occurrences. I understand what is being
proposed for the bug fix and if it were to go wrong could impact the whole estate so avoiding such a fix sounds
like the correct decision. However I doubt if POL would have been involved in that decision. Given the incidents
we were discussing on Friday, we do need to be able to re-assure POL that we would spot any further
occurrences and have a mechanism to correct the accounts (if necessary) even if we don't fix the root cause.
Regards
Gareth
Gareth Jenkins
Distinguished Engineer
Applications Architect
Royal Mail Group Account
FUJITSU
Lovelace Road, Bracknell, Berksh
ip://uk fujitsu.com
ss Please consider the environment - do you really need to print this email?
This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu
Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free.
FUJ00155238
FUJ00155238
From: Stewart Mike
Sent: 04 August 2008 11:46
To: Jenkins Gareth GI
Cc: Drake Claire; Peach Mik; Card Cheryl; Chambers Anne O
Subject: RE: Branch 141832 Craigpark
Gareth, Seeing as I had an action to report on this incident in that it had happened twice at this office
(although re Anne's note it only affected the balancing once), I can report to POL that we have seen this
twice in the estate, but do I report that we have a fix for it? Also do you know if it was a joint by us and
POL not to fix it as there were only 2 incidents.
Regards Mike
Mike Stewart SDM On-Line Services
Royal Mail Group Account/UK Private Sector
FUJITSU
Lovelace Road, Bracknell, Berkshire, RG12 8SN
vices Limited, Registered in E
6, Registered Office: 22 Baker Street, London, W1U 3BW
This e-mail is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be
privileged. Fujitsu Services does not guarantee that this e-mail has not been intercepted and amended or that it is virus-free.
From: Chambers Anne O
Sent: 01 August 2008 15:49
To: Jenkins Gareth Gl; Stewart Mike
Ce: Drake Claire; Peach Mik; Card Cheryl
Subject: Branch 141832 Craigpark
Sorry Gareth I should have remembered this one since I have been asked about it several times.
The query, and several responses, are on PC0158102. This explains in some detail that the problem
occurred just once. A Riposte Lock event was generated on this and one previous occasion, but I
explained that on the earlier occasion it had not affected the balance (I had visions of being in court
explaining the event log again).
The cause of the underlying problem is known, see PC0152376, which is the only other known instance,
at a different branch, where it has caused an R&P mismatch. There was also a problem with the same
root cause at a third branch, where the figures were ok but DEF did not roll over.
There is a fix available, but given the low incidence of problems (and the errors introduced on the back of
other fixes) it was decided not to implement it. But maybe, since we have no way of monitoring for it, and
R&P mismatches may not be reported by the PM, this decision should be reviewed?