Technical Tips

How to ensure IMS help requests are routed to the correct PREFERENCE System.

If you are running more than one PREFERENCE system in your installation, then you may encounter anomalies when your application region is defined to connect to the wrong PREFERENCE system.  For example help requestors may receive the wrong help, incomplete help or possibly no help (i.e. the user is taken to the PREFERENCE sign-on screen or the application screen remains unchanged). 

Authorizations you will require to perform this procedure.

To ensure your help requests are being routed to the correct PREFERENCE System, you will require authority for the following:

• supervisor access to all PREFERENCE systems (if necessary this can be multiple people working together)

• access to the IMS application in question (again this can be multiple people working together)

• for the Additional Notes section you may require the assistance of your IMS systems programmer

Before you begin the Test Procedure below, you will need to check with the group responsible for the IMS application transaction in question to determine the specific name of the PREFERENCE help transaction (i.e. the default name is "CBHIMS") being used by the specific IMS transaction.  Each IMS transaction could be using a different name for "CBHIMS".  You will need to get the exact name being used by the specific IMS transaction.  This is important because each "CBHIMS" transaction name can be assigned different routing.

Test Procedure

In the following procedure we will attempt to detect whether a help request for a specific IMS transaction is being routed to a specific PREFERENCE system.  It is easiest to interpret this testing when you have a small number of users signed on to the PREFERENCE region in question.  Thus, we recommend performing this testing during a window of time when there are few users signed on.  To begin this testing perform the following steps:

1. From one terminal session sign-on as a supervisor to the PREFERENCE system that you believe is the target system of a help request from the application region in question.  For example if this is the production application region, you would probably sign-on to the production PREFERENCE region.

2. At the "Type Command Line" of this first session type "ls" as in Line Status and press ENTER.  If there is a small number of lines signed on, you should be good to proceed.

3. From a second terminal session sign-on to the IMS system where the application transaction in question runs.

4. From a cleared screen on this second terminal session type the specific name for the "CBHIMS" transaction (obtained from the application group) followed by a single space and press ENTER.  This should take you to the PREFERENCE sign-on screen.  In the upper-right corner you should see "TERMINAL ID:" followed by this sessions "terminal-ID".  Record this "terminal-ID" for the next step.

5. Again from the first terminal session type "ls" as in Line Status and press ENTER.  Has the second terminal session been added near the bottom of the Line Status Report (i.e. you should see the "terminal-ID" from step 4 above)?

Please note:  If in step 4 above the PREFERENCE sign-on screen does not appear after entering the specific name for the "CBHIMS" transaction, inform the system administrator responsible for PREFERENCE of this situation.

If the second terminal's session is not found while performing the above, then from the first terminal session sign-off of the current PREFERENCE system, sign-on to another of your PREFERENCE systems as a supervisor and repeat the above procedure (step 5).  Repeat this process until you have found the PREFERENCE system with the second terminal session.

If you found the second terminal's session while performing the above, then help requests for the application in question are being routed to the PREFERENCE System where the first terminal supervisor session is signed on.  If this is the PREFERENCE system designed to provide help for the application in question, then your setup is fine.

If you find from the above that your application in question is having help requests routed to the wrong PREFERENCE system, then you need to contact your IMS systems programmer to research the IMS setup for routing help requests to PREFERENCE.  The Additional Notes below are intended to aid the IMS systems programmer with researching this PREFERENCE setup.

Additional Notes

The PREFERENCE transaction "CBHIMS" is used to request PREFERENCE help for an IMS application transaction.  You may have many "CBHIMS" transaction definitions by different names to support your IMS application transactions.  The user(s) performing the procedure above should be able to supply the name of the "CBHIMS" transaction they were using while testing the above.

The "CBHIMS" transaction names can be defined to run in different IMS Message Processing Regions (MPR).  However, whatever MPR is defined to be the region where the "CBHIMS" transaction name is to be dispatched to must run in the same MVS image as the targeted PREFERENCE system.  The following shows an example of a correctly configured system followed by examples that result in misrouting of PREFERENCE help requests.

Example 1.  Demonstrates Production and Test IMS help requests being routed to the correct PREFERENCE systems.

