FUJ00225752
FUJ00225752
From: Selwyn Sarah[/O=EXCHANGE/OU=ADMINGROUP 1/CN=RECIPIENTS/CN=SELWYNS]
Sent: Wed 17/11/2010 9:29:42 AM (UTC)
To: Parker Steve (PostOfficeAccount
Ce: Munro Donnaf,
Barnes Gerald.
Jenkins
Subject: RE: ARQ calls - further to yesterdays rant...........
Attachment: Sysman3Events.xls
Steve,
Items a) to c) below are covered by the Audit Retrieval HLDs, user guides and support guide and were agreed and signed
off as part of the HNG-X release 1 and 2 designs.
However, I understand that for Audit Retrieval Queries (ARQs) where event files are required by the Post Office that the
SSC are required to analyse very large volumes of BAL Sysman3 HNG-X events to determine if there are any financially
significant events and that these events could be presented in a more helpful format. During Horizon live operation effort
was expended iteratively determining Horizon events that were of no financial significance for Horizon ARQs and these
events were then filtered out into a benign events file (which was also available to SSC if required). The benign events
(see attached spreadsheet for HNG-X benign events if you don’t have permission to access this Wiki)
As you can see there are only two HNG-X BAL alertgroup/alertkey (event types) defined as benign for filtering out (many
more were determined for Horizon). I think the time has come to get the BAL/OSR experts involved to advice us on what
could be interpreted as definitively benign and filtered out to reduce the number of events that the SSC need to analyse. I
will shortly send out an invitation for a workshop. Meanwhile, we need some sample events as supplied to the SSC to use
in the workshop to at least start to identify the events with AndyT and Martin.
The format of the event spreadsheets supplied by the Litigation Team can be improved by including a sheet header and
this can be handled by a PEAK (as discussed below) in the long run and in the short term can be supplied as an xls
proforma by Audit Dev for the Litigation Team to use in producing the events files. The xls filenaming improvements are
discussed as a change to the Litigation process below.
I think we should discuss d) and e) in a different meeting since reducing the number of events the SSC need to analyse
appears to be your top priority currently (correct me if I am wrong here please Steve).
Thanks and regards,
Sarah
From: Parker Steve (PostOfficeAccount)
Sent: 16 November 2010 16:42
To: Selwyn Sarah
Cc: Munro Donna; Thomas Penny; Barnes Gerald
Subject: RE: ARQ calls - further to yesterdays rant...........
Sarah,
I think it will be worthwhile to discuss this in more detail?
In particular:
a) What types of data are currently retrieved as ARQ requests
b) Are all the types still relevant at HNGX
c) Are any types missing
d) How do we ensure that we have a very lightweight process to change existing audit filters
FUJ00225752
FUJ00225752
e) Review existing SSC WI
Steve
From: Thomas Penny
Sent: 15 November 2010 12:45
To: Selwyn Sarah; Parker Steve (PostOfficeAccount)
Cc: Munro Donna
Subject: FW: ARQ calls - further to yesterdays rant...........
Sarah / Steve
I think we need some assistance here in the form of guidance from the system designers as to which areas we should be
examining for evidence of possible financial effects; I think we are all agreed that it is imperative that we provide
accurate audit records.
Could we please identify who we should consult for such guidance?
Kind regards
Penny
From: Barnes Gerald
Sent: 15 November 2010 10:16
To: Parker Steve (PostOfficeAccount); Thomas Penny
Cc: Miller Kevin; Simpkins John; Wright Mark; Selwyn Sarah
Subject: RE: ARQ calls - further to yesterdays rant...
Steve,
I refer to your first question as to whether BAL events are needed.
It was our original designer, Alan Holmes, who thought the BAL events could, in general, have financial
significance. I am sure he had very good reasons but you need to email him to find out what they are. I am not yet
knowledgeable enough in the end to end system from counter to Branch Database to know myself. To play Devil's
advocate though surely if there was a BAL event to say that a transactional message was not being passed on then this
must have a financial significance? However is this not just another example (used several times before) of where if you
examine a spreadsheet and discover events of a particular pattern to have no financial significance then your raise a
PEAK to ask for them to be filtered out? If, after due consideration, you think all BAL event can be filtered out then the
PEAK can say exactly that! Note that if you do ask for them all to be rejected then they will still be available in the
rejected events.
Regards,
Gerald Barnes
From: Parker Steve (PostOfficeAccount)
Sent: 12 November 2010 14:37
To: Thomas Penny
Cc: Miller Kevin; Simpkins John; Wright Mark; Barnes Gerald; Selwyn Sarah
Subject: ARQ calls - further to yesterdays rant...........
Penny, Gerald
We may be able to sort some of this by process and some by development change.
Firstly the dataset content is unusable:
FUJ00225752
FUJ00225752
The major issue. One of the sets we received recently (PC0205558) had 3 event files containing
4000+ lines. In all cases 98% of these were BAL We cannot expect anybody to eyeball 12,000 lines
of events, they will go boss-eyed!
Do we need to look at the BAL events at all?
Secondly, the format:
We used to get a Spreadsheet with a number of tabs with meaningful names viz:
1) Run details
2) Sysman 2 query run - details of the query
3) Sysman 3 Query run - details of the query
4) Sysman 2 FAD nnnnnn - Sysman 2 events for FAD nnnnnn with headings to define column content
5) Sysman 3 FAD nnnnnn - Sysman 3 events for FAD nnnnnn with headings to define column content
Then 4 + 5 repeat for other FADs if required.
We now just get a number of txt files added as evidence, all with the filename format "nnn Sysman n
Events.txt".
1) No indication of file content.
2) No indication of which two files are sysman 2 / 3 events for a given FAD
3 When you finally find the right pair of files containing FAD events the events are comma separated
but there are no headings to ensure that we interpret them correctly.
To get us back to useable format:
Litigation support need to:
1) Edit the files returned WITH events to add a first line with headings e.g.
“FAD","ActionTime",”ActionCode”,”Identitied”,”...etc.....", “i. etc...
The header line to be added would be the same for each data set of the same type (i.e. SYSMAN2 or
3) so would be constant values.
2) Import the comma separated fields into a spreadsheet TAB. The import would maintain the
headings added in (1)
3) Rename the tab to something meaningful (e.g. Sysman 2 FAD nnnnnn).
Repeat as required.
It’s not a lot of work IF it is done at the time the files are generated so that you know what the
content of each one represents. A Peak with development to get (1) done automatically would make
it even easier.
You just pass a single spreadsheet for each ARQ.
Steve
-----' Original Message-----
From: Thomas Penny
Sent: 11 November 2010 16:40
To: Parker Steve (PostOfficeAccount)
Cc: Miller Kevin; Simpkins John; Wright Mark; Barnes Gerald; Selwyn Sarah
Subject: RE: ARQ calls
Steve
Thank you for your note.
FUJ00225752
FUJ00225752
The change in format is due, as Raj rightly said, to the more automated method of retrieving
events. This is as detailed on the attached CPs. I've checked and I cannot see any impact
for SSC; this was in 2009 and long before there was any formal agreement for SSC to support
event analysis. I'm sincerely sorry but it didn't register with me that this would be more
labour intensive for your team.
I've copied in Gerald and Sarah who can obviously help with the technical aspects.
Perhaps once you've had the chance to review we could discuss.
Kind regards
Penny
----- Original Message-----
From: Parker Steve (PostOfficeAccount)
Sent: 11 November 2010 16:00
To: Thomas Penny
Cc: Miller Kevin; Simpkins John; Wright Mark
Subject: ARQ calls
Penny,
I'm concerned about the ARQ calls we have received recently.
In the past we have received a single spreadsheet. That spreadsheet had tabs for the
different data types and column headings which made it easy to understand which column
contained which data and made the data easy to manipulate, sort etc.
We have recently been receiving ARQ Peaks with a number of simple text files attached as
evidence, no file name convention, no formatting, no column headings and I suspect extraneous
data which we do not need to examine. This has significantly lengthened the time taken with
each of the ARQs.
Catherine asked Raj what the situation was and got the reply "With regards to the comments on
the above PEAK, evidence going forward is going to be in .txt format as we (Audit Team) will
be generating the events ourselves rather then it being done by Audit-Dev which used to be in
the .xls format."
Can you confirm what is going on here please Penny. If the comments Raj has made are correct
then the change of format has been neither explained nor agreed with the SSC. If there is a
new requirement for the SSC to process ARQs in this format then I will need to re-impact our
process and look to increasing headcount in order to do, what I consider to be, part of your
teams work.
Steve