Subject: Emailing: msg10855.txt

From: "Juian Satran \(Hotmail\)" <[email-masked]>
Date: Wed, 19 Jun 2002 18:41:19 +0300

Pat,

Your "issue" with operational is probably related to a missreading of the text.
The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al connections  but the barrier "stays"  while the connection is operational and will be "removed" if the connection goes away.
The barrier is there to avoid stale commands popping-up at the target after a recovery.

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 19 Jun 2002 21:59:42 +0300

I mean S1.   S5 is not "fully synchronized" - stale commands getting out 
at the target while the initiator logs out may  be perceive as within a 
valid window (a very improbable event but possible nevertheless).

Julo

[email-masked]
06/19/2002 08:30 PM
Please respond to pat_thaler

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        RE: Emailing: msg10855.txt

Julian,
 
I don't think it is a misreading of the text. I will try restating the 
question.
 
You say below "the barrier "stays"  while the connection is operational 
and will be "removed" if the connection goes away.
 
Does "the connection goes away" mean that the connection state machine 
leaves S5: LOGGED_IN state or does it mean that the connection state 
machine has returned to S1: FREE state?
 
Pat

-----Original Message-----
From: Juian Satran (Hotmail) [mailto:[email-masked]]
Sent: Wednesday, June 19, 2002 8:41 AM
To: ips
Cc: Juian Satran (Hotmail)
Subject: Emailing: msg10855.txt

Pat,
 
Your "issue" with operational is probably related to a missreading of the 
text.
The barrier (dissalow wrapping) is on CmdSN. CmdSN advances accross al 
connections  but the barrier "stays"  while the connection is operational 
and will be "removed" if the connection goes away.
The barrier is there to avoid stale commands popping-up at the target 
after a recovery.
 
Julo