We have three MVS images running (MVS1 - Production, MVS2 - Production and MVS3 - Test).  Under MVS1 we have PREFP, the production PREFERENCE system.  Also running under MVS1 we have three IMS MPR's as follows: MPR1, MPR2 and MPR3.  Running under MVS2 we have three IMS MPR's as follows: MPR4, MPR5 and MPR6.  Under this IMS Production environment region MPR1 is defined to be the system where the PREFERENCE "CBHIMS" transaction is to be dispatched to.  Thus, when a user requests help for an application running under MPR1, 2, 3, 4, 5 or 6, the "CBHIMS" transaction is scheduled in MPR1.  The "CBHIMS" transaction then communicates with the PREFERENCE running in MVS1 which happens to be PREFP.

Under MVS3 (the test system) we have PREFT, the test PREFERENCE system.  Also running under MVS3 we have three IMS MPR's as follows: MPR7, MPR8 and MPR9.  Under this IMS environment region MPR7 is defined to be the system where the PREFERENCE "CBHIMS" transaction is to be dispatched to.  Thus, when a user requests help for an application running under MPR7, 8 or 9, the "CBHIMS" transaction is scheduled in MPR7.  The "CBHIMS" transaction then communicates with the PREFERENCE running in MVS3 which happens to be PREFT.

Example 2.  Demonstrates Production IMS help requests being miss-routed to the wrong PREFERENCE systems or to a PREFERENCE unavailable situation during times of high activity.

For this example we have the same setup as above except the MPR1 region is not the only one available to process the selected PREFERENCE "CBHIMS" transaction.  We have an IMS definition APPLCTN Macro specification of SCHDTYP=PARALLEL.  The IMS TRANSACT Macro definition for this "CBHIMS" transaction has the PARMLIM= specified to define the threshold value of when another MPR is to be scheduled.  When the threshold is reached, MPR4 and MPR7 are defined to process the "CBHIMS" transaction.  Thus, during times of high activity the "CBHIMS" transaction could be scheduled to run on the MPR4 region.  This would result in the user receiving a GC500 error message.  If the MPR7 region is scheduled, then this production help request will be processed by the test PREFERENCE system.

Example 3.  Demonstrates a problem of Production IMS help requests being routed to the Test PREFERENCE system.  This example assumes the PREFERENCE subsystem-ID being used for PREFP and PREFT is the same only they are defined to different MVS images.

If a change is made to the configuration (possibly due to Sysplex) of MVS1 and MVS3 as shown above where MPR1 (formerly on MVS1) switches places with MPR9 (formerly on MVS3), then we will encounter an unexpected change.  Help requests from MPR1, 2, 3, 4, 5 or 6 will be routed to MPR1.  However, now MPR1 will communicate with PREFT because that is the PREFERENCE system running under the same MVS image as MPR1.  What this means for this example is all IMS help request for this PREFERENCE "CBHIMS" transaction whether production or test will be routed to the test PREFERENCE system.

Example 4.  Demonstrates a configuration where PREFERENCE help requestors will receive a GC500 error message.  This example assumes the PREFERENCE subsystem-ID being used for PREFP and PREFT are different.

If a change is made to the configuration (possibly due to Sysplex) of MVS1 and MVS2 as shown above where MPR1 (formerly on MVS1) switches places with MPR6 (formerly on MVS2), then we will encounter an unexpected change.  Help requests from MPR1, 2, 3, 4, 5 or 6 will be routed to MPR1.  However, now MPR1 does not have a PREFERENCE system running under the same MVS image.  What this means is all Production IMS help request for this PREFERENCE "CBHIMS" transaction will receive a GC500 error message when they request PREFERENCE help.

If MPR1 was still running on MVS3 as in example 3 above, it would attempt to communicate with a non-PREFERENCE subsystem-ID (i.e. PREFT is using a different subsystem-ID than PREFP).  This would result in the help requester receiving a GC500 error message.

If you believe you have a PREFERENCE setup problem similar to the above and you need assistance, please contact SumTotal's technical support.  Click here for information on contacting SumTotal technical support.