Re: [External] ACS timeout during network latency -- MIDRANGE-L

Looking at some of the recent message on the list caused me to review some system setting, and I identified one that might be part of the problem. Review shows that the partition where the disconnect is most likely to allow a reconnect has a much longer value for the QDSCJOBITV parameter. The partition where it fails has only 5 minutes. This I think is at least one part of the puzzle.

On 10/21/2020 9:21 AM, Joe Pluta wrote:

Thanks, Jeff! I looked, and my session have both Auto Connect and Auto Reconnect set to Yes. I do not have keep alive (on the Advanced tab) selected, but as I noted it still works sometimes. It's the inconsistency of results that makes this so hard to address. :(

On 10/21/2020 9:13 AM, Barron, Jeff via MIDRANGE-L wrote:

I had the same _exact_ issue.

I'm working from memory here, so your mileage may vary.

In an ACS session, Communication —> Configure —> Connection, both Auto Connect and Auto-Reconnect radio buttons are set to Yes.

I probably played with other settings too, but I couldn't be certain. Anyway since I muddled with it I've reconnected nearly 100% of the time with no issues.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Joe Pluta
Sent: Wednesday, October 21, 2020 8:52 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: [External] ACS timeout during network latency

I'm dealing with a situation where I lose connectivity to a VPN for
45-60 seconds. Pings time out during that time, but then the network recovers. If I hit Enter on an ACS session during that time, the session will fail and I understand that. And often, if I don't hit Enter until the ping comes back, the sessions stay up. Sometimes, though, that doesn't work and the sessions go down on their own even without me hitting a key. Does anyone know why that is, and what I can do to extend that time so that a 60 second outage doesn't take down 5250?

And that brings up the second point. I wouldn't care so much about the disconnect if it weren't for the fact that I sometimes have to then do some really tedious steps to bring the session back up. Sometimes I get
this:

1. Screen goes black during disconnect (and beeps once) 2. After the network comes back, I get signon screen 3. I sign on and I get the screen that lets me take an option 1 to reconnect to my existing job

That's fantastic! But sometimes I get this:

1. Screen goes black during disconnect (and beeps once) 2. After the network comes back, the session tries to reconnect but tells me the device name is in use and beeps again 3. Step 2 repeats ad infinitum 4. I have to go into a different session, ENDJOB the active job, and vary off the device

If I wait long enough after the ENDJOB, the system usually varies the device off itself, but it takes a little while.

Does anyone know the magic behind why it works one way or the other? And please note, I don't want to creaet a new device name and sign on to that one. That tends to create lots of device descriptions and also leaves the original job hanging. I really want to reconnect to the existing job if possible.

Thanks!