FUJ00155210
FUJ00155210
From: Gelder Robert[/O=EXCHANGE/OU=ADMINGROUP1/CN=RECIPIENTS/CN=GELDERR]
Sent: Thur 17/01/2008 2 PM (UTC)
To: Wilcox David{_
Subject: FW: 153009
McKeown Kevin.
Good Afternoon,
This is an interesting one, it concerns a corrupt mails txn message at <Date:17-Dec-2007><Time:17:27:17>, due
to the time I have ruled out a patch as the cause of this.
Regards
Rob
From: Barnes Gerald
Sent: 17 January 2008 09:31
To: Parker Steve (PostOfficeAccount); Cozens Tyrone TJS; Peach Mik; Bamber Sheila; Cumming Marshall; Scardifield
Mark; Higman Lionel M; Gelder Robert
Cc: Budworth John; Elliott Lorraine
Subject: RE: 153009
Hi Steve.
I thought it might be a good idea to summarise this problem for those on the thread who have not had time to
read the PEAK
I was assigned a PEAK in which the Post Master was unable to roll over a stock unit.
I analysed the problem and found that one mails transaction was corrupt and this was causing the problem
I sent the PEAK back with advice and guidance as to the need to correct the corrupt transaction either by re-
importing it if feasible or using a patched DataServer I supplied.
I cloned the PEAK and sent it to the team responsible for mails to analyse.
They sent the clone back to me saying they did not know how the transaction got corrupted but requesting that
balancing be improved to cope better with corrupt transactions.
I thought about this and decided that now was not the time to improve balancing for the reasons I gave and have
already been quoted. Besides it is the old case of garbage in garbage out. The fundamental problem was the corrupt
transaction.
What I did propose was a general method for DataServer to correct corrupt transactions which I could easily
code.
Whether or not this is required will depend on several things including the frequency with which the problem
occurs.
Regards,
Gerald Barnes
From: Parker Steve (PostOfficeAccount)
Sent: 16 January 2008 11:03
To: Cozens Tyrone TJS; Peach Mik; Bamber Sheila; Cumming Marshall; Scardifield Mark; Higman Lionel M; Gelder Robert
Cc: Budworth John; Barnes Gerald; Elliott Lorraine
Subject: RE: 153009
"Given the nature of the problem SSC don't see any reason to attempt fix this one"
FUJ00155210
FUJ00155210
Management bul!sh1 mode off .... Don’t touch it with a barge pole
Steve
From: Cozens Tyrone TIS
Sent: 16 January 2008 10:28
To: Peach Mik; Parker Steve (PostOfficeAccount); Bamber Sheila; Cumming Marshall; Scardifield Mark; Higman Lionel M; Gelder Robert
Ce: Budworth John; Barnes Gerald; Elliott Lorraine
Subject: 153009
All, the only Peak currently in RMF is 153009, so we intend not to hold an RMF tomorrow. Rob, please could we
hold the Ref Data meeting at 15.00 tomorrow.
Mik/Steve, Please could you take a look at 153009 in Peak. Gerald Barnes has impacted this Peak, but added the
comment below earlier in the progress information:-
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 error message displayed to the user and the system left so that he can do something
else. I hope the HNGx version is much better. I 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 PC0152376.
Do you think there is a requirement for another EPOSS drop or can we leave this for the time being? Does this
issue happen frequently and does it cause much of a problem from your point of view?
Thanks,
Ty