Managing qname SYSZCNZ in a monoplex Environment.
search cancel

Managing qname SYSZCNZ in a monoplex Environment.

book

Article ID: 50985

calendar_today

Updated On:

Products

MIM Resource Sharing (MIM) MIM Data Sharing (MII) MIM Tape Sharing (MIA) MIM Message Sharing (MIC)

Issue/Introduction

Consoles, whether MCS, SMCS, subsystem, or EMCS, have never been allowed to be active on more than one system in a sysplex at one time. In a monoplex environment, duplicate console names are allowed.

This document will assist you in identifying the current management of the SYSZCNZ qname in your environment and provide the steps necessary to remove the qname from MII management if you are running in a monoplex and this qname is incorrectly managed.

 

Environment

Release:
Component: MICS

Resolution

IBM provides the following information regarding use of the SYSZCNZ qname in a sysplex:
Consoles (MCS, SMCS, subsystem, or EMCS) have never been allowed to be active on more than one system in a sysplex at one time. Beginning with z/OS V1R10, new resource SYSZCNZ CONNAME#consolename is held while a console is active. If the ENQ cannot be obtained, the console does not activate. If serialization is managed within a global resource serialization ring complex, the console can only be active on one system, even if the systems are not part of the same sysplex.

A similar ENQ called SYSZCNZ USERID#userid is obtained when a user logs on to an MCS or SMCS console. The same naming restrictions would apply to the logon ID. Note that multiple global resource serialization complex sharing through third-party alternate serialization products (MII) will not cause this problem because all the related ENQs are issued with RNL=NO to prevent third-party management.

The rest of this document discusses the SYSZCNZ qname in a monoplex environment:
In a MONOPLEX environment, duplicate console names are allowed. Some customers have multi-system environments that run as monoplexes.

In a monoplex environment, there can be false contention resulting from MII managing the SYSZCNZ qname. MII may be managing SYSZCNZ because the RNL=NO option does not apply. A MIM DISPLAY CONFLICTS command can show the number of global conflicts that have occurred for the SYSZCNZ qname.

Note that this scenario assumes that you have SYSZCNZ coded as GDIF=YES or are running PROCESS=ALLSYSTEMS, where MII will manage this qname by default.

If you find that SYSZCNZ is being managed by MII incorrectly in your monoplex environment, you may follow these instructions to dynamically remove SYSZCNZ from MII management. This can be accomplished via the MIM ADDQNAME/DELQNAME commands:

    1. Issue the DELQNAME command to delete the qname from MII management:
      F MIM,DELQNAME QNAME=SYSZCNZ

DELQNAME has no effect on the current status of resources in this qname class (that is, for resources currently enqueued). This command is a global command and needs to be issued only on one system in the complex. CA MIM then communicates the information to the other systems. A system that later joins the complex will adjust its qname list to match the other systems.

  1. Update the MIMQNAME list to permanently reflect the changes for SYSZCNZ:
    QNAME=SYSZCNZ   GDIF=NO
  2. Issue the ADDQNAME command:
    F MIM,ADDQNAME QNAME=SYSZCNZ GDIF=NO

Information on the ADDQNAME and DELQNAME commands can be found in Chapter 5 'CA MII Statements and Commands' of the MIM Statement and Command Reference Guide.