Comments on: Multiple session on the iSeries

By: daks

daks — Wed, 13 Jul 2011 17:35:19 +0000

There is a limit (set by you) to the number of qpadevXXXX sessions which can be active at one time. It’s possible that through security issues (people varying off their sign on and/or sessions, all available qpadevxxxx sessions are “varied off”….

I have seen this many times. You can check this out by typing “wrkcfgsts *dev and then jumping to “qpadev”……..scroll down and see how many are are varied on; varied off; active; or on a sign on screen…….

By: Featured Member: Splat - ITKE Community Blog

Featured Member: Splat - ITKE Community Blog — Thu, 05 May 2011 06:51:53 +0000

[...] Multiple session on the iSeries [...]

By: tomliotta

tomliotta — Sat, 16 Apr 2011 02:15:37 +0000

Is it possible that “NOT ME” accidently checked or un-checked the setting for the session?

That would be the most likely cause.

Be aware that it can also be changed by adding or removing the AutoConnect= line in the .WS file for the session (or by changing the setting from/to ‘Y’ or ‘N’). That opens the possibility of any number of causes since anything that can update a text file can make the change from anywhere, as long as the route is available, permissions are available, etc. Slim possibility, but non-zero.

I’d go with “Not me”.

Tom

By: Featured Member: Koohiisan - ITKE Community Blog

Featured Member: Koohiisan - ITKE Community Blog — Tue, 12 Apr 2011 06:32:17 +0000

[...] Multiple sessions on the iSeries [...]

By: tomliotta

tomliotta — Fri, 08 Apr 2011 01:23:37 +0000

Yes, it looks like client access is trying to open the same session twice.

If just this user is seeing the problem and the configuration is simply requesting any available device, how have you determined that “client access” is trying to open the same session twice? And what did you do you stop it from doing that?

So far, everything sounds like a normal, default configuration.

Tom

By: splat

splat — Thu, 07 Apr 2011 14:56:39 +0000

Any change to QLMTDEVSSN limiting the number of user sessions?

By: tomliotta

tomliotta — Thu, 07 Apr 2011 02:46:59 +0000

I would go to QAUDJRN and look for T/AF (Authority Failure) entries at the time connections were attempted.

If the same device is being selected that is already in use by another session that belongs to this user, and if other QPADEV* devices seem to be available but not selected, then look very carefully at any changed authorities for that user. E.g., has this user become *ALLOBJ/*SECOFR class and is now only authorized to this device?

Next, if the system is not allowed to create new QPADEV* devices, let it auto-create a new one for this user, then turn the capability back off. Look for the same device types on the new device and the earlier one. Are they different device types than the devices that weren’t selected? Some authority wrinkle that has changed might restrict access.

Tom

By: amazing0

amazing0 — Thu, 07 Apr 2011 00:48:09 +0000

Thank you all for your quick response. I did check the workstation id, and it is blank, The user gets the defaults device, ie QPADEV….., so I also checked that all available devices are varied on. Yes, it looks like client access is trying to open the same session twice. One thing that the user changed was her password.

By: koohiisan

koohiisan — Wed, 06 Apr 2011 20:16:35 +0000

Ours use the ‘avoid duplicate names’ option and this happens all the time. They end up closing one session without signing out, or mess up the password 3 times and lock *that* session. (session ‘B’, for instance) So, next time they try to get three sessions, they only get session ‘A’ and ‘C’, because ‘B’ is still varied off.

So, do a wrkdevd [session name for workstation]* to see them all. For instance: “WRKDEVD DSP21*” would show DSP21A, DSP21B, DSP21C, etc. See if any are varied off.

By: tomliotta

tomliotta — Wed, 06 Apr 2011 17:58:10 +0000

One of our as400 users lost the ability…

If the capability was “lost”, then something changed. First place to look is the properties of the .WS file that defines the session(s). Look at its last change date. If that date is close to the date of loss, you probably know the source. If it wasn’t changed, then you’ve nearly eliminated anything on the user’s PC side.

Of course, if it’s been changed while attempting to fix or analyze the problem, then that info is lost. Keep it in mind for the future.

Tom