In this blog entry I will talk about what Shared Message Datasets (SMDS)
are, what problem(s) they solve and how to implement and manage SMDS in your Queue
Sharing Group (QSG).
What are Shared
Message Datasets?
Currently, shared message queues and their message data are
stored in structures that are built in the Coupling Facility. These structures are defined with a fixed
size, so all message queues assigned to a particular structure, are constrained
by this size. Once a CF structure is
full, the reason code 2192 is issued, indicating that the storage medium for
that queue is full. In V7.1 new function mode, a new construct called a Shared
Message Dataset has been introduced to prevent CF structures from filling
up. The SMDS is a linear VSAM dataset much like a pageset for non-shared queues today, but is associated with a CF
structure.
Implementing Shared
Message Datasets
Before we can implement a SMDS architecture all queue
managers in the queue sharing group need to have the OPMODE=(NEWFUNC ,710) set
in the ZPARM. Once this has been set,
and the queue managers have been restarted we can now allocate the Shared
Message Datasets.
Each Queue Manager in the queue sharing group will have its
own copy of the SMDS for a coupling facility structure. This is designated by the use of an * in the
DSGROUP parameter of the CFSTRUCT definition.
See below:
Queue Manager Queue Manager
QMA1 QMB1
/ \
/ Queue Sharing Group \
/ (QM01) \
'MQVS.QM01.QMA1.SHAREQ.SMDS' 'MQVS.QM01.QMB1.SHAREQ.SMDS'
CFSTRUCT
(SHAREQ)
DSGROUP('MQVS.QM01.*.SHAREQ.SMDS')
You can see the DSGROUP attribute is
MQVS.QM01.*.SHAREQ.SMDS. The queue manager will take the * and substitute its
name for the SMDS it is to use.
Now, let’s create and format the shared message datasets we
want to use. This is done using two
utilities, IDCAMS and CSQJUFMT.
//CRESMDSA JOB (ABCD,1234),'J LANG',CLASS=C,MSGCLASS=H
//*
//***********************************************************
//* Allocate the SMDSs
//***********************************************************
//DEFINE EXEC PGM=IDCAMS,REGION=4M
//SYSPRINT
DD SYSOUT=*
//SYSIN DD *
DELETE 'MQVS.QM01.QMA1.SHAREQ.SMDS'
ERASE CLUSTER
SET MAXCC=0
DEFINE CLUSTER -
(NAME(MQVS.QM01.QMA1.SHAREQ.SMDS) -
MEGABYTES(200 300) -
LINEAR -
DATACLAS(DCXVSM) -
SHAREOPTIONS(2 3) ) -
DATA -
(NAME(MQVS.QM01.QMA1.SHAREQ.SMDS.DATA) )
/*
//***********************************************************
//* Format the SMDS
//***********************************************************
//FORM EXEC PGM=CSQJUFMT,COND=(0,NE),REGION=0M
//STEPLIB DD
DSN=MQM.SCSQANLE,DISP=SHR
// DD
DSN=MQM.SCSQAUTH,DISP=SHR
//SYSUT1 DD
DISP=OLD,DSN=MQVS.QM01.QMA1.SHAREQ.SMDS
//SYSPRINT
DD SYSOUT=*
The job above is for the QMA1
queue manager…you will also need to change the QMA1
to QMB1 and run the job again. Also you will notice a DATACLAS
above, this is telling IDCAMS that this VSAM file has extended addressability
and can be expanded past the 4GB limit.
It can actually grow to 16TB given that you have that amount of DASD
available.
So now we have our shared message datasets for each of our
queue managers in the queue sharing group, and we also have each queue manager
running with the OPMODE=(NEWFUNC ,710). So we have two options, we can alter
our current CTSTRUCT to Level 5 and set the appropriate variables, or we can
create a new CFSTRUCT set to Level 5. If
we are creating a new struct, work will need to be done in the coupling
facility policy to allocate this new structure, and the new policy will need to
be started to become active. For the
second option you can get with your z/OS systems programmer and they will
handle that portion.
For now, let’s look at altering a current CFSTRUCT.
It is easiest to do this in a batch job since several new
attributes need to be set at the same time.
//SMDSJOBA JOB (ABCD,1234),'J LANG',
// CLASS=C,
// MSGCLASS=H
//*
//EXTRACT
EXEC PGM=CSQUTIL,PARM='QMA1'
//STEPLIB DD DSN=MQM.SCSQANLE,DISP=SHR
// DD DSN=MQMQ.QMA1.SCSQAUTH,DISP=SHR
// DD DSN=MQM.SCSQAUTH,DISP=SHR
//SYSPRINT
DD SYSOUT=*
//SYSIN DD *
COMMAND
DDNAME(INPUT)
/*
//*
//INPUT DD *
ALTER -
CFSTRUCT('SHAREQ') -
DESCR('Level 5 CFSTRUCT') -
CFLEVEL(5) -
RECOVER(YES) -
OFFLOAD(SMDS) see
note 1 -
OFFLD1TH(70)
see note 2 -
OFFLD1SZ(32K) “ -
OFFLD2TH(80) “ -
OFFLD2SZ(4K) “ -
OFFLD3TH(90) “ -
OFFLD3SZ(0K) “ -
DSGROUP('MQVS.QM01.*.SHAREQ.SMDS') -
DSBLOCK(256K) -
DSBUFS(100) -
DSEXPAND(YES) -
RECAUTO(NO) -
CFCONLOS(TERMINATE)
/*
//*
Note 1: When changing the level of
a CFSTRUCT to 5, the OFFLOAD parameter must be set to DB2 or SMDS. In our case, we are using shared message
datasets due to the performance impact of using DB2. (this topic is for another
paper)
Note 2: There are three sets of
offload rules that the queue manager uses. These contain the percentage that the
coupling facility structure must reach before the rule kicks in. In our listing above, we have the following:
OFFLD1TH(70)
– When the coupling facility reaches 70% full
OFFLD1SZ(32K)
– New messages greater than 32K go to the SMDS
OFFLD2TH(80)
– When the coupling facility reaches 80% full
OFFLD2SZ(4K)
– New messages greater than 4K go to the SMDS
OFFLD3TH(90)
– When the coupling facility reaches 90% full
OFFLD3SZ(32K)
– New messages greater than 0K go to the SMDS
Special Note: There is still some
data stored in the coupling facility for a message that is offloaded to the
SMDS, so the larger your messages are, the more benefit you will get from using
SMDS. The 3rd rule here, says
that if the CF is 90% full, all new messages go to the SMDS. For messages that are under 140 bytes, you
will not benefit from this rule, and the CF will still become 100% full because
while it is moving let’s say 100 bytes messages to the SMDS, it is using more
space than that to control the pointers to these messages.
So now we have our CF at level 5, and we have our SMDS
allocated. You need to make sure the
that the queue manager started task ID’s have UPDATE access to the SMDS VSAM
datasets. (RACF Rules). The owning queue manager will have its SMDS open for
UPDATE, other queue managers in the group will have all other SMDS’s open for
READONLY.
There are several new commands that system programmers have
available to them to aid in the management of the SMDS. Below are a few of the
most common: (you will use your own queue manager name)
/-QMA1 DIS
SMDSCONN(QMA1) CFSTRUCT(SHAREQ)
Display the status and availability to the SMDS by the queue manager.
Output:
CSQM201I –QMA1
CSQMDRTC DIS SMDSCONN DETAILS
SMDSCONN(QMA1)
CFSTRUCT(SHAREQ)
OPENMODE(UPDATE)
STATUS(OPEN)
AVAIL(NORMAL )
EXPANDST(NORMAL )
END SMDSCONN DETAILS
/-QMA1 START SMDSCONN(QMA1) CFSTRUCT(SHAREQ)
Start the
connection to
the SMDS from the queue
manager. This will
allocate and open
the
SMDS if it is new, otherwise
it automatically happens.
Output:
-QMA1
CSQMSSMD ' START SMDSCONN' NORMAL COMPLETION
The change you will see from the
start will be shown by displaying the connection.
While running a job to load the
queue, you will see expansion messages in the queue manager address space if it
is allocating more space for the SMDS…this is much like normal page set
expansion.
CSQE213I -QMA1
CSQEDSS2 SMDS(QMA1) CFSTRUCT(SHAREQ)
data set
MQVS.QM01.QMA1.SHAREQ.SMDS is now 98% full
CSQE239I -QMA1
CSQEDSS2 SMDS(QMA1) CFSTRUCT(SHAREQ)
data set
MQVS.QM01.QMA1.SHAREQ.SMDS has become full so new large
messages can no longer
be stored in it
CSQE212I -QMA1
CSQEDSI1 Formatting is complete for
SMDS(QMA1)
CFSTRUCT(SHAREQ) data set MQVS.QM01.QMA1.SHAREQ.SMDS
CSQE217I -QMA1
CSQEDSI1 Expansion of SMDS(QMA1)
CFSTRUCT(SHAREQ) data
set MQVS.QM01.QMA1.SHAREQ.SMDS was successful
76860 pages added, total pages
128160
While this is happening, your job, or channels will be
paused until the expansion completes.
Other SMDS commands: (for a complete list of parameters, see
MQ Command Reference)
ALTER SDMS (qmgr|*)
CFSTRUCT(cfname) DSBUFS(number)
DSEXPAND(yes|no|)
DISPLAY SMDS (qmgr|*)
CFSTRUCT(cfname) WHERE(filter)
DISPLAY SMDSCONN (qmgr|*)
CFSTRUCT(cfname) WHERE(filter)
RESET SMDS (qmgr or
*) CFSTRUCT(cfname) ACCESS(enabled|disabled)
STATUS(failed|recovered)
START SMDSCONN (qmgr
or *) CFSTRUCT(cfname)
CMDSCOPE(‘
‘|qmgr|*)
STOP SMDSCONN (qmgr
or *) CFSTRUCT(cfname)
CMDSCOPE(‘
‘|qmgr|*)
Optional parameter
Testing:
I had two CF structures
established of the same size. One was at
Level 4, one was at Level 5 with a SMDS assigned to the CFSTRUCT. I attempted to put 50,000 messages that were
40,000 bytes each. In the Level 4
CFSTRUCT, I was able to load 4710 messages in the queue before the RC 2192 was
returned stating that the CF was full.
In the Level 5 structure with the SMDS assigned, once the CF level
reached 70%, the data started going to the SMDS and I was able to put all
50,000 messages on the shared queue.