What does Device Wait Timer (DEVWAITTMR) do?

[LiQuiD_FuSioN]

Hello, guys!

Does anyone happen to know any details on how the Device Wait Timer (DEVWAITTMR) actually works?

IBM site says:

Device wait timer (DEVWAITTMR)

Specifies the device wait timeout value. This is used to limit the amount of time that a subsystem takes for the work station input/output to complete. The timeout value that is used for each device is obtained from the controller that it is attached to at vary on time. A change in this parameter value takes effect for attached devices when they are next varied on.

*SAME

This value does not change.

device-wait-timer

Specify a value ranging from 2 through 600 that specifies the maximum number of seconds that the subsystem waits for work station input/output to complete for all work stations attached to this controller.

When selecting a value for this parameter, the types of devices attached to the controller should be taken into account. Locally attached work stations should have a low value for this parameter (10 seconds or less).

https://www-01.ibm.com/support/knowledgecenter/ssw_i5_54/cl/chgctlvws.htm

My question is what happens when the timer is UP?

I tried testing with an unused device controller by setting timer from 20 to 5 secs. I've let my session sit on a screen with no input, I tried running a few commands like 'wrkdevd *all' and let it load all the devices as well for about 10 secs. So not entirely sure how it's supposed to work.

Reason being I've been dealing with this dreaded CPF5140 message:

Message . . . . : Session stopped by a request from device XX.
Cause . . . . . : The request shutdown was caused by either the user turning
the power off, by a device error, or the ASCII controller inactivity timer
expired. Recovery . . . : Close the files and vary the device off (VRYCFG
command). If the problem occurs again, enter the ANZPRB command to run
problem analysis.

Hence, why I'm looking into the "ASCII controller inactivity timer" bit in the CPF message to see if it leads me to anywhere.

I'd appreciate any tips or kind words of encouragement.

Low down:
-Users will be actively working and get disconnected from their 5250 sessions
-CPU utilization is below 90% at the moment, can ping office
-I was able to simply re-connect their session fine again
-Session keep alive timeout's at 30 secs (on a side note, what happens if just ONE keep alive doesn't make it to client? I've heard from other people that it tries X amt of times before killing a connection)
-Inactive job time out's at 60 mins
-I'll double check local office PCs to be safe/defrag/reinstall iSeries suite later on/check Windows event logs
-IBM in general let us know to try running their traces, I may have to simply go that route
-Telnet keep alive packets are allowed on our network too

Fun stuff!

Thanks

[egami]

Re: What does Device Wait Timer (DEVWAITTMR) do?

This sounds like they aren't remote users on a WAN, but rather local LAN users. A couple things to check on the IBM i side are the values in CHGTCPA (F4 to prompt, F11), what does it show for TCPKEEPALV? and also in CHGTELNA (F4 to prompt, F11), what does is show for TIMMRKTIMO?

I think default values are 120 (minutes) and 600 (seconds), respectively. I would probably set those around 7200 (m) and 2400 (s), respectively if they aren't that or more already.

If you have a user that you can really rely on feedback from you might have them run a recursive ping to the system next to their 5250 session and see if they're experiencing pack loss when their session drops.

In my experience, more times than not this is a network issue rather than a PC or server issue. Especially when it is affecting multiple users. I've worked with IBM support in the past to set up some diagnostics in order to work in conjunction with our network LAN/WAN guys to resolve these issues as they can be tricky.

Another couple things:

1. Make sure you have fairly recent PTF's installed for the system.

2. You might check and make sure that the NIC on the IBM i and the port(s) it is plugged into on the switch aren't set to auto-negotiate. I've seen this cause various issues at a couple places I've worked. IBM generally recommends having the NIC and switch port hard-coded to match.

You can check this on the IBM i side by doing WRKLIND and taking option 5 on the interface and make sure that "Line speed" and "Duplex" aren't set to *AUTO.

[LiQuiD_FuSioN]

Re: What does Device Wait Timer (DEVWAITTMR) do?

This sounds like they aren't remote users on a WAN, but rather local LAN users. A couple things to check on the IBM i side are the values in CHGTCPA (F4 to prompt, F11), what does it show for TCPKEEPALV? and also in CHGTELNA (F4 to prompt, F11), what does is show for TIMMRKTIMO?

I think default values are 120 (minutes) and 600 (seconds), respectively. I would probably set those around 7200 (m) and 2400 (s), respectively if they aren't that or more already.

A mixture of remote/local, connecting through VPN through the WAN.

For our system:

CHGTELNA - Session keep alive timeout . . . TIMMRKTIMO 30 (SECONDS)
CHGTCPA - TCP keep alive . . . . . . . . . TCPKEEPALV 120 (MINUTES)

As far as I know these parameters are different from each other, right? TCP keep alive is for other types of connections, Telnet's for 5250 connectivity.

1. Make sure you have fairly recent PTF's installed for the system.

2. You might check and make sure that the NIC on the IBM i and the port(s) it is plugged into on the switch aren't set to auto-negotiate. I've seen this cause various issues at a couple places I've worked. IBM generally recommends having the NIC and switch port hard-coded to match.

You can check this on the IBM i side by doing WRKLIND and taking option 5 on the interface and make sure that "Line speed" and "Duplex" aren't set to *AUTO.

We should be fairly updated, did some PTFs earlier in year/late last year. I'll double check again.

For our ethenet line descriptions, we're set at 1G line speed & *FULL duplex. 1 Gb is what our switch's running at as well apparently. I appreciate the reply back, I'll keep digging.

[tomliotta]

Re: What does Device Wait Timer (DEVWAITTMR) do?

TCP keep alive is for other types of connections, Telnet's for 5250 connectivity.

Telnet is also "TCP", so 'TCP keep alive' also applies to telnet. But it's a little more complicated than just that. For some background, review the Setting the session keep-alive parameter topic. Be sure to note details such as:

This action affects only named virtual devices. For automatically selected virtual devices (QPADEVxxxx), the interactive job always ends.

That is, various attributes of sessions and the environment make a difference in determining what might work best. Other details can be just as important.

[LiQuiD_FuSioN]

Re: What does Device Wait Timer (DEVWAITTMR) do?

I have an update for those interested.

We recently had a lot of helpdesk calls roll in due to AS400 session disconnects. Network guys didn't report any changes.

Currently have a PMR opened with IBM, going to go through their instructions and run a trace. They feel it's most likely network related but better to verify with trace first.

-On a side note, even the IBM rep doesn't know how many times the IBM i machine resends a keep alive packet (TIMMRKTIMO) if the first one fails to reach client. It's some magical set number I assume.
-I'll try and ask what that Device wait timer (DEVWAITTMR) value does as well (IF I can)

[LiQuiD_FuSioN]

Re: What does Device Wait Timer (DEVWAITTMR) do?

I have an update for those interested.

We recently had a lot of helpdesk calls roll in due to AS400 session disconnects. Network guys didn't report any changes.

Currently have a PMR opened with IBM, going to go through their instructions and run a trace. They feel it's most likely network related but better to verify with trace first.

-On a side note, even the IBM rep doesn't know how many times the IBM i machine resends a keep alive packet (TIMMRKTIMO) if the first one fails to reach client. It's some magical set number I assume.
-I'll try and ask what that Device wait timer (DEVWAITTMR) value does as well (IF I can)

Update for those who are interested:
Network guys restarted one of their main switches, no more reports of disconnects finally!

Glad to move on now.