FUJ00176331 -Peak Incident Management System Call Reference PC0268776, logged by Jason Muir on 03/04/2018 - “ARQ Failing due gaps - POO817B”

Evidence on official site

FUJ00176331
FUJ00176331

Peak Incident Management System
Call Reference PC0268776 Call Logger Deleted User -- Security Ops
Release Reported In -- HNG-X Rel. Ind. Top Ref
Call Type Problem Management Priority C -- Progress restricted
Contact Deleted Contact Call Status Closed -- Administrative Response
Target Date 08/04/2018 Effort (Man Days) 0
Summary ARQ Failing due gaps - POO817B.

Progress Narrative
patc:03-Apr-2018 14:01:45 User:Jason Muir

caLL PC0268776 opened
Details entered are:~

summary:ARQ Failing due gaps - P00817B
call Type:M

call Priority:¢

lfarget Release: HNG-X Rel. Ind.

Routed to:Security Ops - Jason Muir

oate:03-Apr-2018 14:01:45 User:dason Muir
lA fast ARQ is failing as it is reporting Gaps in the data, please could this be investigated. Meanwhile a slow ARQ will be run to
jobtain the data.

ery Handler .txt attached as evidence.

Many Thanks.

Jbate:03-Apr-2018 14:02:09 User:Jason Muir
levidence Added - QueryHandler Log

Jbate:03-Apr-2018 14:02:16 User:Jason Muir
Defect cause updated to 40: General - User

Date: 03-Apr-2018 14:02:33 Uscr:Jason Muir
the Call record has been transferred to the team: Audit-Dev
[the Call record has been assigned to the Team Member: Gerald Barnes

date: 24-May-2018 19:27:38 Uscr:Gerald Barnes

[Start of Response]

It have just checked and PO0817B is no long present. I need the FAD and date range to investigate this PEAK now.
{End of Response]

Response code to call type M as Category 40 -- Pending -- Incident Under Investigation

oate:24-May-2018 19:30:07 User:Gerald Barnes
{Start of Response]
It have found the FAD and date in the evidence.
{End of Response]
lkesponse code to call type M as Category 40

Pending

Incident Under Investigation

Date: 25-May-2018 10:59:00 Uscr:Gerald Barnes

[Start of Response]

It have started the slow ARQ OTH3881B with the same FAD code and dates to try and duplicate the issue.
{End of Response]

Ikesponse code to call type M as Category 40 -- Pending -- Incident Under Investigation

Hours spent since call received: 3 hours

Date: 30-May-2018 18:20:14 User:Gerald Barnes

[Start of Response]

I have duplicated the problem and I have been able to establish that the missing data is from the correspondence counters 37, 56
land 57 from the dates 14th - 21st June 2008.

It note that these correspondence counters are not the same as real counters and so no real counter data is lost.

i am rerunning the query on {IRRELEVANT
{End of Response]

esponse code to call type M as Category 40 -- Pending ~~ Incident Under Investigation
lfours spent since call received: 1 hours

© see if the same problem occurs there. In that case the query is OTH3334W.

FUJ00176331
FUJ00176331

Date: 31-May-2018 10:49:01 Uscr:Gerald Barnes
[Start of Response]
[here were no gaps shown in the fIRRELEVAN’
[End of Response] =

Response code to
tours spent since

audit server and so at least we can get the data from one audit server.

11 type M as Category 40 -- Pending == Incident Under Investigation
11 received: 1 hours

[Date:31-May-2018 10:49:24 User:Gerald Barnes
Defect cause updated to 14: Development — Code

Date:31-May-2018 10:56:43 Uscr:Gerald Barnes
[Start of Response]

there are indeed gaps in the data returned by They are only for correspondence server nodes and not actual counters.

there were no gaps in the data returned from { ot the same FAD and date range.
jow at Horizon messages were logged by independent processes and went into different files for Bootle and Wigan. The fact that
correspondence nodes only are missing rather indicates a bug in this process and not in the gathering of the files by the audit
system. If the audit system had missed out a file you would likely as not have gaps in the actual Post Office counters too.

lso I conclude that there is no evidence of a bug in the audit system. I also note ng.Past_Qffice Counter message is missing at
all and the correspondence server messages are only missing from

{End of Response]

Response code to call type M as Category 62 -- Final -- No fault in product
routing to Call Logger following Final Progress update.

tours spent since call received: 3 hours

Date:18-Feb-2019 14:53:39 User:Jason Muir

[Start of Response]

io fault found as advised by Gerald Barnes, therefore closing PEAK.

[End of Response]

esponse code to call type M as Category 68 -- Final -- Administrative Response
outing to Call Logger following Final Progress update.

jbate:18-Feb-2019 14:53:43 User:Jason Muir
IcALL PCO268776 closed: Category 68 Type M

Root Cause Development - Code

Logger Deleted User -- SecurityOps

Subject Product General/Other/Misc -- Unknown General/Other/Misc (version unspecified)
Assignee Deleted User -- Security Ops

Last Progress 18-Feb-2019 14:53 -- Jason Muir