ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

After a CA Datacom/DB Multi-User (MUF) environment was upgraded from version 14.0 to 15.1, all but one of the 40 CICS regions were able to connect. The problem CICS region log showed RC 68(001)...

book

Article ID: 5378

calendar_today

Updated On:

Products

Datacom DATACOM - AD CIS COMMON SERVICES FOR Z/OS 90S SERVICES DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS COMMON PRODUCT SERVICES COMPONENT Common Services Datacom/AD CA ecoMeter Server Component FOC EASYTRIEVE REPORT GENERATOR FOR COMMON SERVICES INFOCAI MAINTENANCE IPC UNICENTER JCLCHECK COMMON COMPONENT Mainframe VM Product Manager CHORUS SOFTWARE MANAGER CA On Demand Portal CA Service Desk Manager - Unified Self Service PAM CLIENT FOR LINUX ON MAINFRAME MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME GRAPHICAL MANAGEMENT INTERFACE WEB ADMINISTRATOR FOR TOP SECRET Xpertware

Issue/Introduction

After a CA Datacom/DB Multi-User (MUF) environment was upgraded from version 14.0 to 15.1, all but one of the 40 CICS regions were able to connect. The problem CICS region log showed error:

DB00121I - UNAVAILABLE - mufname1,mufname2
DB00122I - ACCESS TYPE - LOCAL,XCF(mufname)    TASKS=n
DB00501E - OPEN ERROR - RETURN CODE 68 (001) CXX=                    MUFNAME=mufname

Cause

Customer dumped the DBINRPR modules in both regions and found different RMIDs for each.

The CICS region that was not working had an outdated library in the DFHRPL that had a copy of an old DBINRPR.

Customer had a version 14.0 DBINRPR (and other) modules in the CICS region that was unable to connect to the version 15.1 MUF. 

This library was used prior to version 14.0 but was supposed to have been removed.

Environment

z/OSCICS/TS

Resolution

They removed the library, cycled the CICS region, and it connected to the 15.1 MUF without a problem. 

Additional Information

The rules for back-level support means that DBINRPR is one release and it needs to connect to a MUF that is of a lesser release. 

In this case the DBSIDPR drives the process and the DBSIDPR is required to be at the same release as the MUF it is connect to. 

A DBINRPR at version 15.n can connect to a MUF at 14.0 ONLY if the DBSIDPR is also built from 14.0 libraries. 

It has also been the pattern that DBINRPR needs a DBSIDPR at its same release to talk to the MUF at that release.