Solve a Client Access Mystery, Win a No Prize
April 30, 2008 Hey, Joe
|
I have searched every configuration I know of on our 9406-720 (running OS/400 V4R4), but I cannot find what is limiting the total number of Client Access 5250 sessions running on my machine. No matter what, the machine will only accept about 70 sessions. I’ve had to cut out multiple user sessions in order to allow everyone a single session. Any ideas on where the limit is coming from? –Rick It’s like Rubik’s Cube for the iSeries… with No Prize Rick sent his question in this week and so far I haven’t been able to come up with an answer. So I’m going to open this one up to the readership and see what we can come up with together. Listed below are some solutions that I suggested Rick try to solve his problem, none of which did the trick. If someone can do better than I can at analyzing this problem (maybe even you), I’ll send it over to Rick and see if works. While I don’t have a large budget for prizes (look up and see zero), I can offer the following perks to anyone who solves the puzzle.
Can you do better than a pundit at solving this issue? Send those entries my way and let’s see if we can solve Rick’s dilemma. You can reach me through the Contact the IT Jungle Team Web page. The Glow from Joe’s Failed Brilliance Here are my guesses for what could be happening in Rick’s shops. These guesses turned out to be brilliant innovative i5/OS administrator thinking. They also turned out to be dead flat wrong. However, they might prove informative and get you thinking about the right solution to the problem. The QAUTOVRT Solution My first shot was to ask Rick to check his Autoconfigure Virtual Devices (QAUTOVRT) system value. QAUTOVRT sets the absolute highest number of virtual devices the system will create when a 5250 telnet user tries to sign on the system. QAUTOVRT can be set to any value from zero (the shipped value) to *NOMAX, which allows any number of users to attach to the system. My thinking was that if the total number of virtual devices on the system exceeded the number in QAUTOVRT, the system might be denying new user devices as people tried to log in. If you’re playing along at the office, classify this one as “nice try but not even close.” Rick checked the QAUTOVRT value on his system and it was already set to *NOMAX. So it was on to my next futile attempt. Maybe QINTER Is Doing It? My next thought was that maybe the job queues in his QINTER subsystem were incorrectly set up, and that were stopping more than 70 users from starting 5250 interactive sessions. To test this, I asked Rick to check the QINTER subsystem job queue entries on his system. This is easily done on the green screen by looking at his subsystem description. He displayed the QINTER subsystem description by typing in the following Display Subsystem Description (DSPSBSD) command. DSPSBSD SBSD(QINTER) On the Display Subsystem Description menu, he took option 6, Job Queue Entries. This option displays a list of all the job queues that are authorized to accept work for the system. For each job queue, there are 10 critical values that can limit work (signed on users in this case) coming into the subsystem. These values are:
Of course, I struck out here, too, as everything was already set to *NOMAX. However, if Rick wanted to change any of these values for a job queue that feeds work into his QINTER subsystem, he would use the Change Job Queue Entry (CHGJOBQE) command to change that particular value for a job queue entry. Maybe QINTER Is Doing It, Part II Aside from QINTER’s job queue entries, the subsystem also uses its Operational Attributes settings to limit the total number of jobs it will accept from all subsystem job queues. To view a subsystem’s operational attributes, I asked Rick to run the DSPSBSD command once again for QINTER and then take option 1, Operational Attributes, off the menu. DSPSBSD SBSD(QINTER) On the Display Operational Attributes screen, Rick can look at the Maximum Jobs In Subsystem value to see how many total jobs from all sources that the QINTER subsystem will allow to run. If this value is set to *NOMAX, QINTER will accept as many jobs as it can for the subsystem. If the value is set lower, QINTER will limit the maximum number of jobs it will accept to that value. If needed, Rick can change this value to a higher number or to *NOMAX by using the Change Subsystem Description (CHGSBSD) command like this. CHGSBSD SBSD(QINTER) MAXJOBS(*NOMAX) Unfortunately, Rick didn’t need to change this value as it was already set to *NOMAX. Client Access Licensing The next theory was that his Client Access Express for Windows licensing was wrong, and that it contained a usage limit or threshold that was too low for the system. This was easy to check. Rick ran the Work with Licensed Information (WRKLICINF) command and placed a ‘5’=Display’ next to the 5722XW1, feature code 5050 entry. Of course, both the Usage Limit value and the Threshold value were set to *NOMAX, which also meant that the system could accommodate an unlimited number of users. So once again, the answer eluded us. Are You Smarter Than an Admin Alert Columnist (Not Hard)? So that’s the history, the mystery, and the challenge behind this week’s technical tip. If you’re up to it, send me your solution via the Contact the IT Jungle Team Web page. All entries will be forwarded to Rick, and the winner will solely be judged by the first entry that allows Rick to let more than 70 users on his system. If you’ve been looking to help out a fellow System i soldier and earn absolutely no prize for your troubles, be sure to enter today.
|
