FUJ00155366
FUJ00155366
Peak Incident Management System
Call Reference PC0164429 Call Logger David Seddon -- EDSC
Release Targeted At -- T86 Top Ref FSTK_ 2 0 _WP29300
Call Type Cloned call Priority B -- Progress stopped
Contact David Seddon Call Status Closed -- S/W Fix Available to Call Logger
Target Date 26/09/2008 Effort (Man Days) 2.00
Summary FAD005948 BM stock unit was rolled over it was forced to clear the local suspense account
All References Type Value
SSCKEL KEL dsed56280
TRIOLE for Service 82747
Fast Track Fix FSTK 2 0 WP29300
Work Package PWY_WP_ 29300
Release PEAK PCO165710
Clone Call PC01S2421
Clone Master PC0152376
Progress Narrative
bate:05-Sep-2008 12:56:52 User:David Seddon
CALL PC0164429 opened
Details entered are:-
summary:FAD005948 BM stock unit was rolled over it was forced to clear the local suspense account
call Type:
call Priority:B
ltarget Release: T80
Routed to:EDSC - David Seddon
Date: 20-Dec-2007 12:35:19 User:_Customer Call_
JcALL PC0152376 opened
betails entered are:-
summary: Ibrahim from the NBSC has asked that an issue be i
call Type:L
call Priority:B
target Release:T70
Routed to:EDSC - _Unassigned_
Date/Time Raised: Dec 20 2007 11
Priority: B
contact Name:
contact Phon
riginato
riginator's reference: 82747
Product Serial No:
Product Site: 005948
[brahim from the NBSC has asked that an issue be investigated by our software team regarding discrepancies still showing when the
IS stock unit is rolled to clear the local supsense account.
incident History:
2007-12-20 11:53:19 [ Brooks, Katrina]
INIT : create a new request/incident /problem/change/issue
2007-12-20 12:01:32 [I Brooks, Katrina]
Log : The following information has been sent to me via Email from Tbrahim @ NBSC
n Wednesday 12/12 the BM stock unit had a gain of £465.73. As this stock unit rolled over it was forced to clear local suspense
k1083.76- . The gain of £465.73 did not go to local suspense and is not included in the £1083.76-.
[this was not the last stock unit to roll over. The last stock unit to roll over was MIS at 10:20 on 13/12. This stock unit had no
discrepancies. MIS is a correction stock unit and was not inactive as it is rolled every BP.
the suspense account and final balances corroborate the above as the office has sent us copies.
[the Trading statement agrees with the suspense account and that BM stock cleared suspense but did not send its gain to suspense,
[fhe Trading position line should always show zero. Under the BM stock column it shows £465.73-.
It have had a trial done on BM stock to see if this is showing the £465.73 but it is not.
2007-12-20 12:02:28 [ Brooks, Katrina]
log : I contacted the PO to gain more details but the pm was on the other phone. I was asked to call back in 15 mins.
FUJ00155366
FUJ00155366
P007-12-20 12:04:59 I Brooks, Katrinal
xoG : Ibrahim stated that this might be the same issue for branch code 003020 (incident number 76918) .
2007-12-20 12:25:58 [ Brooks, Katrina]
L0G _: I have spoken to the PM for more details:
su - BM that has the problem
SC SU is one they use to roll over the office.
User name JBAf==3
Have rolled into TP9
jode 1
2007-12-20 12:33:53 [ Brooks, Katrina]
L0G : Ibrahim from the NBSC states that this might be related to Branch Code 003020 (76918) that I have sent back across for
investigation.
2007-12-20 12:37:31 [ Brooks, Katrina]
LOG : Can you please investigate as to why when the BM stock unit was rolled over it was forced to clear the local suspense
laccount. This was not the last stock unit to be rolled over.
Thanks
2007-12-20 12:38:11 [ Brooks, Katrina]
IfR : Transfer ‘group! from 'HSH7' to 'PEAK'
bate: 20-Dec-2007 1
[the call summary has been changed from:—
brahim from the NBSC has asked that an issue be i
[the call summary is now
FAD005948 BM stock unit was rolled over it was forced to clear the local suspense account
jate:20-Dec-2007 12:41:51 User:Lorraine Guiblin
Product EPOSS & DeskTop =- Counter Common (version unspecified) added.
jbate:20-Dec-2007 12:42:07 Usecr:Lorraine Guiblin
the Call record has been assigned to the Team Member: David Seddon
Progress was delivered to Provider
jbate:21-Dec-2007 13:46:12 User:David Seddon
Cloning call so original can be pas
urposes.
ncilaition
Sd to development for further investigation and clone can be passed to MSU for rec
jDate:21-Dec-2007 13:46:19 User:David Seddon
call has been cloned to Call:PC0152421 by User:David Seddon
[Date:21-Dee-2007 1:
Isvidence Added = 005948 - Comp
jbate:21-Dec-2007 13:51:13 User:David Seddon
lbvidence Added - Subscription 6.
Jbate:21-Dec-2007 13:52:39 User:David Seddon
lkvidence Added - 005948 Ctrl Event/Audit/?
baté:21-Dee-2007 14:55:20 User:David Seddon
[Start of Response]
Stockunit BM was being rolled over on counter 1 at the same time that the various BOD of day pri es were being run in the
background around 7pm. It was during the CABSProcess that the following message was written to the audit log...
SU: €PostTxnsToLocalSuspense (:-1056374781) Timeout occurred waiting for lock. (0xC1090003) CreateMessageEx:
IRiposteCreateMessageEx call failed.
[fhe messages that should have posted the £465.73 gain in stockunit BM to local suspense failed to be written. Consequently, when
liccal suspense was cleared (written off to Pél in this case) the £465.73 wasn't taken into account and this resulted in the -
465.73 trading position seen on the Branch Trading Statement.
Routing call to development to investigate further and improve the error handling so that following the failure to write messages
the system doesn't carry on regardless.
[End of Response]
Response code to call type Las Category 40 -- Pending -- Incident Under Investigation
Response was delivered to Consumer
Date:21-Dec-2007 15:01:22 User:David Seddon
[Start of Response]
It is not believed that there will be any ongoing impact of this problem at the branch and the branch is not personally out of
FUJ00155366
FUJ00155366
[pocket given that losses were written off to Pal, However, there is an impact on POLFS which will need to be corrected: the
Jaetail for this is contained in call PC0152421 which has been passed to the MSU for onward progression to POL.
[End of Response]
Ikesponse code to call type L as Category 40
Response was delivered to Consumer
Pending -- Incident. Under Investigation
JDate:21-Dec-2007 15:01:29 User:David Seddon
IThe Call record has been transferred to the team: QFP
Progress was delivered to Provider
Joate:02-Jan-2008 08:29:51 User:Lionel Higman
the Call record has been assigned to the Team Member: Mark Scardifield
progress was delivered to Provider
Date:02-dan-2008 09:51:02 User:Mark Scardifield
Ihe Call record has been transferred to the team: EPOSS—Dev
[the Call record has been assigned to the Team Member: Gerald Barnes
progress was delivered to Provider
joate:02-dan-2008 13:17:58 Uscr:Gerald Barnes
Htarget Date/Time updated: new value is 10/01/2008 12:35
Development Cost updated: new cost is 2 (Man Days)
[Start of Response]
the fact that EPOSS code is not resilient to errors is endemic. There seems little point fixing it in this one particular case
because there will be many others to catch you out. For example when I tried to balance with CABSProcess running I found that
ldeclaring cash failed with the same sort of error message!
Itt may be worth passing on the general message to the HNGx team that in many cases code should always try and exit gracefully
Jafter an error and not just blunder on regardless.
Hhis is a perfect example of why. Had the balancing code exited gracefully then if the user had tried again after CABSProcess had
finished working then all would have been well.
ror the time being I propose a much cheaper solution then re-writing a lot of EPOSS error handling.
the problem is that because of a previous PEAK (PC0140715) CABSProcess writes out messages atomically. It does a StartTransaction
lite early on (which creates the lock), then initiates writing lots of transactions with CreateMessage and persistent objects
ith PutObject and finally really writes them with a call to EndTransaction (which ends the lock). If something else tries to
rite a transaction whilst CABSProcess has things locked then it will time out after 10 seconds. Hence if CABSProcess takes more
than 10 seconds to run you could get this sort of problem. In this case CABSProcess took 33 seconds to run which gives a
significant window of opportunity for this sort of problem to occur. I suggest addressing this matter directly by having
caBsProcess store all that it wants to write out to a collection and then only really write it out at the very end. In this way
the system will be locked for less than 10 seconds and there will be no possibility of this sort of problem.
Jerx 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:
(2) 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:
effort in mandays.
2 man days
[There will be an expectation at RMF that this approximates to the timescale for delivery so if there are reasons why this might
Jnct be the case please note them here.
HMPACT ON TEST:
hat independent test coverage does development recommend?
Ithis will often be about the level of regression testing required.
Just some independent tests that CABSProcess is still producing the same results as before.
IMPACT ON USER:
Benefit of making the fix.
Itt will no longer matter if CABSProcess is running when the user tries to do many sorts of different things, balancing included.
hat does the user have to do to get this problem?
lo anything which involves writing a transaction whilst CABSProcess is running (after 19:00) when CABSProcess has sufficient work
to do so that it takes more than 10 seconds to run (so probably on the larger offices).
How does it affect them when it occurs?
jhatever is being tried on the counter at this time can potentially fail.
HMPACT ON OPERATIONS:
FUJ00155366
FUJ00155366
Benefit of fix that may not visible to end user:
tess support calls.
IkISKS (of releasing and of not releasing proposed fix):
hat live problems will there be if we do not issue this fix?
Problems will continue to occur if the counter is being used whilst CABSProcess is running in those cases when it
Ho. seconds to run,
hat are the risks of this fix having unexpected interactions with other areas?
lone.
lis this a high-risk area in which changes have caused problems in the pas'
ves. However the fix proposed is self contained and is considered unlikely to cause any problems.
should we consider a pilot rollout and of what sort?
LIST OF LIKELY DELIVERABLES:
cABSProcess
LIST OF THE ABOVE ALREADY DELIVERED FOR THE PROPOSED RELEASE:
lone
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:
ANYTHING ELSE THAT SHOULD BE KNOWN ABOUT THIS CHANGE:
lothing
[End of Response]
lkesponse code to call type L as Category 55 -- Pending -- Live Fix Impact Supplied
It think a pilot is well worth while in all cases. However as stated before I do not consider this a dangerous fix.
takes more than
jatc:02-Jan-2008 13:20:43 User:Gerald Barnes
[fhe call Target Release has been moved to Proposed For ~~ T70
lDate:02-dan-2008 1
[Start of Response]
It have put proposed for T70. However I think it really wants to be 180. There is no T80 option at the moment.
[End of Response]
Response code to call type L as Category 55 -- Pending -- Live Fix Impact Supplied
1:40 User:Gerald Barnes
joate:02-dan-2008 13:23:17 User:Gerald Barnes
the Call record has been transferred to the team: RelMngmntForum
Progress was delivered to Provider
JDate:08-Jan-2008 15:19:29 User:John Boston
the call Target Release has been moved to Proposed For -- T80
Date:10-dan-2008 14:31:17 User:Tyrone Cozens
[Start of Response]
Routing to EDSC for KEL and close.
[End of Response]
IResponse code to call type L as Category 68 -- Final -
outing to Call Logger following Final Progress update.
Administrative Response
JDate:10-Jan-2008 14:39:30 User:Lorraine Guiblin
lthe Call record has been assigned to the Team Member: David Seddon
Progress was delivered to Provider
jate:10-dan-2008 1:
Reference Added: &:
Jbate:10-Jan-2008 16:06:12 User:David Seddon
[Start of Response]
nore prevalent then the need for a fix will be reviewed once again. In the meantime KEL dsed5628Q
has been created to cover the problem.
tt has been decided that no fix will be carried out for the time being given the rarity of the problem. Should the problem become
FUJ00155366
FUJ00155366
ith regard to this instance of the problem we have already passed details and corrective actions necessary on to Post Office
Limited by means of a BIM issued by the MSU (PC0152421). Therefore no further action is necessary and this call can simply be
closed.
[End of Response]
Response code to call type L as Category 70 ~~ Final -- Avoidance Action Supplied
outing to Call Logger following Final Progress update.
service Response was delivered to Consumer
jDate:10-Jan-2008 16:06:13 Uscr:David Seddon
CALL PC0152376 closed: Category 70 Type L
JDate:10-Jan-2008 16:06:12 Uscr:David Seddon
Defect cause updated to 14 -~ Development = Code
Date:10-Jan-2008 16:14:50 User:_Customer Call_
consumer XXXXXX@TFS01 has acknowledged the call closure
JDate:05-Sep-2008 12:56:52 Uscr:David Seddon
call cloned from original call:PC0152376 by User:David Seddon
Jat ¢:05-Sep-2008 12:57:17 User:David Seddon
the Call record has been transferred to the team: EPOSS-Dev
[the Call record has been assigned to the Team Member: Gerald Barnes
Dat e:05-Sep-2008 13:31:08 User:Gerald Barnes
It have developed a fix for thie and attach the source and a ReadMe.txt for it in the zip file attached as evidence labelled "Work
lon fix so far".
JDate:05-Sep-2008 13:32:03 User:Gerald Barnes
lsvidence Added - Work on fix so far
Jbate:05-Sep-2008 15:06:01 Uscr:Gerald Barnes
ffarget Date/Time updated: new value is 26/09/2008 12:56
Development Cost updated: new cost is 2 (Man Days)
[Start of Response]
It proposed a fix for this before - see "Date:2008-01-02 13:17:58 User:Gerald Barnes". At the time it was rejected. However after
further investigation it has been decided that this needs to go to RMF again - see an email from Gareth Jenkins attached as
levidence labelled "Email from Gareth". I also attach a report I have written showing the sorts of problems that can potentially
loccur if the problem is not fixed as evidence labelled "Report on Potential problems".
leIx 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:
(2) 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:
lsffort in mandays.
2 man days
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.
IMPACT ON TEST:
what independent test coverage does development recommend?
[this will often be about the level of regression testing required.
lust some independent tests that CABSProcess is still producing the same results as before.
IMPACT ON USER:
Benefit of making the fix.
Itt will no longer matter if CABSProcess is running when the user tries to do many sorts of different things, balancing included.
hat does the user have to do to get this problem?
ldo anything which involves writing a transaction whilst CABSProcess is running (after 19:00 on node 1) when CABSProcess has
sufficient work to do so that it takes more than 10 seconds to run (so probably on the larger offices).
How does it affect them when it occurs?
whatever is being tried on the counter at this time can potentially fail.
FUJ00155366
FUJ00155366
HMPACT ON OPERATIONS:
Benefit of fix that may not visible to end user.
tess support calls,
IkISKs (of releasing and of not releasing proposed fix):
at live problems will there be if we do not issue this fix?
Problems will continue to occur if the counter is being used whilst CABSProcess is running in those cases when it takes more than
ho seconds to run.
hat are the risks of this fix having unexpected interactions with other areas?
None.
is this a high-risk area in which changes have caused problems in the past?
ves. However the fix proposed is self contained and is considered unlikely to cause any problems.
should we consider a pilot rollout and of what sort?
Ir think a pilot is well worth while in all cases. However as stated before T do not consider this a dangerous fix. The simplest
sort of pilot is required. Test it out on 100 officess for a month and then if there are no problems release it everywhere.
ist OF LIKELY DELIVERABLES:
kansProcess
LIST OF THE ABOVE ALREADY DELIVERED FOR THE PROPOSED RELEASE:
one
LIST OF THE ABOVE ALREADY DELIVERED TO A RELEASE LATER THAN THAT PROPOSED:
LIST OF THE ABOVE LIKELY TO BE REDELIVERED INTO THE PROPOSED OR A LATER RELEASE:
IANY'THING THAT SHOULD BE KNOWN ABOUT THIS CHANG!
jothing
[End of Response]
Respor ode to call type € as Category 42 -- Pending -- Product Error Diagnosed
ours spent since call received: 7.5 hours
[Dat e:05-Sep-2008 1:
lsviden
jDate:05-Sep-2008 15:12:53 Uscr:Gerald Barnes
the call Target Release has been moved to Proposed For -- T86
JDat¢:05-Sep-2008 15:13:20 Uscr:Gerald Barnes
lthe Call record has been transferred to the team: RelMngmntForum
jbate:10-Sep-2008 11:05:53 User:John Budworth
fhe call Target Release has been moved to Targeted At -- T86é
oate:10-Sep-2008 11:12:39 User:John Budworth
[Start of Response]
ffargeted at T86 outside of formal RMF after discussions and emails with Mik Peach, Sheila Bamber and Steve Evans. As Gerald
Barnes is on leave until the 23rd of September the LFS delivery is not expected until Friday 26th earliest.
ltesting to be scheduled for 2 weeks commencing October 1st with live deployment to commence Thursday 1éth of October. These are
luuide dates only.
Routing to EPOSS-Dev.
[End of Response]
Response code to call type C as Category 56 -- Pending -- Live Fix Authorised
jDate:10-Sep-2008 11:12:57 Uscr:John Budworth
the Call record has been transferred to the team: EPOSS~Dev
jbate:12-Sep-2008 16:33:27 User:Steve Evans
[the Call record has been assigned to the Team Member: Gerald Barnes
FUJ00155366
FUJ00155366
fbate:12-Sep-2008 16:
[Start of Response]
serald, please fix ASAP.
[End of Response]
esponse code to call type C as Category 56 -- Pending -- Live Fix Authorised
3:40 User :Steve Evans
jDate:24-Sep-2008 11
[Start of Response]
[fhe fix is in source safe. Only one file had to be modified and that was modMainEx.bas. However, as per our coding standards, '~
7:33 User:Gerald Barnes
comments were separately stripped from modMainEx.bas (in an earlier version) and clsProcessWorkingDay.cls.
fhe test plan is added as evidence labelled test plan "Test Plan" and the test results to which it refers are added as evidence
labelled "Test Results".
[End of Response]
lkesponse code to call type C as Category 56 -- Pending -- Live Fix Authorised
Hours spent since call received: 7.5 hours
[Date:24-Sep-2008 18:28:35 Uscr:Gerald Barnes
levidence Added - lan
[Date:24-Sep-2008 1:
evidence Added - 1.
9:07 User:Gerald Barnes
Date:25-Sep-2008 14:30:10 Uscr:Mike Coon
[Start of Response]
IEPOSS-DEV Solution Review
ln viable and comprehensive local Unit Test Plan which is sufficient to test the solution, has been attached (UTPXXXXX.doc) —
present; as is a Report.
Ii am satisfied that the proposed solution has been;
agreed with and underwritten by Design (NA) (N/A as no design authority)
I-Implemented according to this agreement in the proposed fix for this fault.
...MJC has checked the code.
jotes:
nly comment is that the "With mtypeTransaction Handle" clauses are ignored and the type name re-iterated in new lines of code
(which is perfectly safe) and that some of the old comments about writing of transactions and use of StartTransaction() are now
rendered inaccurate-
[End of Response]
Response code to call type C as Category 56 -- Pending -- Live Fix Authorised
Date:25-Sep-2008 14:
[Start of Response]
POSS-DEV Solution Review
1:02 User:Mike Coon
la viable and comprehensive local Unit Test Plan which is sufficient to test the solution, has been attached (UTPXXXXX.doc) -
Present; as is a Report.
I am satisfied that the proposed solution has been;
LAqreed with and underwritten by Design (NA) (N/A as no design authority)
I-Implemented according to this agreement in the proposed fix for this fault.
-..MJC has checked the code.
lotes:
nly comment is that the "With mtypeTransaction Handle" clauses are ignored and the type name re-iterated in new lines of code
(which is perfectly safe) and that some of the old comments about writing of transactions and use of StartTransaction() are now
rendered inaccurate.
[End of Response]
Response code to call type C as Category 56 -- Pending -- Live Fix Authorised
date: 25-Sep-2008 14:44:20 Uscr:Gerald Barnes
[Start of Response]
Fixed by a new release of CABSProcess.exe.
[End of Response]
Response code to call type C as Category 46 -- Pending -- Product Error Fixed
JDate:25-Sep-2008 14:44:34 User:Gerald Barnes
fhe Call record has been transferred to the team: EPOSS-Rel
jDate:26-Sep-2008 1:
[Start of Response]
FUJ00155366
FUJ00155366
[oink tested OK. I heavily populated a message Store with £1570 worth of transactions. 1 then advanced the system clock to 19:00
land started an automatic tool to transact £130 worth of transactions in a continuous process. I logged on after everything had
jcompleted and saw that the cash level was £1700 so that nothing had been missed. I looked at the transactions written and could
see that 4 complete transaction had been written whilst CABSProcess had been running between 19:01:36 and 19:02:18.
[End of Response]
esponse code to call type C as Category 46 -- Pending -- Product Error Fixed
JDate:26-Sep-2008 1:
[Start of Response]
IEPOSS-DEV Reference Data Notification
7:11 User:Phil Budd
fter final unit testing, all Reference Data to be released through EPOSS-DEV and associated with this fix must be itemised and
liependencies explained.
Inf this PEAK is for a Reference Data fix, the changed Reference Data should then be attached to the PEAK as evidence.
ESSION OF the Reference Data element of the FIX should also be discussed.
issues affecting MIGRATION and possible subsequent REG
(fo be completed by the developer)
this fix is
de only (¥) [If ¥, skip rest]
[End of Response]
Response code to call type C as Category 46 -~ Pending -- Product Error Fixed
bate: 26-Sep-2008 12:50:44 User:Phil Budd
[Start of Response]
IEPOSS-REL HANDOVER QUALITY AUDIT CHECKLIST
Prior to formal Handover to the Testing function, an audit of required processes should be completed.
(fo be completed by the release~builder)
iH. Design/Solution Documentation attached or In-Line (¥)
2. EPOSS-DEV Solution Review complete (¥)
3. EPOSS-DEV Unit Test Notification complete (UTP attached)
4. EPOSS-DEV Reference Data Notification complete (¥)
Is. Reference Data change attached (NA)
It am satisfied that the proposed solution has been processed correctly (Y)
jotes: Fix issued at release level T86i1 via work package 29300
{End of Response]
response code to call type C as Category 48 -- Pending -- Fix Released to PIT
JDate:26-Sep-2008 12:50:59 User:Phil Budd
Reference Added: Work Package PWY WP_29300
jDate:26-Sep-2008 12:51:10 User:Phil Budd
IfOP Reference set to: Work Package PWY WP 29300
jbate:26-Sep-2008 12:51:44 Uscr:Phil Budd
[the Call record has been transferred to the team: Dev-Int-Rel
bate: 29-Sep-2008 14:30:50 User:Tyrone Cozens
eference Added: AK PCO165710
JDate:29-Sep-2008 15:13:36 Uscr:PIT Automated User
Reference Added: Fast Track Fix FSTK_2_0_WP29300 (TOP Reference)
jbate:29-Sep-2008 15:16:00 User:Arun Singh
[fhe Call record has been transferred to the team: EDSC
JDate:29-Sep-2008 16:16:12 User:Joe Harrison
[fhe Call record has been assigned to the Team Member: David Seddon
jDate:30-Sep-2008 10:38:44 Uscr:Cheryl Cara
[fhe Call record has been transferred to the team: Live Supp.Test
FUJ00155366
FUJ00155366
bate: 30-Sep-2008 10:39:31 User:John Budworth
product DeviIntRel-Director -- Live Supp.Test (version unspecified) added.
bate:04-Nov-2008 11:55:22 User:John Budworth
[Start of Response]
P29300 being delivered to live vai Tivoli Product LFS COUNTER 44 1.
ust testing completed.
Pilot completed.
toll out to the estate authorise and almost completed (41 counters outstanding).
Routing to call logger for closure.
[End of Response]
Response code to call type C as Category 60 ~~ Final ~~ S/W Fix Released to Call Logger
outing to Call Logger following Final Progress update.
JDate:04-Nov-2008 15:24:27 User:David Seddon
[Start of Response]
ix to CABSProcess delivered. Closing call.
{End of Response]
lkesponse code to call type C as Category 60 -- Final -- S/W Fix Released to Call Logger
routing to Call Logger following Final Progress update.
JDate:04-Nov-2008 15:24:36 User:David Seddon
CALL PCO164429 closed: Category 60 Type
Root Cause Development - Code
Logger David Seddon -- EDSC
Subject Product EPOSS & DeskTop -- Counter Common (version unspecified)
Assignee David Seddon -- EDSC
Last Progress 04-Nov-2008 15:24 -- David Seddon