FUJ00155224
FUJ00155224
Peak Incident Management System
Call Reference PC0153009 Call Logger Gerald Barnes -- Deleted Team
Release Proposed For -- T80 Top Ref 96082
Call Type Cloned call Priority C -- Progress restricted
Contact _ Gerald Barnes Call Status Closed -- Administrative Response
Target Date 20/01/2008 Effort (Man Days) 2.00
Summary FAD 226242 unable to roll over
All References Type : Value
-TRIOLE for Service 96082
SSC OCR OCR 17725
Clone Master PCO152828
Progress Narrative
oate:15-dan-2008 12:19:52 User:Gerald Barnes
CALL PC0153009 opened
Details entered are:~
summary: FAD 226242 unable to roll over
call Type:
call Priority:¢
Target Release:T70
Routed to:EPOSS-Raised - Gerald Barnes
Jbate:10-Jan-2008 11:33:06 User: Customer Call_
CALL PC0152828 opened
Details entered are:~
lSummary:Please advise when branch last rolled over for bot
call Typ:
call Priority:
lfarget Release: T70
Routed to:EDSC ~ Unassigned
bate/Time Raised: Jan 10 2008 1
priority: C
contact Nam
contact PH
originator? XXXXxK@TFSOT
riginator's reference: 96082
Product Serial No:
Product Site: 226242
Denise Miller
Please advise when branch last rolled over for both Office and SU and whether this branch is at risk of archive thanks
Incident History:
2008-01-10 11:30:45 [ Miller, Denise]
INIT : create a new request /incident/problem/change/issue
Date:40-dan-2008 11:38:15 User:Lorraine Guiblin
fhe call summary has been changed frot
Please advise when branch last rolled over for bot
[the call summary is now:
rad 226242 advise when branch last rolled over
jbate:10-Jan-2008 11:38:22 User:Lorraine Guiblin
Product EPOSS & DeskTop -- EPOSS : 3
cified) added.
jbate:10-Jan-2008 11:38:29 Uscr:Lorraine Guiblin
{fhe Call record has been assigned to the Team Member: Lina Kiang
Progress was delivered to Provider
Date:10-dan-2008 15:40:39 User:Lina Kiang
[Start of Response]
fhe last BTS was for TP 08 on 28/11/07; the first stock unit (AA) rolled into TP 09 on the same day (43 days ago).
Disablearchiving is switched on at the counters so the msgs will not be archived nonetheless the Branch is at risk if it does not
roll soon (e.g. if there is a fire).
[End of Response]
lkesponse code to call type L as Category 68 -- Final -- Administrative Response
FUJ00155224
FUJ00155224
Routing to Gall Logger following Final Progress update.
service Response was delivered to Consumer
bate:10-Jan-2008 15:40:39 User:Lina Kiang
CALL PC0152828 closed: Category 68 Type L
Jbate:10-Jan-2008 15:40:39 Uscr:Lina Kiang
use updated to 99 -- General — Unknown
Date:40-dan-2008 16:12:49 User: Customer Call_
consumer XXXXXX@TFS01 has acknowledged the call closure
JDate:10-Jan-2008 16:28:24 User: Customer Call_
caLL PC0152828 reopened by Customer Call_
Please advise when branch last rolled over for both Office and SU and whether this branch is at risk of archive thanks
Incident History:
poo8-01-10 11:30:45 [ Miller, Denise]
INIT : create a new request/incident /problem/change/issue
2008-01-10 11:32:10 [ OTt]
YTIACKINFO : Provider Ref: PC0152828
2008-01-10 11:37:14 [ OTT]
joristu
betail
2008-01-10 15:39:40 [ OTT]
PIRES.
provider Ref: PC0152828
Resolution Details: Update by Lina Kiang:Category 68 -- Final -~ Administrative Response:The last BTS was for TP 08 on 28/11/07;
the first stock unit (AA) rolled into TP 09 on the same day (43 days ago).
Ipdate by Lorraine Elliott:Call routed to Team:EDSC Member:Lina Kiang
DisableArchiving is switched on at the counters so the msgs will not be archived nonetheless the Branch is at risk if it does not
roll soon (e.g. if there is a fire).
2008-01-10 15:39:40 [ POWebService, 01]
JRE: Status changed from 'New' to 'Resolved'
2008-01-10 16:10:28 [ Vincent, Niall]
IR: Transfer 'group' from 'PEAK' to ‘OBC HOLD 1'
2008-01-10 16:26:44 [ Miller, Denise]
rR : @@BIM - I have contacted the Post Master as per previous calls he has been having difficulty rolling over for a while
says that is using the Gateway for the rollover but after rebooting and attempting to start the rollover the system busy timer. is
displayed and ''please wait''. He attempted 2/1/08, 5/01/08 and 9/1/08 with the same result. Whilst talking he says that his line
inanager Sue Spicer has advised that an engineer will be coming out to fix his problem and that he should ring horizon for the
lta. I have explained that we have no open call for an engineer and that he is well behind on rolling over (43 days). I have left
Ja message for Sue Spicer to call me back. Could SSC check this branch out incase there is a software issue preventing completion
lof rollover from the Gateway. Thanks.
Jbate:10-Jan-2008 16:29:59 User:Anne Chambers
fhe call summary has been changed from:-
FAD 226242 advise when branch last rolled over
[fhe call summary is now:
IFAD 226242 unable to roll over
Jbate:40-dan-2008 16:30:24 User:Anne Chambers
[the Call record has been assigned to the Team Member: Lina Kiang
progress was delivered to Provider
oate:21-Jan-2008 11:59:49 User:Lina Kiang
[Start of Response]
[this appears to be a software problem: PM has been informed that he will not be able to rollover until we figure out what's
rong. I will be retrieving evidence from node 1 today and asked the PM to phone in if trading becomes unbearable to get me to
stop (I have given the PM this Tf£S 96062) but this will mean that Development will be delayed starting investigations.
[End of Response]
lresponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
response was delivered to Consumer
Date:11-Jan-2008 13:12:53 User:Lina Kiang
[Start of Response]
evidence from counter 1 has now been retrieved.
[End of Response]
response code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
FUJ00155224
FUJ00155224
jbate:11-Jan-2008 13:20:57 User:Lina Kiang
evidence Added - FAD226242-ms.
1 node
event log and audit log
Date:11-Jan-2008 13:22:32 User:Lina Kiang
[Start of Response]
[the attempt by the PM to rollover on 05/01/08 (on node 1) was left running overnight and failed. The Audit log shows a "General
railure (This key is already associated with an element of this collection)" and points to msg 1-1425636 then it continues
Hooping overnight until the PM rebooted. The PM has also attempted to rollover using node 2 on 02/01/08 overnight and that failed
With the same errors.
store has been retrieved from node 1 and attached as evidence.
outing call to Development for investigation - please note that this FAD is overdue for a rollover so is at risk.
[End of Response]
lkesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
joate:11-gan-2008 13:22:48 User:Lina Kiang
[the Call record has been transferred to the team: QFP
Progress was delivered to Provider
Jbate:11-Jan-2008 14:16:08 User:Lionel Higman
the Call record has been assigned to the Team Member: Mark Scardifield
Progress was delivered to Provider
jDate:14-Jan-2008 09:30:50 Uscr:Mark Scardifield
the Call record has been transferred to the team: EPOSS-Dev
(fhe Call record has been assigned to the Team Member: Gerald Barnes
Progress was delivered to Provider
Jbate:14-gan-2008 0:
[Start of Response]
It wish to import the message store and attempt a rollover myself to find out what is going wrong. To do this I need in addition
the subscription groups. I have emailed Lina to ask her to attach these.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
0:08 Uscr:Gerald Barnes
jate:14-Jan-2008 10:42:41 User:David Seddon
evidence Added = All Ones
abscription Group
bate:14-dan-2008 11:40:11 User:_Customer Call_
IcALL PC0152828 reopened by Customer Call_
Jbate:14-Jan-2008 11:40:11 User: Customer Call_
Please advise when branch last rolled over for both Office and SU and whether this branch is at risk of archive thanks
incident History:
2008-01-10 11:30:45 [ Miller, Denise]
INIT : create a new request/incident/problem/change/issue
2008-01-10 11:32:10 [ OTT]
IACKINFO : Provider Ref: PC0152828
2008-01-10 11:37:14 [ OTT]
joristu
betail:
2008-01-10 15:39:40 [ OTT]
joTIRES :
Provider Ref: PC0152828
lkesolution Details: Update by Lina Kiang:Category 68 -- Final -- Administrative Response:The last BTS was for TP 08 on 28/11/07;
the first stock unit (AA) rolled into TP 09 on the same day (43 days ago).
jpdate by Lorraine Elliott:Call routed to Team:
DSC Member:Lina Kiang
Disablearchiving is switched on at the counters so the msgs will not be archived nonetheless the Branch is at risk if it does not
loll soon (e.g. if there is a fire).
2008-01-10 15:39:40 [ POWebService, 01]
ke : Status changed from 'New' to ‘Resolved!
2008-01-10 16:10:28 [ Vincent, Niall]
IR : Transfer ‘group’ from 'PEAK' to ‘OBC HOLD 1'
2008-01-10 16:26:44 [ Miller, Denise]
IR : @@BIM - I have contacted the Post Master as per previous calls he has been having difficulty rolling over for a while. He
says that is using the Gateway for the rollover but after rebooting and attempting to start the rollover the system busy timer is
displayed and ''please wait''. He attempted 2/1/08, 5/01/08 and 9/1/08 with the same result. Whilst talking he says that his line
FUJ00155224
FUJ00155224
fanager Sue Spicer has advised that an engineer will be coming out ta fix his problem and that he should ring horizon for the
leta. I have explained that we have no open call for an engineer and that he is well behind on rolling over (43 days). I have left
la message for Sue Spicer to call me back. Could SSC check this branch out incase there is a software issue preventing completion
lof rollover from the Gateway. Thanks.
2008-01-10 16:27:59 [ OTT}
jOTIACKINFO : Provider Ref: PC0152828
2008-01-10 16:29:21 [ OTT]
joristu
betail:Update by Anne Chambers:Call routed to Team:EDSC Member:Lina Kiang
2008-01-11 10:46:54 [ Miller, Denise]
Koc : @@bim - I left a voice message for Sue Spicer last night advising that until our 3rd line have investigate the possible
software issue at this branch we would not be sending an engineer. I have emailed IMT/Leighton Machin to ensure no base unit
/pinpads are swapped in the interim.
2008-01-11 11:59:06 [ OTT}
joristu
Detail:Update by Lina Kiang:Category 40 -- Pending -- Incident Under Investigation:This appears to be @ software problem: PM has
been informed that he will not be able to rollover until we figure out what's wrong. I will be retrieving evidence from node 1
today and asked the PM to phone in if trading becomes unbearable to get me to stop (I have given the PM this TfS 96082) but this
ill mean that Development will be delayed starting investigations.
2008-01-11 13:11:47 [ OTT]
LISTU
Detail:Update by Lina Kiang:Category 40 -- Pending -- Incident Under Investigation:Evidence from counter 1 has now been
jretrieved.
2008-01-11 13:21:23 [ OTT]
TISTU
jDetail:Update by Lina Kiang:Category 40 -- Pending -- Incident Under Investigation:The attempt by the PM to rollover on 05/01/08
(on node 1) was left running overnight and failed. The Audit log shows a "General Failure (This key is already associated with an
jelement of this collection)" and points to msg 1-1425636 then it continues looping overnight until the PM rebooted. The PM has
Jsiso attempted to rollover using node 2 on 02/01/08 overnight and that failed with the same errors.
store has been retrieved from node 1 and attached as evidence.
Routing call to Development for investigation - please note that this FAD is overdue for a rollover so is at risk.
2008-01-11 13:21:58 { OTT]
PISTU :
betail:Update by Lina Kiang:Call routed to Team:QFP
2008-01-11 14:15:15 { OTT]
jorrstu
JDetail:Update by Lionel Higman:Call routed to Team:QFP Member:Mark Scardifield
2008-01-12 00:51:34 [ Rainbow, Mary)
[rR : Transfer 'group' from ‘PEAK' to ‘'RMGA BIM'
2008-01-14 11:43:14 [ Chambers, Anne]
lst : Status changed from ‘Resolved’ to ‘Work In Progress!
2008-01-14 11:43:15 [ Chambers, Anne]
ITR : Transfer ‘group’ from 'RMGA BIM' to 'PEAK*
jate:14-Jan-2008 11:46:58 Uscr:Lorraine Guiblin
IThe Call record has been assigned to the Team Member: Lina Kiang
Progress was delivered to Provider
bate:14-dan-2008 11:49:15 User:David Seddon
fhe Call record has been transferred to the team: EPOSS-Dev
fhe Call record has been assigned to the Team Member: Gerald Barnes
Progress was delivered to Provider
Jbate:14-gan-2008 1.
[Start of Response]
the problem is that transaction <GroupId:226242><Id: 1><Num:1425636> has corrupt primary mappings which do not align and this
causes DataServer to fail.
7:06 Uscr:Gerald Barnes
It notice that relevant product 21126 has correct mappings but was start dated after the failing transaction was written.
Perhaps there was a corrupt EPOSSProducts in existence at the time of the transaction?
[End of Response}
lkesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Date:14-gan-2008 1
{Start of Response]
the product 21126 has been transacted seconds before and after the failing transaction with no problem. So if a corrupt
IePoSsProducts existed it must have been for a very short time.
7:08 Uscr:Gerald Barnes
kGroupid:226242><Id:1><Num:1425636> was the only example with corrupt mappings.
FUJ00155224
FUJ00155224
Tend of Response]
Ikesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
Joate:14-gan-2008 17:00:09 User:Gerald Barnes
[Start of Response]
ly response "Date:2008-01-14 13:27:06 User:Gerald Barnes" had a mistake. The EPOSSProducts with the correct mappings was
introduced 10 days before the failing transaction.
Itt now looks more difficult to explain this PEAK as a temporary fault in the EPOSSProducts Data.
[End of Response]
Ikesponse code to call type L as Category 40 -- Pending -- Incident Under Investigation
lbate:35-gan-2008 1
[Start of Response]
fhe transaction <GroupId:226242><Id:1><Num:1425636> has an incorrect 14 primary mapping. All other transactions of product 21126
(even those written just seconds before and seconds after) have the correct primary mappings. It appears very difficult to
lexplain this by the temporary introduction of a faulty EPOSSProduct 21126.
[End of Response]
Response code to call type L as Category 40 -- Pending -- Incident Under Investigation
3:56 Uscr:Gerald Barnes
jbate:15-dan-2008 7:38 User:Lina Kiang
evidence Added - FAD226242-partial 1
ore from node 1 with corre
@ imported onto counter
jDate:15-Jan-2008 12:09:54 Uscr:Lina Kiang
Reference Added: 1925
bat e:15-gan-2008
Start of Response]
It ran a patched DataServer to correct the faulty transaction <Groupld:226242><Id:1><Num:1425636> and it was then possible to
rollover the stock unit. I attach the patch as evidence labelled “Patch DataServer". If the faulty message can be corrected and
jreimported that will work as well.
[End of Response]
Response code to call type L as Category 40 -- Pending ~~ Incident Under Investigation
8:58 Uscr:Gerald Barnes
[Date:15-dan-2008 1:
levidence Added - P.
Jbate:15-Jan-2008 12:19:52 Uscr:Gerald Barnes
call cloned from original call:PC0152828 by User:Gerald Barnes
bate:15-gan-2008 1
[Start of Response]
It am cloning this PEAK so that the correct team can investigate how the corrupt mails message <GroupId:226242><Id:1><Num:1425636>
can be produced.
[End of Response]
Response code to call type C as Category 38 -- Pending -- Potential Problem Identified
1:11 User:Gerald Barnes
Joate:15-Jan-2008 12:21:22 User:Gerald Barnes
the Call record has been transferred to the team: APS-Ctr-Dev
Jate:15-Jan-2008 13:18:48 User:Adrian Goodwin
[the Call record has been assigned to the Team Member: Richard O'Neill
Date:15-gan-2008 14
[Start of Response]
It is a complete mystery as to how this erroneous value of the <[d4:> attribute within the Primary Mapping (<PM:>) attribute could
joe set for this one occurrance of this transaction. smart post merely copies the entire <PM:> attribute from the appropriate
roduct data to the transaction message. It has no interest in its contents. It does not manipulate individual attributes within
this attribute.
9:01 User:Richard O'Neill
there are no products within the entire message store, including out-of-date products, that have the erroneous value of <L4:>
that has appeared in this one transaction message. So, the hypothesis that somehow the wrong product has been used can be
Jdiscounted.
[this may be a RetailBroker or Escher Mails problem that has somehow corrupted the data.
can the rollover process be changed to simply flag the problem for manual fixing and then complete the rollover? This would then
lavoid the dire consequences, suggested in the PEAK, for a delay in making the rollover.
[End of Response]
Ikesponse code to call type C as Category 40 -- Pending -- Incident Under Investigation
Jate:15-Jan-2008 14:49:16 Uscr:Richard O'Neill
[the Call record has been transferred to the team: QFP
FUJ00155224
FUJ00155224
fbate:15-gan-2008 16:
[Start of Response]
See suggestion from Richard.
[End of Response]
Response code to call type C as Category 70 -- Final -- Avoidance Action Supplied
Routing to Call Logger following Final Progress update.
2:22 User:bionel Higman
lDate:45-Jan-2008 17:10:39 Uscr:Gerald Barnes
Development Cost updated: new cost is 2 (Man Days)
[Start of Responsel
ith regards to Richard's suggestion.
fhe problem was in fact already flagged. A message in the audit log pin pointed the precise message that caused the problem.
the error handling of balancing is deficient in some ways. In most cases an error is just logged and the code bluders on
regardless leaving the system locked. What should happen is that the error should be logged, the process cleanly aborted, an
lerror message displayed to the user and the system left so that he can do something else. I hope the HNGx version is much better.
Ir am not sure it is worth while spending time improving the EPOSS version which is shortly to be replaced; it would be better
spending the same effort making the HNGx version better. I had already requested that this be advised to the HNGx team in
lpco152376.
JAt the moment, under the original PC0152828, attempts are being made to import a corrected message
kGroupid: 226242><Id:1><Num:1425636> to allow the balancing to proceed.
it is too early to say whether this process will succeed.
i have already got the stock unit roll by running a patched DataServer which corrects the corrupted transaction.
Ik propose a cheap general solution to the problem.
lA new version of DataServer be written which configurably corrects any messages found to be corrupt. It will be controlled by a
Inew collection the CorruptCorrection collection.
lkach object will contain
Data:
I). .<MessNum:
see S1d 2 X>
+ .<Num:¥>
S
<Correctio1
complete Corrected Message>
As DataServer runs it will check each message read in to see whether it matches anything in the CorruptCorrection collection
(which of course will usually not exist) and if it does it will correct the message.
lerx IMPACT
complete Forecast Date and Development (man days) fields below this text box.
include a brief statement for each of the headings below these instructions.
n return to Details window Set Target Release Type to "Proposed for" and Target Release to that proposed.
to the Developer:
(1) Put yourself in the shoes of people downstream and provide information that they are likely to need to process this fix. eg
the testing and rollout costs may add significantly to the COST of the fix
(2) Check that the statements are still accurate post-implementation
IMPACT ON DEVELOPMENT:
IEf€ort in mandays.
[there will be an expectation at RMF that this approximates to the timescale for delivery so if there are reasons why this might
Inct be the case please note them here.
l2
HMPACT ON TEST:
at. independent test coverage does development recommend?
\This will often be about the level of regression testing required.
few tests to make sure that balancing works with the new DataServer. A couple of tests populating the CorruptCorrection
collection and confirming the changes are used by balancing.
HMPACT ON USER:
Benefit of making the fix.
correcting corrupted messages which stop stock units rolling will be much easier.
what does the user have to do to get this problem?
see Richard's comments - basically we do not know!
low does it affect them when it occurs?
the user is unable to roll a stock unit.
IMPACT ON OPERATIONS:
Benefit of fix that may not visible to end user.
ffice roll information will not be delayed so much from affected offices.
FUJ00155224
FUJ00155224
RISKS (of releasing and of not releasing proposed fix):
hat live problems will there be if we do not issue this fix?
lust the occasional problem as this one.
hat are the risks of this fix having unexpected interactions with other areas?
jone.
is this a high-risk area in which changes have caused problems in the past?
tt is but this fix is very self contained and should be fine.
should we consider a pilot rollout and of what sort?
lA very simple pilot should be used. Issue the software to a small number of Offices and make sure balancing works OK for at least
lone Office Rollover. Then release it everywhere.
InIST OF LIKELY DELIVERABLES:
IsPOSSDataServer
LIST OF THE ABOVE ALREADY DELIVERED FOR THE PROPOSED RELEASE:
one.
LIST OF THE ABOVE ALREADY DELIVERED TO A RELEASE LATER THAN THAT PROPOSED:
lone
LIST OF THE ABOVE LIKELY TO BE REDELIVERED INTO THE PROPOSED OR A LATER RELEASE:
None.
IANYTHING ELSE THAT SHOULD BE KNOWN ABOUT THIS CHANGE:
lothing.
[End of Response]
Response code to call type C as Category 55 -- Pending -- Live Fix Impact Supplied
jbate:15-Jan-2008 17:11:15 User:Gerald Barnes
[the call Target Release has been moved to Proposed For -- T80
JDate:15-Jan-2008 17:11:36 User:Gerald Barnes
[the Call record has been transferred to the team: RelMngmntForum
jbate:16-Jan-2008 0:
[Start of Response]
iaving thought about this some more the CorruptCorrection collection will need the FAD code as a suffix.
4:46 Uscr:Gerald Barnes
lence the collection of corrections will be CorruptCorrection_XXX where XXX is the FAD code.
[Bnd of Response]
Response code to call type C as Category 55 -- Pending -- Live Fix Impact Supplied
[Date:17-Jan-2008 11:12:13 User:Lina Kiang
lcerald, just to let you know that last night, the PM successfully rolled over (for details see original call PC0153009).
Jbate:17-Jan-2008 12:06:25 Uscr:Gerald Barnes
[Start of Response]
It see from the comment
corrected one.
08-01-17 11:12
hina Kiang" that she was able to fix the corrupted message by reimported 2
ence my proposed fix will only be required if the volume of corrupt messages produced gets too great for the SSC to easily cope.
If it is required I have thought of an improvement which would help in this case. The correction collection should change to
Data:
-+--<MessNum:
Rees Geese eee STGEKR
<Correct FromEPOSSProduct :Z>
--».<Correction:Complete Corrected Message>
>
here Z is either True or False.
tf False (or the attribute is omitted) behaviour is as described before.
Itt True the Correction attribute is not required and instead the transaction is automatically corrected from data in the correct
IEPOssProducts collection object.
[End of Response]
Response code to call type C as Category 55 -- Pending -- Live Fix Impact Supplied
FUJ00155224
FUJ00155224
Date: 21-Jan-2008 09:42:07 User:Gerald Barnes
[Start of Response]
I add a few further thoughts on this.
Richard in his comment “Date:2008-01-15 14:49:01 User:Richard O'Neill" states “Can the rollover process be changed to simply flag
[the problem for manual fixing and then complete the rollover?”.
the rollover process already flagged the failing transaction to the audit log but left the system locked. I think the ideal
lbchaviour would be to flag the problem but leave the system in a useable state. In my opinion it would have been a mistake to
lallow the rollover process to continue because you would end up with a balance report with incorrect figures. The whole point of
accounting is to end up with correct figures!
lence I believe the existing behaviour of the error handling in this case is not so very different to the ideal behaviour and
hence not worth fixing because of its imminent replacement by HNG-X.
Ite we want to do anything to balancing it is what I propose - simplify supplying the corrected input.
If this problem crops up again we really want to raise a PEAK on the fact that corrupt transactions are being produced. This was
the original point of this clone but Richard has diverted it back to balancing again! Just because we do not know the reason for
the corrupt transaction being produced does not stop it being a bug! Maybe the problem needs analysing a little more and sending
ito Escher.
[End of Response]
Response code to call type C as Category 55 -- Pending -- live Fix Impact Supplied
Jbate:24-Jan-2008 15:49:04 User:Tyrone Cozens
[Start of Response]
ix not required. This has already got a KEL raised against it (PC0152376). Routing to call logger for closure.
[End of Response]
Ikesponse code to call type C as Category 68 -- Final -- Administrative Response
routing to Call Logger following Final Progress update.
oate:24-Jan-2008 15:50:58 User:Gerald Barnes
Defect cause updated to 42: Gen — Outside Pathway Control
Date:24-Jan-2008 15:51:03 User:Gerald Barnes
ALL PCO153009 closed: Category 68 Type ©
Root Cause : Gen - Outside Program Control
Logger Gerald Barnes -- Deleted Team
Subject Product EPOSS & DeskTop -- EPOSS (version unspecified)
Assignee Gerald Barnes -- Deleted Team
Last Progress 24-Jan-2008 15:51 -- Gerald Barnes