How To
Summary
Analysis of CPU usage by a controller task typically shows that a large percentage of CPU is spent
in VSAM buffer management. This can be improved by setting up the zWS VSAM files to use VSAM SMB
(system managed buffering) instead of LSR (local shared resources) or NSR (non-shared resources).
An IDEA was opened for this:
Use VSAM system managed buffers (SMB) instead of LSR to reduce the CPU consumption by the controller task by around 40% [ZWS-I-369]
Objective
Reduce CPU consumption by the zWS controller task
Environment
These changes are meant to be tried in a sandbox / test environment to measure the performance effect and if beneficial, to make the same changes to a development or production environment. This technote will be revised as additional feedback / customer experiences are received so that the most useful information (for example, the files for which the biggest improvement is received) will be highlighted.
Steps
To be able to define VSAM extended datasets requires a DFSMS DATACLAS set up with
(DATA SET NAME TYPE = EXTENDED REQUIRED and EXTENDED ADDRESSABILITY = YES )
DATACLAS LAST TIME EXTENDED
NAME MODIFIED DATA SET NAME TYPE ADDRESSABILITY
--(2)--- --(25)--- -------(26)------- -----(27)-----
]DCEXT 14:26 EXTENDED REQUIRED YES
In this example, DCEXT is the dataclas that can be used.
The steps required to change a VSAM file to EA (extended addressability) and use it with VSAM SMB are as follows:
A) Allocate the new extended VSAM data sets
B) Stop the controller.
C) Copy the old VSAM data sets to the extended VSAM data sets.
D) Rename the data sets (so that the files allocated will be the EA ones
E) Modify JCL to specify that SMB should be used
F) Modify controller parameters (if needed)
G) Start the controller
The steps required for one file (these can be repeated for any additional files are:
Start with normal VSAM file definition (for example CP1) :
DEFINE +
CLUSTER ( +
NAME('ZWS.V10R1M0.ZWSA1V.CP1') REUSE +
NONSPANNED +
SHR(3) VOL(I#US07) CYLINDERS(4 4) +
) +
DATA ( +
NAME('ZWS.V10R1M0.ZWSA1V.CP1DATA') +
KEYS(19 0) RECORDSIZE(200 32000) +
) +
INDEX ( +
NAME('ZWS.V10R1M0.ZWSA1V.CP1INDEX') +
)
Allocate new VSAM file with extended addressability dataclas:
DEFINE +
CLUSTER ( +
NAME('ZWS.ZWSA1V.MILLION.CP1') REUSE +
STORCLAS(PRIMARY) +
DATACLAS(DCEXT) +
NONSPANNED +
SHR(3) VOL(I#US01) CYLINDERS(4 4) +
) +
DATA ( +
NAME('ZWS.ZWSA1V.MILLION.CP1DATA') +
SPEED +
KEYS(19 0) RECORDSIZE(200 32000) +
) +
INDEX ( +
NAME('ZWS.ZWSA1V.MILLION.CP1INDEX') +
)
Stop the controller.
Copy original file into new VSAM EA file:
//STEP10 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
REPRO -
INDATASET(ZWS.V10R1M0.ZWSA1V.CP1) -
OUTDATASET(ZWS.ZWSA1V.MILLION.CP1) -
REPLACE
Rename so that the CP1 allocated to the controller will be the EA file:
//STEP20 EXEC PGM=IDCAMS,REGION=6M
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ALTER -
ZWS.V10R1M0.ZWSA1V.CP1 -
NEWNAME(ZWS.ZWSA1V.OLD.CP1)
ALTER -
ZWS.V10R1M0.ZWSA1V.CP1DATA -
NEWNAME(ZWS.ZWSA1V.OLD.CP1DATA)
ALTER -
ZWS.V10R1M0.ZWSA1V.CP1INDEX -
NEWNAME(ZWS.ZWSA1V.OLD.CP1INDEX)
ALTER -
ZWS.ZWSA1V.MILLION.CP1 -
NEWNAME(ZWS.V10R1M0.ZWSA1V.CP1)
ALTER -
ZWS.ZWSA1V.MILLION.CP1DATA -
NEWNAME(ZWS.V10R1M0.ZWSA1V.CP1DATA)
ALTER -
ZWS.ZWSA1V.MILLION.CP1INDEX -
NEWNAME(ZWS.V10R1M0.ZWSA1V.CP1INDEX)
Add AMP= parameter for this file (so that VSAM SMB will be used) in the controller JCL and also any CP or LT batch JCL:
//EQQCP1DS DD DISP=SHR,DSN=ZWS.V10R1M0.ZWSA1V.CP1,
// AMP=('ACCBIAS=SYSTEM,MSG=SMBBIAS')
The MSG value will generate (once per file) a message like:
IEC161I 001(DW)-255,VA1C,VA1C,EQQADDS,,,ZWS.V10R1M0.ZWSA1V.AD,,
IEC161I CATALOG.USER.SYSPLEXI
to show what VSAM processing type will be used. For example:
DO - Direct optimized (LSR): The DO processing technique optimizes for totally random record access. This is appropriate for applications that
access records in a data set in totally random order.
SO - sequential optimized: The SO technique optimizes processing for record access that is in sequential order.
DW - direct weighted: The majority is direct processing; some is sequential. DW processing provides the minimum read-ahead buffers for sequential
retrieval and the maximum index buffers for direct requests.
SW - sequential weighted: The majority is sequential processing; some is direct. This technique uses read-ahead buffers for sequential requests
and provides additional index buffers for direct requests. The read-ahead will not be as large as the amount of data transferred with SO.
If the CP related files (CP1, CP2) have been modified to use SMB these parameters can be set to eliminate
unneeded LSR processing:
OPCOPTS
CPBPLIM(1)
CPDTLIM(1)
Note the complete set of CP related files is:
NCP,CP1,CP2,SCP, ACP (if using DB2 history function), NXD, XD1, XD2
Restart the controller
Run a similar workload to what was done BEFORE the changes to see what the reduction of CPU time is.
Additional Information
For the purposes of benchmark testing of the procedure, the following groups of files were modified:
(1) AD, NCP,CP1,CP2,SCP, ACP (if DB2 history function is used), WS
(2) XD1,XD2,NXD,SI
(3) NCX,CX,RD (these should help if Special Resources (SR) is heavily used)
(4) Not tried in benchmark testing - LT, JS1, JS2 (these could also be beneficial)
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
22 October 2026
UID
ibm17293179