FUJ00081135
FUJ00081135
To: Wright Mark}
Ce: Stewart Mike __
From: Jenkins Gareth GI
Sent: Thur 9/30/2010 4:15:40 PM (UTC)
Subject: RE: Receipts & Payments.
Bansal Steve (BRAO1!
All,
I’ve now had the Events back from Security and had a chance to look at them. A few points to note:
1. There seems to be a fairly clear pattern, namely
a. One or more 902 Events as a SU is balanced and the bug takes effect.
(I'm not sure I understand why there are sometimes multiple 902 events and perhaps we need to investigate
this further.)
b. One or more 903 events when the BTS is produced (often some time later)
(The reason for multiples here are probably as a result of them noticing a problem, abandoning the rollover
and trying again.)
Looking at the 902 / 903 events, those from July onwards all seem to follow this pattern.
There is also one Branch 436217 in March that follows this pattern which is not in the Spreadsheet (but the events would have
been archived from BRDB but should still be in BRSS though may have been lost due to Streams issues)
4. However there are a number of Branches up to May 5" where there are 902 Events and no 903 Events which suggests a totally
separate issue which ahs been fixed. There are 194 such events affecting 64 different branches.
There are no 902 or 903 Events between 6/5/2010 and 1/7/2010 which seems odd. I’m checking this out.
There are 2 Branches for which we have application events and no NT 903 / 904 Events (148025 and 113459)
There are 2 Branches in the list which don’t have 902 events and so may be a different issue. These are 122946 and 374632
and so perhaps need checking to confirm that this is the same issue. (It may be that the 902 events were lost or it could be a
different issue.)
8. There are 2 Branches not in the original list (222311 and 238320) with 902 events and no 903 event. This indicates a Branch
that has not the problem but not yet produced the BTS
9. The event analysis has therefore only identified 3 other instances (see 3 and 8 above). This means we can be confident that
looking for Events 117 does pick up the problem once the BTS is rolled, while looking for Event 902 will pick up the problem as
soon as it actually occurs.
10. As indicated below there are a number of other branches reported on the master Peak. However lets wait until POL ask us to
fix something before worrying about adding them into the list.
yn
NOH
Regards
Gareth
Gareth Jenkins
Distinguished Engineer
Applications Architect
Royal Mail Group Account
itp: 7uk Fajitsicom
s&s 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: Wright Mark
Sent: 30 September 2010 09:31
To: Jenkins Gareth GI
Cc: Stewart Mike; Bansal Steve (BRAO1)
Subject: RE: Receipts & Payments.
FUJ00081135
FUJ00081135
8) This one is part of a GUI tool written in java.
9) Thats what I thought. (it's in those reports anyway)
I would suggest that we wait until we know what POL want us to do before we collect any more info for the new offices. If
they want us to fix them them we will do a full sweep at that point, then we will enter BAU, fixing any new ones as the peaks
are raised from the eventing team.
Regards,
Mark.
From: Jenkins Gareth GI
Sent: 30 September 2010 09:13
To: Wright Mark
Cc: Stewart Mike; Bansal Steve (BRAO1)
Subject: RE: Receipts & Payments.
Thanks Mark,
Some follow ups:
8) I'll follow this up with you next week when Penny is back. What you have looks like a useful basis for what is
needed. What is the underlying technology?
9) We'll need this data at some point to do the fixes, but it isn’t important for now.
10) I’ve now done that and there is a complete match for the available events other than the fact that there is no
event for Branch 113459 (412420 was also a different value, but that’s a different problem!) which is
encouraging
11) I've cloned the Peak as 2048899 and sent it to Security Ops.
12) For the scenario we had it was an Insert. For Live cases it depends upon which BP the SU is in when it is
fixed. There may be a mixture of Inserts and Updates (and when an Update occurs we will need to read the
current value and do an Update to adjust it by the appropriate amount — so Inserts would be much easier). I
believe that if the SU being fixed is in BP 1 then the fix will always be an Insert. It is when BP is more than 1
and there have been Discrepancies carried forward from earlier BPs that we will need an Update.
I also see that a number of other examples have been added onto Peak 204765 this morning, presumably as a result of
yesterday's rollovers. These will need to be captured and added into the spreadsheet. Is this something you will do
periodically?
Regards
Gareth
Gareth Jenkins
Distinguished Engineer
Applications Architect
Royal Mail Group Account
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.
FUJ00081135
FUJ00081135
From: Wright Mark
Sent: 29 September 2010 17:37
To: Jenkins Gareth GI
Cc: Stewart Mike; Bansal Steve (BRAO1)
Subject: RE: Receipts & Payments.
7. Yes.
8. Yes. see the samples attached. I'm sure we can come up with a suitable arrangement.
9. I extracted the data for the first half and didn't write them down so didn't have them to hand when Cheryl sent me
the spreadsheet with the ones she had done. I didn't think it was worth adding them at the time as the figures were
more important, but if needed they are available in the attached reports.
10. No.
11. Not as far as I know. If you think it needs to get started then I would suggest cloning the peak you have and
sending it to Penny with the request details.
12. Do you mean ‘insert’ or is it an ‘update’ ?
Cheers,
Mark.
From: Jenkins Gareth GI
Sent: 29 September 2010 17:14
To: Wright Mark
Cc: Stewart Mike; Bansal Steve (BRAO1)
Subject: RE: Receipts & Payments.
Mark,
A bit more info and also some questions on the data in your spreadsheet:
1. I can confirm that Event 116 is generated when there is a Receipts Payments mismatch on a Trial SU
Balance. The way the bug works means we only get Receipt Payments mismatches on Final SU balances and
so that is why you've not found any 116 events. (Good news in that means there aren't other bugs around for
Receipts Payments mismatches!)
2. Event 117 is generated when there is a Receipts Payments mismatch on a Trial Office balance. Therefore if
the User sees the Receipts Payments mismatch and so abandons the Office Rollover and then tries again later,
this would explain the duplicate events. In one case (Branch 138824) the second attempt was over a week
later!
3. The SU name on the event 117 is irrelevant. It reflects the SU to which the User is attached when rolling over
the Branch. In some cases the User (or even different users) have tried the Branch rollover attached to
different SUs
4. Therefore I think we can ignore the duplicates you have highlighted in green since these are all for the same
TP rollover.
As you say Branch 412420 is a totally different problem and so can be ignored.
I think this means we have 39 affected Branches that have actually rolled over into a new TP. Note that by
looking at the Rep Event data we can only detect the problem for Branches that have hit the problem for a stock
unit and then rolled the branch over into a new TP.
7. Where does the data in cols G and H come from? Is this done by looking at the data in
BRDB_RX_REPORT_REPRINTS?
8. Asan aside, have SSC developed a tool to convert the data from BRDB_RX_REPORT_REPRINTS into a
readable text file since I’m looking for such a tool to help Penny in prosecution support.
9. Why is Col H only populated for the September occurrences? Is that just a case of work in progress?
10. Has this been correlated with the available NT events 902 and 903 that you sent out last week? (NB what you
sent out were just the 903s. 902 events should indicate when a SU actually hits the problem while the 903 / 117
may be some time later.)
11. Is anybody following through with Audit to retrieve older 902 / 903 events?
12. Dev have now reproduced the scenario and applied the proposed fix (by inserting data into BRDB) and it
appears to work in the simplistic case we set up so it looks like we do have a formula to correct the data if POL
want us to do that.
Regards
Gareth
Gareth Jenkins
FUJ00081135
FUJ00081135
Distinguished Engineer
Applications Architect
Royal Mail Group Account
Jfuk. fujitsu.com
eS Please consider the environment - do you really need to print this email?
England n
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: Wright Mark
Sent: 29 September 2010 14:48
To: Jenkins Gareth GI; Stewart Mike; Bansal Steve (BRAO1)
Subject: Receipts & Payments.
Please see the attachement which is the list I had with me earlier to which we have added the trading
position figures (BTS Trading position column).
We have now found some as negative so that is cleared up. One thing to note is that the Stockunit
mentioned in the BRDB event is not necessarily the stockunit affected... my guess is that it is the currently
attached stock unit.
Anyway at least this gives us some monetary figures for POL when we have the talk.
Regards,
Mark.