|
In this section: |
Ensure all the regions have the same name specified for APPLGROUP.
If the Logon specifies an application name, make sure the name is in a service block in each MSO region you want available to the MSO Load Balancing group.
If the Logon does not specify application name ensure that all targeted MSO regions in the group have the same service name as specified for the first service block in the initially contacted MSO region.
If the logon does not specify a Load Balancing Group name or application name, then the defaults may be set in the IBI Subsystem. Issue the subsystem command:
IBIS DISPLAY LOADBALANCING
This shows the current default settings. Once default settings are set in the IBI subsystem, all access requests that are not supposed to use these defaults will require that the group and application name be specified.
The distribution of users does not seem to be even across MSO Load Balancing regions.
Load Balancing only has an effect at Logon time. If users FIN out of one or more regions faster than the rate of new users logging on, then the distribution will become unbalanced.
Dividing the Load Balancing group can produce imbalances across MSO regions in the APPLGROUP.
One region is rejecting all MSO Logons and users cannot get on even when other regions are available.
The placement algorithm for Logon routing MSO users into load balanced regions does not guarantee the region can handle it. If one region becomes overstressed due to the amount of activity but it has the lowest number of users, users are routed to it and fail in Logon. This can be remedied in one of two ways:
My payroll application fails in one Load Balancing region.
Ensure that the environment for the failing region is identical to the region in which the application works properly. Before you make any changes, review the other applications assigned to that region making sure the correction will not affect those applications adversely.
A user is having a problem. How do I find out in which MSO region they are executing.
Have the user execute a FOCEXEC that calls the MSOINFO module. This module now returns the application name in addition to the service block name and server name. The following lines in a FOCEXEC accomplish this:
-SET &SERVER = MSOINFO('SERVER ','A8');
-TYPE SERVER JOBNAME IS &SERVER
-SET &SERVICE = MSOINFO('SERVICE ','A8');
-TYPE SERVICE BLOCK NAME IS &SERVICE
-SET &APPLICAT = MSOINFO('APPLICAT','A8');
-TYPE APPLICATION NAME IS &APPLICAT
-SET &APPLGROUP = MSOINFO('APPLGROUP','A8')
-TYPE GROUP NAME IS &APPLGROUP
The first parameter in the invocation of the MSOINFO subroutine must be padded to 8 characters.
A Logon request with SERVER(FOCUS) is being rejected with the message LOGON FAILED: SPECIFIED SERVICE UNKNOWN when there is a service block with FOCUS as its service name.
The ability to access a service block with the SERVER(....) parameter on an MSO Logon request becomes disabled when Load Balancing is active in the region. The service block can only be reached this way if APPLNAME=NONE is specified and the region is initially contacted by setting Load Balancing defaults in the IBI Subsystem
MSO users may capture a dump of an IBI internal trace file. CSS researchers or IBI programming may request this trace for problem determination. This function requires additional DDnames be allocated to the CICS region. FOCDMP00 through FOCDMPnn may be allocated. At any time a CICS user may issue the following command to cause the current contents of the MSO CICS trace to be written to the selected DDname.
MSMT DUMP {*|transaction_name} DDSUFFIX(nn)
where:
Allocate the FOCDMPnn data sets to a SYOUT class or to a sequential file of 4 tracks. These data sets should have an LRECL of 102.
| Information Builders |