- Open terminal connection, log in
- Pass terminal connection in a variable, CloseConnection True
- Pass terminal connection in a variable…
I would expect the last Terminal Session activity to throw an error because we already closed the connection in the first Terminal Session activity. But it doesn’t, it actually reopens a new connection using the same connection string from the original connection.
@postwick - is the delay duration enough for the first connection to close?
No, I had it set to 3 seconds. The connection doesn’t close. I looked at TerminalConnection.Connected and it was false, but the last Terminal Session still just reopened the terminal window, the main terminal screen appeared, and then closed.
(the point here is I’m writing a “Mainframe Close” custom activity that fits our needs, and noticed this behavior when testing it)
The one thing I found that causes the last Terminal Session activity to fault as it should is to set TerminalConnection to Nothing. But that seems like closing the connection should do that automatically.
This doesn’t look right. Could you still include the version of your Terminal activity package for full context?
Mainframe activities version is 2.1.0
The CloseConnection property is ignored if the OutputConnection property is set. We consider that the connection is meant to be used at a later point in the workflow so we do not close it.
If the connection is not meant to be reused, do not set the OutputConnection property.
This is not explicitly documented right now but there is a new version of the terminal activities documentation in the works and it will include an explanation for this behavior.
The OutputConnection property is not set in the Terminal Session activity that has CloseConnection set to true. But the connection still isn’t closed.
I understand what you mean. I thought you meant that the connection does not properly close.
I tested now and it looks like the connection closes properly but then reopens a new connection when I try to reuse the variable.
I agree, this is not a desired behavior and I will open a bug.
Just to close the loop, this was fixed in the recently released Terminal 2.5.0