FUJ00171950
FUJ00171950
Peak Incident Management System
Call Reference PC0065075 Call Logger
Release Targeted At -- Horizon Future Unspecified — Top Ref
Call Type Requirements Futures Database Priority _
Contact Deleted Contact Call Status
POA Deleted User -- Deleted Team
D -- Non-urgent
Closed -- Administrative Response
Target Date —_ 02/05/2001 Effort (Man Days) 0
Summary S10/EPOSS Prev button allows multiple logon
Progress Narrative
foate:18-Apr-2001 10:45:00 User:Binav Avni.
ALL PCO065075 opened
keferences entered ar
Product EPOSS & DeskTop EPOSS added
Target Release entered: Unknown
ls10/EPOSS Prev button allows multiple logon
s10/EPOSS/ST06/triple counter test.
togged on to C01 and while ‘Adjust Stock’ picklist was being built, tried to
transfer the session to C03: to recreate:
I Enter user id and password.
I Message received: ‘Session Transfer
Inachine, please wait.
I While this message is displayed, press the ‘PREV’ button which take the
screen back to the riposte screen.
I try logging on again, and this time logon is allowed. User is logged on
th counters at the same time.
CALL PC0065075:Priority C:Calltype $ - Target 25/04/01 11:45:34
the Call record has been assigned to the Team Member: Nikki O'Sullivan
Defect cause updated to 99:General - Unknown
Hours spent since call received: 1.0 hours
The user is being transferred to this
Joate:18-Apr-2001 11:55:00 User:Nikki O'Sullivan
IF} Response :
send to eposs-fp
(END OF REFERENCE 25768263]
lkesponded to call type $ as Category 30 -TL confirmed
[the response was delivered on the system
{the Call record has been transferred to the Team: QFP
Hours spent since call received: 0 hours
[Date:4@-Apr-2001 12:09:00 User:del (05/01 John McLean)
Ihe Call record has been assigned to the Team Member: Les Ong
Hours spent since call received: 0 hours
Date:18-Apr-2001 12:43:00 User:Nikki O'Sullivan
upgrading to B at QFP request
CALL PC0065075:Priority B:CallType S - Target 23/04/01 11:45:34
lbate:18-Apr-2001 13:22:00 User:Les Ong
[this problem is more serious than it looks and may explain live calls where
lusers have been managing to log on at 2 counters at the same time.
hat this bug also allows while a user is performing a Trial Cash Account
print/preview on one counter is for him to log on at a second counter with
the Office Balancing button initially locked but becoming unlocked after some
seconds. This explains how the user on live PinICL 64421 managed to do this.
Joate:18-Apr-2001 13:30:00 User:Les Ong
[the Call record has been transferred to the Team: EPOSS-FP
Hours spent since call received: 1 hours
Jbate:19-Apr-2001 11:04:00 User:Les Ong
to clarify further, the Session Transfer message appears whenever a session
transfer is attempted while the system is busy (e.g. building a picklist,
reparing a report).
tt is a problem in M1 and needs to go to RMF for approval to fix as soon as
jpossible. However, it's not absolutely clear where the problem lies. It may
pe a StopDeskTransfer problem and this needs to be looked at in the first
instance. I've talked with Rex Dixon who is going to look at the problem
first.
the Call record has been transferred to the Team: 1.
Hours spent since call received: 1 hours
Dev
FUJ00171950
FUJ00171950
[Date:19-Apr-2001 12:09:00 User:del (05/01 John McLean)
target Release updated to CI4MIR
Date:49-Apr-2001 12:10:00 User:del (05/01 John McLean)
lf) Response :
luive impact required
(END OF REFERENCE 25782952]
lkesponded to call type $ as Category 54 ~Live Fix Impact Required
the response was delivered on the system
Date:19-Apr-2001 13:49:00 User:Rex Dixon
[the Escher code for the first login on C03 generates an
kapplication:$TransFlush> message. This is picked up by the StopDeskTransfer
agent on C01, As C01 is locked to the user, this StopDeskTransfer will
lattempt to write a response persistent object with <TransferFailed:reason>.
In this case, it would appear that StopDesk?ransfer's attempt to write the
reponse mist have failed or been timed out. This can happen because there is
la Riposte transaction in porogress on that counter.
m_ C03, when the user backs off the first attempt to login while still
Waiting for this reponse, the second attempt should have done the same thing,
land written another <Application:$TransFlush> message. This does not appear
tc have happened, so the first suspect must be the Escher login code.
II need a copy of the message store generated by this sequence of events to
confirm or otherwise deny this hypothesis, and have asked Les Ong to supply.
lbate:20-Apr-2001 17:05:00 User:Les Ong
I've checked the messages generated when session transfer is instigated and
found that the current version of Riposte does not write a $transflush
essage. Instead, another format message is written. It looks like Escher
Ihave revised the way that they handle session transfer:-
Riposte 223 update 18a
kel ler 1D:MIGRO1><UserName :MIGcssp<FlushNodeId:1><Application
kiposte 223 update 27
essions><ObjectNams
‘ransFlush>
State:RequestingTransfer><IdTra
so somewhere between updates 18A and 27A Riposte has changed. Should we be
jusing $TransFlush anyway? Doesn't the dollar implies that this is internal to
lsscher.
User:Les Ong
Because this problem does not seem to exist with Riposte update 18A, my
assertion that this could explain live problems is incorrect. The system will
not. move beyond 18A until M1 goes in.
Jat @:14-May-2001 16:05:00 Uscr:Les Andrew
the agent team will for a decision on what to do next.
ror attn of Gareth Jenkins.
Ithe Call record has been transferred to the Team: TDA
fours spent since call received: 2 hours
JDate:15-May-2001 08:12:00 User:Tarig Arain
the Call record has been assigned to the Team Member: Gareth Jenkins
Hours spent since call received: 0 hours
Date:16-May-2001 07:54:00 Uscr:Gareth Jenkins
lhe net result of this is that the StopDeskTransfer service is no longer
required. I'll leave this PinICL on TDA until we can justify a CP to remove
the service from the counter.
Priority should be reduced to D.
careth
Jbate:16-May-2001 12:23:00 User:Lionel Higman
kesetting priority as requested.
[Date:16-May-2001 12:24:00 Uscr:Lionel Higman
CALL. PC0065075:Priority D:Callfype $ - Target 02/05/01 11:45:34
[Date:22-Jan-2002 08:08:00 Uscr:Lionel Higman
target Release updated to Future Unspecified
[Dat e:20-dun-2002 07:55:00 User:Del (01/04 John Newitt)
FUJ00171950
FUJ00171950
(fontact changed to Harjinder Hothi
Ibate:09-gan-2004 1
send to eposs-fp
9:41 User: Customer Call_
[bate:09-Jan-2004 1.
ive impact required
Customer Cali_
bate:11-Jun-2004 12:30:40 User:Harjinder Hothi
see following response received from Gareth in Email:
rom: Jenkins Gareth GI
sent: 08 June 2004 15:14
fr Hothi Harjinder
Ic Rex Dixon
subject: RE: PC0065075 Update
[this PinICL has been sitting there in this state for 3 years!
[the issue is still relevant in that we have been maintaining this Agent and
he-testing it and running it on the counter at every release, however in
usiness terms it does absolutely nothing and may as well be scrapped. The
problem is that there doesn't appear to be any mechanism to remove such code.
tf a CP were to be raised, the chances are that a number of people would
introduce costs for changing it, and it would be considered to be to
laifficult to fit into a release. Feel free to try if you like.
i suspect it will probably stay in this state until we move to Roadmap.
jeanwhile if anybody ever finds a bug in it, then the simplest thing is to
kill it!
Regards
lcareth
Jbate:21-gun-2004 11:49:23 User:Lionel Higman
the call TargetRelease has been changed from:-
Future Unspecified
[he call TargetRelease is now:-
Future Unspecified
JDate:06-Sep-2004 12:43:55 Uscr:Gareth Jenkins
the Call record has been transferred to the team: ASD-Futures
the Call record has been assigned to the Team Member: Gareth Jenkins
JDate:15-Nov-2004 15:53:42 User:Lionel Higman
CALL PC0065075:Priority 0:CallType H - Target
Date: 25-Apr-2008 1
[Start of Response]
Horizon now being fixed only where live can demonstrate a problem. Closing call
[End of Response]
Response code to call type H as Category 68 -- Final -- Administrative Response
kouting to Call Logger following Final Progress update.
6:38 User:Lionel Higman
jDate:25-Apr-2008 10:16:46 User:Lionel Higman
Defect cause updated to 41: General - in Procedure
jate:25-Apr-2008 10:16:51 Uscr:Lionel Higman
CALL PC0065075 closed: Category 68 Type H
Root Cause _ General - in Procedure
Logger POA Deleted User -- Deleted Team
Subject Product EPOSS & DeskTop -- EPOSS (version unspecified)
Assignee POA Deleted User -- Deleted Team
Last Progress 25-Apr-2008 10:16 -- Lionel Higman