POL00001197
POL00001197
Peak Incident Management System
FSTK_2_0_WP24106
B -- Business restricted
STK 2 0 WP23673
‘PC0128969
‘PWY_WP_23673
Originator: Phelp
Product Type: Riposte
Product Serial No:
Product Site: 147136
ontacted
21/12/08 17
contacting pm - does not accpet incoming calls
20 uk955547
, using bat phone - number busy
contacted pm- pm statse rolling over tp w
figures showing but allowed to roll over and on the
there was a £18000 discrpancy ga
uk955547
no items, 0
xt
rb
#21/12/05 17:29 uk955547
Information: downloaded ps standard log file id : 701747
421/12/05 17:34 uk955547
Recommend: Please investigate into M's zero value- see lod for details
21/12/05 17:34 SYSADM
F/323/1
POL00001197
POL00001197
fOpen OTT: Automatic Open OTT
e*updated by Akram Ali at 21/12/05 17:34:56
21/12/05 17:34 uk955547
FREASSIGN: Call # B-0512210763 was Reassigned from Akram Ali, Group
SH2 to Group EDSCL
te:22-Dec-2005 08:13:42 User:Cheryl Card
eference Added: $$ Card!
‘Date:22-Dec-2005 08:20:18 User:Cheryl Card
Product EPOSS & DeskTop -- Balancing added.
Date:22-Dec-2005 08:20:29 User:
Whe Call record has been assigned to the Team Member: Cheryl Card
Progress was delivered to Powerhelp
1
Date:22-Dec-2005 09:23:18 User:Cheryl Card
Whe call summary has been changed from:
ibm statse final balance of stock unit rollover con
‘Whe call summary is now:
PAD147136 - stock unit balance report all zeros
Date:22-Dec-2005 09:23:45 User:Chery] Card
Date:22-Dec-2005 16:05:15 User:Cheryl Card
[Start of Response]
Whe following is a copy of an email sent to Julie Welsh and Jez Murray, who will contact an appropriate person in POL so that
2 dec: an be made on the course of action to be taken
ion
FAD 147136 is a 5-counter site with 7 stock units. On 14/12/05 the M started the process of rolling over stock unit BB. He
sot as far as previewing the Trial Balance, made a few adjustments, then left it logged in until the following day.
n 15/12/05, he previewed the Trial Balance again but it contained only zero values. He rolled over the stock unit regardless,
nd later that day rolled the office into TP%. The Branch Trading Statement also shows zero values for stock unit BB and a non-
zero Trading Position.
‘Stock unit BB was rolled over in an effectively empty state. The PM then declared the correct amount of cash, and adjusted the
istock levels up to the correct volumes. This has resulted in a gain of approximately £18000.
Je are unable to
rrect the system figures safely. We can however provide accurate figures for what should have been in the
‘Final Balance for BB, to enable POL to make the correction perhaps by using a Transaction Correction.
POL need to make a decision on whether they are able to correct the problem in this way, however we do not see any other
alternative. Corrective action should be taken before llth January when the branch is due to roll into TP10.
ihe cause of the problem is unknown and is under investigation.
(End of Response]
Response code to call type 1 as Category 40 ~~ Pending -- Incident Under Inves
Response was delivered to Powerhelp
[Hours spent since call received: 0 hours
i
i
pate:22-Dec-2005 16:58:19 User: Chezyl Card
Bvidence Added - Nessagastore, logs, SP and BIS reports
pate: 22-Dec-2005 16:89:39 User :Gharyl. Gard
be te:22-Dec-2005 17:02:56 User:Cheryl Card
[[start of Response]
his has occurred before ~ see PC0128969. Development were unable to reproduce the problem, so call was closed. Problem needs
co be re-investigated as it has happened again.
marc
‘Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Powerhelp
22-Dec-2005 17:03:17 User:Cheryl Card
all record has been transferred to the team: QFP
Date:23-Dee-2005 10:02:33 User:John Simpkins
¢ Call record has been transferred to the team: EPOSS~Dev
@ Call record has been assigned to the Team Member: Mark Scardifield
F/323/2
POL00001197
POL00001197
fprogress was delivered to Powerhelp
Date:03-Jan-2006 11:33:05 User:David Seddon
[Start of Response]
Problem has occurred again at another office (See PC0130461). Single counter office, node disconnection during balancing, final
balance contained all zeros and on next rollover discrepancy of over £20,000.
ind 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:03-Jan-2006 12:00:25 User:David
[Start of Response]
Raising call to an 'A' priority as we have now had at least three instances of the problem.
dcion,
If we get to the problem before the office is rolled we are able to change objects in the messagestore to reset the stockunit
back to the CAP (TP) rollover trailer. The PM can then rollover. PM should get a large shortage which cancels out the large
ain.
je don't want to be having to do this as making manual changes to the messagestore is open to error and each time we have to
eek authorisation from POL to make the changes.
If we get to the problem after the office is rolled (as in this call) then we are unable to correct the system figures safely.
[Its not been decided how we get the PM sorted out.
11 in all, we want this fixed asap.
[Bnd of Response}
Response code to call type L as Category 40 -- Pending -- Incident Under Investic
Response was delivered to Powerhelp
jours spent since call received: 0 hours
Date:03-Jan-2006 12:00:31 User:David Seddon
Whe call Priority has been changed from B
‘he call Priority is now A
Date:03-Jan-2006 17:18:58 User:Mark Scardifield
‘Whe Call record has been assigned to the Team Member: Gerald Barnes
ogress was delivered to Powerhelp
Date:03-Jan-2006 17:19:09 User:Mark Scardifield
Whe Call record has been assigned to the Team Member: Gerald Barnes
Progress was delivered to Powerhelp
Date:05-Jan-2006 11:45:06 User:Tyrone Cozens
Whe call Target Release has been moved to Targeted At ~~ BI_3S82R
Date:05-Jan-2006 11:45:43 User:Tyrone Cozens
[Start of Response]
1200127070, PC0130275 and PCO130216 all authorised for S82R after discussion in Prayers and advised by Graham Welsh. Lionel,
please route to c
[lend of Response]
Response code to call type L as Category 56 Pendin:
Hours spent since call received: 0 hours.
rrect team, thanks.
- Live Fix Authorised
Date:05-Jan-2006 11:46:11 User:Tyrone Cozens
apologies, already with correct team.
Date:05-Jan-2006 11:49:43 User:Tyrone Cozens
Please ignore my update, this should not have been
for S82R.
sthorised
yet, only PC0127070 and PCO130216 should have been authorised
Date:05-Jan-2006 11:50:05 User: Tyrone Cozens
the call Target Release has been moved to Reported In
sg
Jate:09-Jan-2006 09:45:05 User:Cheryl Card
[Start of Response]
etting status
[End of Response]
esponse code to call type L as Category 40 -- Pendin
Response was delivered to Powerhelp
Mours spent since call received: 0 hours
to Under Investigation
- Incident Under Investigation
ate: 11-Jan-2006 15:38:49 User:Cheryl Card
widence Added - Corrected final balance for stock unit BR, and corrections to TPB BTS
Soe
F/323/3
POL00001197
POL00001197
y
fate:11-dan-2006 15:45:28 User:Chery] Card
[Start of Response]
Stock unit BB has been rolled over successfully on an SSC test counter.
POL have been advised that the exac the gain is ?18238.90, made up of:
ash 213258.61
ther postage items 2615.28
tock to the value of 24365.01
Whe branch will settle the gain as an ‘Emergency Payment’.
whe new final balance for BB, corrections to the BIS, and detailed calculations for determining the exact figure for the gain,
re attached.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Powerhelp
jours spent since call received: 0 hours
value o
Date:12-Jan-2006 11:17:01 User:Cheryl Card
Stock unit BB has now been successfully rolled over into TP10.
POL are asking for the root cause of this error, has any progress been made?
Date:12-Jan-2006 12:06:21 \ser:Gerald Barnes
[Start of Response]
I imported the supplied message store to a date and time of 14-Dec-2005 18:53:32, added an extra bit of subscription group
data needed to do rollovers (no subscription groups are supplied), brought up the Desktop, went into Stock Unit balancing and
left the screen open. I then ran end of day and advanced my system clock to 08:00 the next morning without logging out.
a
I then duplicated the probler
The problem in my case was that the EPOSSBalance Parameters object (<Message:<GroupId:147136>
‘Id: 39><Num:171355><Date:14-Dec-2005><Time:22: 16: 50><Expiry: 7><TranStartNum:171355><Collection: EPOSSBalance>
‘ObjectName:Parameters_00><StartDate:01-JAN-1996 00:00:01><EndDate: ><RData: <Data: <StockRootNode: 3008><StockRootNodeLevel :4>
‘BalanceRootNode : 3017><CashVariancesRootNode: 1001><BalanceRootNodeLevel : 5><CashVariancesRootNodeLevel :1>
‘Ba lanceDynamicLevelRootNode : 5050><Brought ForwardPrimaryMappings : <L1:><L2:><L3:><L4:3009><L5 : 3017>>>><Depend: False><Version:2>
CRC:68294487>>) was after the time of my import and, no doubt due to scavenging before the message store was supplied to me,
as the only one present.
I think there must have been a drop of that object that evening £#8211; there would have been an earlier one before that.
I do notice that for the cross referenced PEAK PC0130461 this object was dropped the evening of the problem as well; however
it was not the case for PEAK PC0128969.
I can not help feeling that this reference data drop must have been the problem for at least two of the PEAKS;
et figure the mechanism as to exactly how.
but I can not
nd of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
jours spent si
Date:12-dan-2006 1
‘Reference Added
Date:12-Jan-2006 1.
[Start of Response]
nother occurrence, see PCO130855.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident U
Response was delivered to Powerhelp
jours spent since call received: 0 hours
der Investigation
Date:17-Jan-2006 1.
[Start of Response]
I tried to reproduce the scenario in PEAK PCO130855. I set up a dual counter system. I imported the supplied message store to
a data and time of <Date:04-Jan-2006><Pime:18:26:43>. I reran the Stock Unit balance as far as the final screen on counter 1.
I ran EOD on both counters. I advanced my system clocks until 3:00 am and bounced counter 2 and its message store. I advanced
y system clocks until 09:00 and completed the balance. Nothing went wrong this time. The most significant difference that I
noticed that in the morning on the new run no query was made immediately before the production of the first set of Opening
Figures whereas in the failing run one was. Far more initial opening figures were produced in the new run then the failing
run. I have not been able to figure out the mechanism by which the extra initial query was made yet but I think this may be a
‘common thread in all these problems I will study again one of the other case to try and give some inspiration.
[End of Response]
Response code to call type L as Category 40 -- Pendir
e ived: 14 hours
Gerald Barnes
g -- Incident Under Investigation
Date:18-Jan-2006 16:09:03 User:Gerald Barnes
[start of Response]
I tried to reproduce the scenario in PEAK PC0130461 by importing the message store to the time <Date:14-Dec-2005>
<Time:17:55:19>. This test example gave problems due to persistent objects which had been replaced and their predecessors
larchived - for example EPOSSBalance Parameters and _EPOSSNodes 2570 01 and so was not convenient to study. I shall go back to
isdudding Pc0128969.
[Bnd of Response]
sponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
jours spent since call received: 8 hours
F/323/4
POL00001197
POL00001197
y
iDate:20-Jan-2006 12:32:40 User:Gerald Barnes
[Start of Response]
I went back to look at PC0128969. This had me very puzzled initially. I could not understand how you get Node Disconnection
messages on a single counter Office. However the explanation is that the office has a node 1 and a node 31 and so from the
boint of view of EPOSSWatchDog is not a single counter office. I suspect that node 31 is a mirror disk.
I set up a dual counter system with nodes 1 and 31 and imported the supplied message store to a date and time of <Date:09-Nov-
005><Time:13:09:20>, I added the AccountingPeriods persistent object since no subscription groups had been supplied.
I then went through the rollover process for stock unit AA but pulled out the network cable whilst previewing the trial
balance. After the preview had been dismissed a disconnection message appeared on the counter. After a few seconds I
reconnected the counter. I acknowledged the disconnection message and then the connection message that appeared underneath it
nd continued the balancing process. Nothing went wrong.
I repeated this experiment but deliberately tried double clicking the buttons that appeared after the network messages had been
acknowledged. I could still get nothing to go wrong.
lence I am starting to run out of ideas on this PEAK.
‘The common thread on all of them is that node disconnection and connection messages would have appeared on the balancing
creen and after that point you can see from the audit log that a tree build occurs (additional to the ones that occur in my
ttempt to duplicate the problem) and after that thin
S go wron
[Bnd of Response}
Response code to call type L as Category 40 -- Pending ~~ Incident Under Investigation
jours spent since call received: 14 hours
Date:09-Feb-2006 1:
[Start of Response]
I have almost certainly now found the mechanism for this problem; though one minor detail needs further work.
In EPOSSStockUnit clsStockUnit is a method ProcessReConnection which, since $80, is called when the clerk acknowledges the
reconnection message. This under certain circumstances rebuilds the tree. However in balancing the tree has been frozen and so
if it is rebuilt by this code (which does not unfreeze it) in these circumstances all data is stored in a different place
Mithin each object within the data tree than usual (dValueChangeWhileFrozen rather than dCurrentValue for example) so that when
che tree is accessed later zeros are returned.
11 the observed facts are fitted by this explanation; the problem only happens on node reconnection, there is always an extra
cree build which appears to be populated from the audit log and zeros are retrieved from the built tree. I have duplicated the
problem by forcing code down the rebuild path in these circumstances.
I am now trying to figure out how the test done on reconnection is fooled into thinking a tree build is required; it is not
when I rerun with imported messages stores.
Glnd of Response]
esponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
jours spent since call received: 20 hours
Date:10-Feb-2006 1.
[Start of Response]
I have only found one possibility for how this problem would come about and that is the bit of code
1:39 User:Gerald Barnes
"StockUnit attachment has not changed whilst disconnected
Tf objStockUnit.intCAP <> iLocalCAP Or _
bjStockUnit.intBP <> iLecalBP or
bjStockUnit.fbIsCurrentInTPMode <> bLocalSUInTPMode Then
"Locally out of sync with message store - refresh local state
eSaveStockUnitProperties objStockUnit
fRefreshCurrentFigures sStockUnit
fUpdateDesktopIdleltems objStockUnit, sCurrentUser
If objStockUnit.fbIsCurrentInTPMode <> blocalSUInTPMode Then
"TP mode has changed so refresh desktop buttons
RefreshButtons = True
ithin ProcessReConnection of EPOSSStockUnit is being executed within the balancing process. It is the case that the outer
st is hit in all 4 cases observed. However in fact the inner block (which would give rise to all the symptoms observed
448211; the extra tree build apparently populated but returning 0s) is not hit in my reruns.
I therefore propose a new release of EPOSSStockUnit with extra audit lines within the if test to print out all relevant
comparison variables to see whether this is genuinely the cause of the problem and to give some idea as to how the problem
ame about if it is.
‘he effect on performance of these trace lines would be negligible because they would only be output on network
disconnection/reconnection.
Tt would only take 1 man day to code and test this extra diagnostic.
[End of Response]
Response code to call type L as Category 40
jours spent since call received: 7 hours
- Incident Under Investigation
F/323/5
POL00001197
POL00001197
Date:10-Feb-2006 13:02:37 User:Gerald Barnes
Ime call record has been transferred to the team: RelMngmntForum
3 was delivered to Powerhelp
‘Date:10-Feb-2006 17:07:06 User:John Budworth
IThis needs to be discussed at prayers on Monday 13th Feb
IIs this "diagnostic" a suitable candidate to join the existing 2 PEAKs currently planned for delivery within a COUNTER_EPOSS
Isrop to the whole of the live estate in S90R timescales. (PEAKs 127879 and 128872 refer) .
Date:13-Feb-2006 09:18:34 User:John Budworth
jorning Prayers of Feb 13th confirmed this is to be a diagnostic only and is to go in the first COUNTER EPOSS drop post $90 to
he whole estate.
PEAK should retain open and be returned to development to capture diagnosti
information
‘Date:13-Feb-2006 09:20:54 User:Tyrone Cozens
ihe call Target Release has been moved to Targeted At -- BI_3S90R
‘Date:13-Feb-2006 09:22:24 User:Tyrone Cozens
i[Start of Response]
RM authorise a fix for S90R (1st drop for COUNTER EPOSS).
[End of Response]
Response code to call type L as Category 56 -- Pending -- Live Fix Authorised
jours spent since call received: 0 hours
Date:13-Feb-2006 09:22:57 User:Tyrone Cozens
Whe Call record has been transferred to the team: EPOSS-Dev
Progress was delivered to Powerhelp
Date:13-Feb-2006 12:05:17 Usor:Gerald Barnes
‘The Call record has been assigned to the Team Member: Gerald Barnes
Progress was delivered to Powerhelp
‘Date:13-Feb-2006 16:11:19 r:Gerald Bar:
Detect case updated to 14: Development
Date:13-Feb-2006 16:58:04 User:Gerald Barnes
[Start of Response]
diagnostic version of EPOSSStockUnit has been prodced for BI3S90R. If my theory about the cause of the problem is produced
kchen, with this diagnostic DLL in place, when the problem next occurs there will be a block of lines written to the audit log
£ the form
SU:clsStockUnit.ProcessReConnection Start Tree rebuild
objStockUnit.intCaP - 11
iLocalCAP = 11
objStockUnit.intBe - 1
iLocalBP - 1
objStockUnit.fbIsCurrentInTeMode - True
bLocalsUInTPMode - True
a
3
force the diagnostic to appear in a correct sense. Have a dual counter office with a sotck unit IND attached to MIGROL. Log
in to counter 2 and then disconnect it and acknowledge the disconnection message. Log in to counter 1, roll stock unit IND
into the next TP ignoring all disconnection warnings and then log out of counter 1. Reconnect counter 2 and acknowledge the
reconnection message - the diagnostic will be produced in counter 2 ' s audit log.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
jours spent since call received: 4.0 hours
I
‘Date:13-Feb-2006 16:59:15 User:Gerald Barne:
ihe Call record has been transferred to the team: EPOSS-Rel
Progress was delivered to Powerhelp
‘Date:14-Feb-2006 14:37:24 User:PIT Automated re
Reference Added: Work Package PaY_WP_23673 (TOP Reference)
4-Feb-2006 14:37:25 User:PIT Automated User
nce Added: Fast Track Fix FSTK 2 0 WP23673 (TOP Reference}
Bo
Be
pana
‘Date:14-Feb-2006 15:50:38 Usor:Mike Coon
Whe Call record has been transferred to the team: Dev-Int-Rel
Progress was delivered to Powerhelp
F/323/6
(ate:14-Feb-2006 16:19:35 User:Vijesh Pandya
‘The Call record has been transferred to the team: Live Supp. Test
‘progress was delivered to Powerhelp
I
‘Date:23-Feb-2006 10
R
sor :Edward Willi:
PCO132674
‘Date:07-Mar-2006 10:48:14 User:Edward Willis
Reference Added: Release PinICL PCO133131
‘Date:07-Mar-2006 11:00:41 User:Edward Willis
Release PinICL 132674 (RNB9158) withdrawn (replaced by PC0133131)
Date:15-Mar-2006 11:56:59 User:Edward Willis
[Reference Added: Re ICL PCO133486
i
Date:22-Mar-2006 14:39:06 User:Sheila Bamber
[[start of Response]
Wested in LST (See release Peak for details). Please close
[lund of Response]
Response code to call type L as Category 60 -- Final -- S/W Fix Released to Call Logger
Routing to Call Logger following Final Progress update.
Hours spent since call received: 0 hours
+
‘Date:22-Mar-2006 14:51:44 User:Lorraine Elliott
Ime call record has been assigned to the Team Member: Cheryl Card
‘progress was delivered to Powerhelp
Date:23-Mar-2006 10:22:02 User:Cheryl Card
[Start of Response}
[End of Response]
‘Response 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:15-May-2006 11:45:40 User:Cheryl Card
o
‘Date:15-May-2006 11:48:45 User
lvidence Added - New evidenc
Cheryl Card
or branch 335207 - messagestore, logs, subscription group (zipped)
Date:15-May-2006 11:56:48 User:Cheryl Card
[start of Response]
Another occurrence of this problem - PC0135486.
Whe PM started balancing on 10/05/06 on counter 2 and le:
lin the messagestore on 11/05/06 at 02:33 and 02:39 (GMT).
jhe PM produced a trial balance which contained all zeros, and then continued to roll into the next
ithe new diagnostics appearing on 11/05/06 at 08:24 (BST).
Please route to EPOSS-Dev for attention of Gerald Barnes.
[[end of Response]
esponse code to call type L as Category 40
Response was delivered to Powerhelp
Hours spent since call received: 0 hours
der Investigation
‘Date:15-May-2006 11:57:04 User:Cheryl Card
he Call record has been transferred to the team: QFP
Progress was delivered to Powerhelp
‘Date:15-May-2006 12:04:47 User:Lionel Higman
ne Call record has been assigned to the Team Member: Mark Scardifield
Progress was delivered to Powerhelp
ate: 15-May-2006 13:51:55 User:Mark Scardifield
ne Call record has been transferred to the team: EPOSS-Dev
ne Call record has been assigned to the Team Member: Gerald Barnes
rogress was delivered to Powerhelp
pa
Date:23-May-2006 11:07:58 User:Cheryl Card
ave updated KEL CCard525M. Will keep the call open and monitor for further occurrences of this proble:
ft it overnight. Network disconnection and reconnection messages occur
POL00001197
POL00001197
TP. The audit log shows
F/323/7
POL00001197
POL00001197
‘Date :25-May-2006 16:49:06 Uscr:Gerald Barnes
Target Date/Time updated: new value is 02/06/2006 17:36
Development Cost updated: new cost is 1 (Man Days)
[Start of Response]
‘The diagnostics showed the following «#8211;
8:24:58 SU:clsStockUnit.ProcessReConnection Start Tree rebuild
8:24:58 objStockUnit.intCAP - 1
8:24:58 iLocalCAP - 1
8:24:58 ob}StockUnit.intBP - 1
8:24:58 iLocalBP - 1
8:24:58 objStockUnit. fbIsCurrentInTPMode ~ True
8:24:58 blocalSUInTeMode «#8211; False
land show that the reason for the fatal rebuild of the tree was that bLocalSUInTPMode was False which is clearly a bug because
now this office and all other offices are in TP mode.
LocalSUInTPMode is determined from the PropertyBag element called SUInTPMode which is set in login.
I tried to figure out how this property could be not set and did find a bug in the PropertyBag dll in that it is cleared on
ession swap when it should not be.
This bug could then be easily explained if the rollover was attempted in a swapped session «#8211; however I found that you
mormally cannot rollover a stock unit in a swapped session. I looked in the supplied message store and saw evidence of session
swapping. I believe that there is a bug in the Riposte DesktopIsSwapped call in that it sometimes says a session is not
wapped when it is.
ly proposed solution to this bug is to eliminate all references to the properties SUInTPMode and OfficeInTPMode which are only
used in EPOSSStockUnit. There are only 6 references in total and so the change is not a big one. These properties are now
redundant because all offices are in TP mode. There is a definite bug with both of them because they are not maintained on
ession swap when they should be.
T have managed to find one reproducible bug scenario. It is not the actual bug noted here but illustrates that a lurking bug
is present.
ave a dual counter office. Log on to one counter and declare cash. It takes a while because it is the first time. Look in the
audit log and you will see evidence of a tree rebuild. Declare cash again and see that it is much quicker and that in the
audit log there is no evidence of a tree rebuild. Now swap session. Disconnect the other counter, wait for the disconnection
essage, connect the counters and wait 11 seconds. Acknowledge both messages. Declare cash and see that it has slowed again.
‘Look in the audit log and the diagnostics as at the top will be there and there will be evidence of a tree rebuild s#8211;
chere should not have been a tree rebuild in these circumstances.
lence my proposed fix is a fix to EPOSSStockUnit dll.
PIX IMPACT
IMPACT ON DEVELOPMENT:
the proposed solution will take 1 man day to code and test. It will be able to be coded and tested as soon as it is authorised
lunless some more urgent PEAK intervenes in the mean time.
IMPACT ON TEST:
though the proposed fix is very localised it would never the less be prudent to spend some time checking that rollovers
till work.
IMPACT ON USER:
they should not have any further problems of the nature described in this PEAK
IMPACT ON OPERATION!
None.
RISKS (of releasing and of not releasing proposed fix):
Releasing
nly the danger of someone somewhere in the release chain making a mistake. The code fix is very isolated and easily module
tested.
Not releasing
‘0 will continue to get problems as described in this PEAK.
[Bnd of Response]
esponse code to call type L as Category 55 -- Pending -- Live Fix Impact Supplied
jours spent since call received: 23 hours
9:35 Use)
Date:25-May-2006 1 :Gerald Barnes
Whe call Target Release has been moved to Proposed For -- 120
Date:25-May-2006 11
:52:03 Use
The Call record has been transferred to the tea
RelMngmntForum
F/323/8
Progress was delivered to Powerhelp
bate:01-Jun-2006 16:18:53 User:Tyrone Cozens
Ime call Target Release has been moved to Targeted At -- 120
‘Date:01-Jun-2006 16:20:54 User:Tyrone Cozens
(product DevintRel-Director -- Live Supp.Test added.
‘Date:01-Jun-2006 16:21:25
[Start of Response]
MF authorise a fix for 120.
[End of Response]
Response code to call type L as Category 56 -~ Pending -- Live Fix Authorised
jours spent since call received: 0 hours
or:Tyrone Cozens
]
‘Date:01-dun-2006 16:21:30 User: Tyrone Cozens
ihe Call record has been transferred to the team: EPOSS-Dev
Progress was delivered to Powerhelp
Date:01-Jun-2006 16:22:59 User:Gerald Barne:
jhe Call record has been assigned to the Team Member: Gerald Barnes
Progress was delivered to Powerhelp
Date:02-dun-2006 16:11:59 User:Gerald Barnes
[Start of Response]
Fixed by a new release of EPOSSStockUnit.
[End of Response]
Response code to call type L as Category 44 -- Pending -- Fix in Progress
jours spent since call received: 7.0 hours
Date:02-dun-2006 16:12:52 Use
l[start of Response]
[fixed by new EPOSSStockUnit
[[End of Response]
esponse code to call type L as Category 46 ~~ Pending -- Product Error Fixed
jours spent since call received: 0 hours
Date:02-Jun-2006 16:13:19 Usor:Gerald Barnes
‘The Call record has been transferred to the team: EPOSS-Rel
Progress was delivered to Powerhelp
ate:02-Jun-2006 17:05:56 User:Mike Coon
(Start of Response]
Six released in WP24106 for 120 (43)
[End of Response]
‘Response code to call type L as Category 46 ~~ Pendi:
Hours spent since call received: 0 hours.
~~ Product Error Fixed
‘Date:02-Jun-2006 17:06:10 User:Mike Coon
ference Added: Work Package PWY_WP_24106
Date:02-dun-2006 17:06:13 User:Mike Coon
{TOP Reference set to: Work Package PWY_WP_24106
02-Jun-2006 17:06:25 User:Mike Coon
all record has been transferred to the team: Dev-Int-Rel
Progress was delivered to Powerhelp
Date:28-Jun-2006 11:08:28 User:PIT Automa x
Reference Added: Fast Track Fix FSTK 2 0 #P24106 (LOP Reference)
iL.
iy 28-Jun-2006 11:08:28 User:PIT Automated User
[[start of Response]
Prasttrack fix released, now ready for test.”
{lind of Response]
Response code to call type L as Category 46 (Product Error Fixed)
Whe incident has been transferred to the team: Live Supp.
brogress was delivered to Powerhelp
Date:06-Jul-2006 15:15:24 User:Edward Willis
IReference Added: se PinICL PCO137357
POL00001197
POL00001197
F/323/9
‘Date:24-Jul-2006 15:59:31 User:Lina Kiang
[[start of Response]
Another occurrence of this problem at FAD 055422. Evidence, if needed is attached to PC0137819.
{[Bnd of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Inves
BResponse was delivered to Powerhelp
Hours spent since call received: 0 hours
dl
igation
Date:24-Jul-2006 16:02:31 User:Lina Kiang
[Start of Response]
Ignore previous update, it should have read:
nother occurrence of this problem at FAD 074908, Evidence, if needed is attached to PC0137766.
[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:18-Aug-2006 17:46:12 User:Sheila Bamber
i[Start of Response]
completed testing in LST, Returning to call logger for clos
[End of Response]
de to call type L as Category 60 -- Final -- S/W Fix Released to Call Logger
update.
Response c
outing to Call Logger following Final Progres:
jours spent since call received: 0 hours
‘Date:21-Aug-2006 08:00:25 \ser:Lorraine Elliott
Whe Call record has been assigned to the Team Member: David Seddon
Progress was delivered to Powerhelp
‘Date:21-Aug-2006 08:04:30 User:Lorraine Elliott
the Call record has been assigned to the Team Member:
Progress was delivered to Powerhelp
Date:31-Aug-2006 09:29:22 User:Cheryl Card
[Start of Response]
losing call as fix has now been released in COUNTER POSS 34 4, KEL CCard525M updated.
[End of Response]
Response code to call type L as Category 60 -- Final -- S/W Fix Released to Call Logger
outing to Call Logger following Final Progress update.
ervice Response was delivered to Powerhelp
Date:31-Aug-2006 09:29:22 User:Cheryl Card
(CALL PCO130275 closed: Category 60 Type L
ate:31-Aug-2006 09:29:22 User:Cheryl Card
jours spent since call received: 0 hours
yp
ate: 31-Aug-2006 09:31:32 User: Customer Call_
onsumer Phelp has received the call closure
POL00001197
POL00001197
Development - Code
"Customer Call_-- EDSC
EPOSS & DeskTop -- Balancing (version unspecified)
_Customer Call_--EDSC
31-Aug-2006 09:31 --_Customer Call_
F/323/10