Technical Tips

How to ensure your CICS 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 CICS system where the application in question runs and possibly the application transaction itself (again this can be multiple people working together)

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

Test Procedure

In the following procedure we will attempt to detect whether a help request for a specific CICS 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 believed to be the target of a help request from the application 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 CICS system where the application in question runs.

4. From a cleared screen on this second terminal session type "prdp" 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 with "**AT SIGNON" under PROGRM)?

Please note:  If in step 4 above the PREFERENCE sign-on screen does not appear after entering "prdp", 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 where the second terminal session is at the sign-on screen.

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 CICS systems programmer to research the CICS setup for routing help requests to PREFERENCE.  The Additional Notes below are intended to aid the CICS systems programmer with researching this PREFERENCE setup.

Additional Notes

The PREFERENCE transaction "PRDP" ("PRDQ" for alternate screen-size applications) is used to request PREFERENCE help for an application transaction.  The "PRDP/PRDQ" transaction may be defined to run in the local CICS system (for example the TOR if an MRO environment) or on a "remote system".  However, whatever CICS region is defined to be the region where the "PRDP/PRDQ" transaction 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 CICS 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 CICS regions CICS1, CICS2 and CICS3.  Running under MVS2 we have three CICS regions CICS4, CICS5 and CICS6.  Under this CICS Production environment region CICS1 is defined to be the system where the PREFERENCE PRDP transaction is to be dispatched to.  Thus, when a user requests help for an application running under CICS1, 2, 3, 4, 5 or 6, the PRDP transaction is routed to CICS1.  The PRDP 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 CICS regions CICS7, CICS8 and CICS9.  Under this CICS environment region CICS7 is defined to be the system where the PREFERENCE PRDP transaction is to be dispatched to.  Thus, when a user requests help for an application running under CICS7, 8 or 9, the PRDP transaction is routed to CICS7.  The PRDP transaction then communicates with the PREFERENCE running in MVS3 which happens to be PREFT.

Example 2.  Demonstrates a problem of Production CICS 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 CICS1 (formerly on MVS1) switches places with CICS9 (formerly on MVS3), then we will encounter an unexpected change.  Help requests from CICS1, 2, 3, 4, 5 or 6 will be routed to CICS1.  However, now CICS1 will communicate with PREFT because that is the PREFERENCE system running under the same MVS image as CICS1.  What this means for this example is all CICS help request whether production or test will be routed to the test PREFERENCE system.

Example 3.  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 CICS1 (formerly on MVS1) switches places with CICS6 (formerly on MVS2), then we will encounter an unexpected change.  Help requests from CICS1, 2, 3, 4, 5 or 6 will be routed to CICS1.  However, now CICS1 does not have a PREFERENCE system running under the same MVS image.  What this means is all Production CICS users will receive a GC500 error message when they request PREFERENCE help.

If CICS1 in this example was still running on MVS3, 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.