LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (September 2010)Back to main CICS-L pageJoin or leave CICS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Tue, 14 Sep 2010 14:58:51 EDT
Reply-To:     CICS List <CICS-L@LISTSERV.UGA.EDU>
Sender:       CICS List <CICS-L@LISTSERV.UGA.EDU>
From:         Robert Zenuk <Robzenuk@AOL.COM>
Subject:      Re: CICS Performance Analysis
Content-Type: multipart/alternative;

The HTASK table is all the TASK data (basically an SMF 110 record). This is nice, but creates a second copy of your SMF 110 data... Aside from the shear volume in our environment and the possibility that someone might actually run a query against all of it, we decided not to use it. We use the historical SMF 110 data with a set of tailored/homegrown MICS/MXG/SAS reports for post analysis. We also use Omegamon/CICS and we do have Omegamon Task History setup and use that for simple near term (less than a day) historical analysis. We can pull interim SMF data for anything more complex. The history in Omegamon/CICS Classic is more detailed than what you can see in the CUA version, but the query/selection capability is limited to a single CICS region and has only basic selection criteria. So (to kill 2 birds with one stone Michele), we use BOTH the CPSM/WUI and Omegamon in our monitoring strategy. The WUI gives us the cross-plex view for all resources and subsets. It allows us to create auto-updating views with summaries and effective sorts to identify quickly the problematic resource and which LPAR and CICS it lives on. At that point, we use Omegamon/CICS to drill into the region and figure out the problem with the gnat's ass detail available in Omegamon. While I have built some pretty cool drill down screens for the WUI to make all that research quicker and easier, I only do that for common recurring issues since many times it means build/tailoring new/existing screens. Don't get me wrong, it is not hard to create WUI screens and I have done it during the heat of the battle in a crisis if it creates a better view into what is happening. But I have not gone out and built all the possible ways to drill into a problem. I have a lot of scenarios built, but it is not a be all to end all. So, Omegamon is still a valuable tool for us. Like I said before, it depends on your focus during selection. My focus is quick, obvious, early problem detection and customer impact avoidance during day-to-day operations in a high volume shop. So, the WUI's easily tailorable, summarizable, auto-updateable pre-built screens for our command center's bigboard are a key consideration... While Explorer is very nice, it currently can't handle that role in our shop. I believe Explorer's current focus is simplifying the CICS administration activities for the next generation of Sysprogs and the quick query. If and when it comes back around to implementing features that facilitate improved real-time monitoring (at least on par with the WUI), we can reconsider it for the role we currently use the WUI for... Rob In a message dated 9/14/2010 10:21:59 A.M. US Mountain Standard Time, kevin.evans@LEO.GOV writes:

We do use DB2, but the majority of our online code get generated from CA/Gen. I’m not sure ( I work on the communications side) whether we can do much about what code comes out of CA/Gen even if Ca-Insight suggests any changes. CPSM WUI has a historical view? Based on what? SMF records. I admit that for what I need, I use CICS Explorer vs the WUI. K From: CICS List [mailto:CICS-L@LISTSERV.UGA.EDU] On Behalf Of Thurlo, Mark C. Sent: Tuesday, September 14, 2010 1:05 PM To: CICS-L@LISTSERV.UGA.EDU Subject: Re: CICS Performance Analysis

Hi Kevin Another suggestion I would make is a good DB2 monitor, unless your applications are VSAM based. Over the years, as VSAM was phased out in favor of DB2, I think it’s become more important to know what’s happening in DB2 than CICS. As an example, we had a DB2 performance specialist come in and do a DB2 bufferpool analysis. His recommendations helped our performance significantly. For us, to resolve deadlocks and long response times generally requires analyzing what’s happening in DB2. We use CA-Insight as a DB2 monitor, and CA-SSA (sub-system analyzer) as a way to get interval statistics without having DB2 statistics turned on. We also correlate CICS and DB2 SMF records to get the full picture. Even though we have CA-SYSVIEW, I rarely use it. It lacks a CICSPlex view. The CPSM WUI can show you a lot of what monitors give you. So, I usually go to CPSM instead. CPSM even has a history view now. Mark Thurlo SuperValu Inc From: CICS List [mailto:CICS-L@LISTSERV.UGA.EDU] On Behalf Of Robert Zenuk Sent: Tuesday, September 14, 2010 11:03 AM To: CICS-L@LISTSERV.UGA.EDU Subject: Re: CICS Performance Analysis

