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

Reply via email to