http://www-01.ibm.com/support/docview.wss?uid=nas1b5c3f619350209b0862568
dd006c5eb4
iSeries Access/System i Access clients contain components that require a
license to function. 5769XE1 Client Access Express for Windows, 5722XE1
iSeries Access for Windows, and 5761XE1 System i Access for Windows
requires a license for Data Transfer and PC5250 Display and Printer
Emulation. 5722XH2 iSeries Access for Windows and 5761XH2 System i
Access for Windows requires a license for every unique web session,
regardless of the function. They 5722XL1 iSeries Access for Linux client
requires a license for the 5250 Display emulation. Since licenses cost
money, it is important to make sure that the license function is working
correctly.
Run the WRKLICINF command, and select Option 5 on the licensed feature
57xxXW1. The Usage Limit must be set to the number of iSeries
Access/System i Access Family for Windows 57xxXW1 licenses that were
purchased. Option 8 from the WRKLICINF command for 57xxXW1 will attempt
to show some jobs associated with the licensing. However, this is not
the best way to investigate.
The 5250 component of iSeries Access/System i Access requires a license.
However, just counting the interactive jobs in the Interactive subsystem
is not a good way of tracking the iSeries Access licenses either. Since
5250 emulation can be started , but sitting at a sign-on screen, there
is no interactive job associated with this. Just counting the
interactive jobs will also leave out the licenses for the Data Transfer
utility, or from System i Access for Web.
The licensing function for iSeries Access is handled by the iSeries
Access Host Server Central Server job. The Optimized Central Server for
Sockets connections is named QZSCSRVS and will check out licenses for
direct TCP/IP connections.
Counting the number of QZSCSRVS jobs that are in use will give the
accurate snap-shot of the number of Client Access licenses in use.
WRKACTJOB SBS(QSYSWRK) JOB(QZSCSRVS) and WRKACTJOB SBS(QUSRWRK)
JOB(QZSCSRVS) are commands that will bring up the total number of
Optimized Central Server jobs for the sockets connections .
By counting the number of these jobs in TIMW state, you can get the
accurate count of the number of Client Access licenses checked out.
As with any job, check the job log for messages. These jobs will tell
you the user profile that requested the Client Access license. Message
CPIAD02, Servicing user profile xxxxxx, will show the user profiles that
have used this job. The last CPIAD02 in this list will be the current
license holder (assuming that the job is in TIMW status, not PSRW). In
some cases, there will also be another message, CPIAD12, Servicing user
profile xxxxxxxx from client xxxxx. Cursor to these messages, press F1
and record the time and date that these messages were logged.
If this number does not match with the number of iSeries Access Licenses
that are expected, this information can help with tracking down what is
happening. In general, the older the message, the more likely it should
be questioned to see if a license is still checked out. Forgetting about
the old PC sitting over in the corner, the most commonly found cause for
the job still allocating the license to a PC that is no longer needed,
is an abnormally disconnected PC.
If a PC disconnects abnormally from the servers system for any reason
without returning the license it was using, it will seem like the
iSeries/System i licensing function is in error. Abnormal disconnects
could be anything from network problems to powering off the PC while it
is connected to that iSeries family server. Since the PC cannot notify
the iSeries family server that it no longer needs a license in these
cases, the iSeries family server cannot know what happened. It is
waiting on the PC to return the license.
How long will the Central Server job wait on the iSeries family server
in these cases? It will wait until the TCP keep alive timer expires (
CHGTCPA , F4, and record the TCP keep-alive value this timer is, in
minutes). When the timer expires, the iSeries family server will send to
the PC to make sure that it is still there and listening. If the iSeries
family server does not receive a response, it will retry a couple of
times over a couple of minutes and then, if still no response from the
PC, it will reclaim the license and recover. Therefore, if the TCP keep
alive timer is set to its default setting of 120 minutes, an abnormally
disconnected PC will be detected after about 130 minutes and then the
license will be reclaimed. However, if the TCP keep alive timer is set
to the maximum 40320 seconds, the license will be held until the timer
pops in 28 days.
If a PC disconnected abnormally and reconnected, it will get a new
license. There is no way to judge accurately if a license has already
been checked out for that PC. So, if there is a PC that is frequently
powered off and reconnected, it may seem to have many licenses checked
out. Also, if there is a network event that causes an abnormal
disconnect and then all the PCs connect back up, it will also seem as if
the Client Access licensing function is inaccurate. It is not. In such
cases, it is extremely important that the TCP keep-alive timer is set to
a value that is accurate for the network environment.
Is there an easy way to verify that the TCP keep-alive mechanism is
working? Yes, fairly easily. Record the TCP keep-alive value. We will
assume a default setting of 120 minutes, or two hours. Connect an
iSeries Access/System i Access PC and bring up a 5250 sign-on screen.
Remember that you do not have to sign on to get the license checked out.
On the iSeries family server, issue the WRKTCPSTS *CNN command (or
NETSTAT *CNN ), and find the IP address for the PC and the as-cent> that
is established. Watch the IDLE TIME while you refresh. The idle time on
this established connection should count up to 02:00:00 - 04:00:00 (two
- four hours) to and then roll back to 00:00:00. The event that caused
the idle time to reset was the TCP keep-alive mechanism.
If this information leads to the conclusion that connections are
dropping, investigate the network connectivity for likely causes.
Rochester Support Center knowledgebase document 30033636 , Telnet
Session Drop Checklist:
<
http://www-01.ibm.com/support/docview.wss?uid=nas1a53b17cf8d5ed7c386256
cf3006ba9d2> may help with that.
midrange.com