I see your initial list as different products... As far as I'm concerned. the true monitors are:

Omegamon/CICS Mainview/CICS Sysview/CICS TMON/CICS

I have had the opportunity to use all 4 and they all have their strengths and weaknesses (as well as price points - having been on the budgeting side in the past). I apologize if I missed anyone else.

Another tool rarely included in this list (and is FREE) is using a tailored CPSM WUI as a Performance Monitor. Since CICS/TS 3.2 all the existing issues with WUI hangs have finally all gone away (with correct timeout configuration of course). Between the WUI, CICS Explorer and API programs, you can build almost anything you want and/or need... The out of the box screens are pretty good to start with, but it is a very easy to use and tailorable product.

So, these 5 are the "online" monitors that allow you to watch real-time online activity.

I see CICS PA as a batch post processor of SMF 110's... Good stuff, but not in the real-time online group in my opinion.

I see Strobe as an application debugging tool. It is great for finding out where you are spending you time, but at a cost (high CPU). We had to abandon Strobe due to cost... We now have Tritune for this purpose... Not quite as detailed, but functional (watch out for their default installation - can be very high CPU and generate TONS of SMF records). In both cases we did not and do not run these tools all the time. Due to the high overhead, times are scheduled to turn on the tool for a specific debugging request. It is turned off immediately following the debugging session. It actually requires change tickets or problem tickets to turn it on in Production.

Back to the online monitors. Over the years I have been involved in several monitor evaluations. Each one was slightly different because the target audience was different... If you are buying an online monitor for operations, quick visibility and folks that may not be CICS Sysprogs, you can make one decision. If you are buying a monitor for 25 year veteran CICS Sysprogs, you might buy a different monitor (probably stamped with a huge opinion). If batch reports are important, you might make a different decision...

So, I say it depends on your audience. Your evaluation should be focused on the satisfying the requirements of your biggest audience with the most intuitive tool for them. The remainder of the analysis should focus on the list of required capabilities for rest of the users. Things I also like to consider are interfaces for automation (specifically REXX - both TSO and Netview).

Rob

In a message dated 9/14/2010 7:29:25 A.M. US Mountain Standard Time, bjwhite66212@YAHOO.COM writes:

I have used Omegamon, TMON, CA-SYSVIEW, Mainview and Strobe. We have Mainview, but only the MQ components, not CICS Support. Strobe seems to be a more specialized tool, it gives a more intense analysis that I used for specific problems, like where CPU was being used within modules.

Each had its pros and cons. I was able to get the job done with any product.

Like many things, it is what you like and afford.

I like the report generation of CICS PA. Since you use CICSPlex, CICS PA might fit in good with CICS Explorer. ____________________________________ From: Kevin Evans <kevin.evans@LEO.GOV> To: CICS-L@LISTSERV.UGA.EDU Sent: Tue, September 14, 2010 8:22:14 AM Subject: CICS Performance Analysis I have been tasked with looking at performance analysis products again. Although we currently have Omegamon XE here (at great cost), it is not used much at all. It seems to be viewed by the systems people as too complicated and too slow (in the GUI mode anyway with the TEPS and TEMS etc). So, I’m looking at analysis products so that we can try and understand our performance now, project (hopefully) future performance (especially WRT to when hardware upgrades may be needed). Current configuration is basically two Z9 CPCs (plus others at our DR site) running CICS 3.2, MQ V7 under z/OS 1.10 in a SysPlex and CICSPlex environment. I have basically restricted my looking to: CICS PA (with possible IA for other reasons) TMON Mainview Strobe We have used TMON and Strobe in the past (although I had nothing to do with those). I would be interested in anyone giving me any feedback on what they view the strengths and weaknesses of the above products. We are moving (slowly) to using Rational Developer for System/z, so PA and IA with their RD/z plugins play well in that arena. Thanks in advance, Regards, K Kevin R Evans Department of Justice Federal Bureau of Investigation Systems Development Unit 1000, Custer Hollow Road SDU-B2 Clarksburg WV, 26306-1000 304-625-5870 304-672-5523 (Cell) kevin.evans@leo.gov


[text/html]


Back to: Top of message | Previous page | Main CICS-L page