Troubleshooting
Problem
Datastore cannot archive joblogs at all or joblogs build up in the JES spool which are intended for the datastore
Symptom
slow performance
Cause
tuning issues and z/OS maintenance
Diagnosing The Problem
The problem is seen when there is a large backlog of unprocessed joblogs waiting in the datastore
destination or joblogs cannot be retrieved from the datastore to perform restart and cleanup
destination or joblogs cannot be retrieved from the datastore to perform restart and cleanup
Resolving The Problem
The best datastore performance is seen with these parameters in place:
STORESTRUCMETHOD(DELAYED)
STOUNSD(Y)
NWRITER(16)
WINTERVAL(1)
If there are many large joblogs, then coding MAXUNPAGES(500) will help also.
There should be 17 UDF and SDF files allocated to the datastore task
If an SNA connection to the datastore is being used, change it to XCF is possible
as this is much more efficient.
Put this entry in your MVS SCHEDxx member:
PPT PGMNAME(EQQFARCH)
NOSWAP
KEY(8)
Then issue command SET SCH=xx
Restart the datastore task and the response should go
back to normal.
JES2 MASDEF tuning particularly the HOLD and DORMANCY parameters may also help, since
the datastore task needs to be on an LPAR which has a minimum of delay in obtaining
the JES2 checkpoint file in order to perform optimally.
A datastore task tuned as specified above should be able to process around 13,000 joblogs
per hour..
,
STORESTRUCMETHOD(DELAYED)
STOUNSD(Y)
NWRITER(16)
WINTERVAL(1)
If there are many large joblogs, then coding MAXUNPAGES(500) will help also.
There should be 17 UDF and SDF files allocated to the datastore task
If an SNA connection to the datastore is being used, change it to XCF is possible
as this is much more efficient.
If this doesn't help it is also possible to make the datastore task non-swappable as follows:
Put this entry in your MVS SCHEDxx member:
PPT PGMNAME(EQQFARCH)
NOSWAP
KEY(8)
Then issue command SET SCH=xx
Restart the datastore task and the response should go
back to normal.
JES2 MASDEF tuning particularly the HOLD and DORMANCY parameters may also help, since
the datastore task needs to be on an LPAR which has a minimum of delay in obtaining
the JES2 checkpoint file in order to perform optimally.
A datastore task tuned as specified above should be able to process around 13,000 joblogs
per hour..
,
[{"Product":{"code":"SSRULV","label":"IBM Workload Scheduler for z\/OS"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"--","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Was this topic helpful?
Document Information
Modified date:
27 June 2024
UID
swg21377945