When was the last time a SAR DB reorg was performed?
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of A T
& T Management
Sent: Wednesday, April 7, 2021 9:10 PM
To: [email protected]
Subject: Re: Questions regarding thruput expectations of CA-View(SAR)
[CAUTION: This Email is from outside the Organization. Unless you trust the
sender, Don’t click links or open attachments as it may be a Phishing email,
which can steal your Information and compromise your Computer.]
Just some thoughts: You have 23 collectors and all are going to the same
dataset? How busy is the dataset? Also, how busy is the JES2 spool? Just
thinking 23 collectors, x number of jobs dumping in to the spool Wondering if
JES2 fencing would be beneficial? I.e. Creating a few more JES spools on
different volumes where jobs would be going to the various new spool datasets
and jobs going ouot to the new JES2 spool datasets. I wonder if CA is using the
new method of extracting spool datasets are in use or they doing their own, or
perhaps using external writers to get the spool datasets?
Scott
On Wednesday, April 7, 2021, 8:36:50 PM EDT, Glenn Miller
<[email protected]> wrote:
I have a few questions that I wanted to ask the group regarding their thruput
expectations and experiences with the CA-View(SAR) software product.
First, I should say that my customer has been using the CA-View(SAR) software
product for a number of years and until recently has basically not had any
complaints/issues. However, within the past few months, we consistently
receive complaints that are basically saying..."CA-View(SAR) is slow" or
"CA-View(SAR) is working as fast now as it used to be". These complaints are
basically indicating that the CA-View(SAR) SYSOUT Collectors are not able to
immediately "process" all of the SYSOUT from the JES2 Spool and store the
output on the CA-View(SAR) disk database at "certain" timeframes. For example,
last night they had a high-water mark of over 14,000 jobs in the JES2 SYSOUT
Class that is used by the CA-View(SAR) SYSOUT Collectors. We have working with
CA/Broadcom CA-View(SAR) support and as of this time, based on the data we have
provided, they do not see any obvious areas of concern.
Is it reasonable to expect the CA-View(SAR) SYSOUT Collectors to be able to
"process" the SYSOUT from multiple hundreds of jobs per minute? Or is this an
example of trying to shovel 10 pounds of "stuff" into a 1 pound can?
After doing some investigation ourselves, we have found that during those peak
timeframes that the CA-View(SAR) SYSOUT Collectors ( we have 23 of them
running, all selecting SYSOUT from the same JES2 SYSOUT Class ) spend nearly
the entire time ( in the very high 90's % ) waiting for the Global ENQ ( we are
running GDPS Hyerswap, using GRS Star Mode ) for the resource "SARUPD" /
"hlq.SARDBASE.I0000001". We are not experiencing other issues that would
indicate that GRS is having any issues.
A little information about the configuration of this environment.
Three z13 machines, one Model 725, one Model 726, one Model 727 Three zEC12
external coupling facility machines One DS8886 (no flash storage) "GDPS Site 1"
/ One DS8886 (no flash storage) "GDPS Site 2"
10 way Sysplex / all z/OS V2R3 systems / 8 customer application z/OS systems /
2 GDPS z/OS systems The 23 CA-View(SAR) SYSOUT Collectors have always run on
only 1 of the 8 customer application z/OS systems
Any thoughts/ideas/experiences would be appreciated.
Thank you in advance,
Glenn Miller
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of HCL is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any email and/or attachments, please check them for
viruses and other defects.
________________________________
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN