Skip navigation
1 2 Previous Next

MainView

28 Posts authored by: Martin Beasley Moderator
Share This:

 

MainView SYSPROG Service v3.7.00 went GA on September 14, 2012. As you are probably aware, MainView SYSPROG Services is available as part of MainView for z/OS as many of the SYSPROG Services can be used by MainView AutoOPERATOR, see MainView AutoOPERATOR Solutions Guide and MainView AutoOPERATOR Advanced Automation Guide for sample SYSPROG solutions.

 

 

There are 4 new services:

 

ANALYZE – The ANALYZE (ANA) service examines the system for backlog of work issues – address spaces waiting to be dispatched, or jobs waiting for an enqueue. Issuing the command will give you the following response:

 

AMTAN5I n Address spaces are waiting to be dispatched

 

AMTAN1I n waiting for resource held by VAM3NQ1 (0061) SJSD?AMTAN2I QNAME=qname,RNAME=resource_name

 

AMTANZI No problems found

 

 

JCPU – The JCPU service provides the ability to locate the address spaces that are the highest user of CP, zIIP, and zAAP processors. It reports on these processor distribution utilization during the sample period. The sample period can be defined between 1-60 seconds with the default of 5 seconds. The unused processor time is not measured, so the total utilization will always be 100% (subject to rounding errors).

 

Issuing – JCPU,1,CP – will sample processor usage for one second and sort the resulting data by the column containing CP utilization in descending sequence:

JCPU.jpg

 

PBUILD – The PBUILD (PLB) service allows you to create or modify exclusion lists after initialization of SYSPROG Services. Exclusion list are used to exclude jobs, replies, enqueues and volumes serial numbers for different SYSPROG Services. PBUILD will process contents of an exclusion list member in a partitioned data set. The exclusion lists support are $$INEXCL, $$RPTEXT, $XENQ, or $$XRS.

 

PLIST – The PLIST (PLI) Service display the active exclusion list and the contents for $$INEXCL, $$RPJOBS, $$RPTEXT, $$XENQ, or $$XRES. This service also displays the name of the list’s creator and time – date when list was created.

 

 

There are also 4 enhanced services:

 

PROGRESS (*) – Display the status and current step information for a specified address space.

JITOKEN – Displays when the job instance was initiated, elapsed execution time, current step name, service class, STOKEN, and accounting data.

TCB – Displays improved output and creates symbols representing the contents of registers and other key fields

IFA – Displays the ASID in addition to the job name.

 

(*) – There are currently 2 version of the PROGRESS service. The new version is the default unless SYSPROG Services is operating under the control of AutoOPERATOR, in which case the PROGRESS version distributed in SYSPROG Services 3.6 is the default. You can use the version parameter to select your preferred PROGRESS version.

 

For more information of what is new in MainView SYSPROG Services, please refer to the release notes.

Share This:

Below is a new customer success story featuring CMF MONITOR at Generali Deutschland Group.

 

HOUSTON, Sept. 24, 2012

Generali Deutschland Group implemented the

BMC CMF MONITOR solution from BMC Software (NASDAQ:BMC) to lower mainframe costs, while providing performance and capacity data to ensure that customer requirements were always met.

"We conducted a rigorous analysis of different ways we could lower the cost of managing the mainframe environment," said Horst Schmidt, mainframe team leader at Generali Deutschland Group. "BMC CMF MONITOR, which is an integrated component of the BMC MainView monitoring solution, was an ideal means of leveraging the relationship with BMC Software and reducing the mainframe footprint cost."

He added, "Aside from the 30 percent reduction in CPU usage, BMC CMF MONITOR provides Generali with a unified platform for powerful online reporting, on-demand graphing, and the publication of critical capacity and performance data."

 

The Challenge

 

 

 

The Solution

 

Generali chose the BMC CMF MONITOR solution because of its superior ability to reduce the workload on its z/OS® mainframe computer compared to the IBM® alternative, while providing a single pane view of both real-time and historical capacity and performance. Its easy integration with the existing BMC MainView solution for CPU monitoring and management was another important plus.

 

Benefits

 

After implementing BMC CMF MONITOR, Generali has been able to:

Lower the total CPU time and costs for managing the mainframe environment by 30 percent

Offload up to 50 percent of the monitoring workload to specialized processors, reducing the load on the general purpose processors

More accurately calculate charge-back costs

Obtain a shared, integrated real-time and historical view of capacity and performance data, enabling Generali to rapidly identify and relieve bottlenecks

For more information on Generali Deutschland Group’s implementation and the BMC CMF MONITOR solution, please:

Read the full Generali case study

Follow @BMCMainframe on Twitter

Become a fan of BMC on Facebook

http://www.bmc.com/news/press-releases/2012/customer-success-generali-deutschland-group-insures-its-mainframe-environment-with-bmc-software.html

Share This:

zexpo.jpg

Not only will we highlighting and providing demonstration of MainView at booth number 42. We also be conducting the following presentations:

 

MainView - Analytics

October 2nd 8:00 to 10:15 - Room Genoa, Session ID: zQV03

Presenters: Mark Rascoe, Product Manager and Wayne Wilson, Advisory Software consultant - BMC SoftwareThis session introduces the new MainView Infrastructure  - with new dynamic performance analytics that analyzes data, creates & sets dynamic thresholds on the data, and more effectively than ever before, proactively identifies and resolves potential issues before they cause business slowdowns or outages. In this session we will discuss and demonstrate the new unique MainView components.

 

Reduce costs and increase availability - Automation in motion

October 3rd 1:00 to 2:15 - Room Modena, Session ID: zQV15

Presenter: Mark Rascoe, Product Manager, BMC Software

This presentation we will cover Automation from operations point of view, covering HMC Management as well as start-up/shutdown. We will also cover performance automation to auto-correct issues encountered with exception processing. We will cover how mainframe automation can work with enterprise wide automation, to help manage your environment from a business application perspective. 

 

Cover and visit us and speak with #waynewilson and #markrascoe at this event.

Share This:
MainView Infrastructure 6.1 introduces you to two powerful new features: Threshold Advisor and Dynamic Threshold. Here we will discuss installation and customization:
Installation

MainView Infrastructure 6.1 will be installed on the mainframe as it always has been, using the OZI installer and integrated customization tool. The customization tool will have a new phase called Infrastructure Setup that will install MainView Infrastructure 6.1 and RTCS.

New for the MVI 6.1 installation are:

  1. An additional component called UIM - our web server address space, to be installed. 
  2. A requirement for a new product level RTCS registry file for each CAS with the DDNAME = CASPERM, that you will have to allocate, either in the OZI customization process or by the view CASPERM. 
  3. A new OZI customization question for installing the UIM component, so you can specify which CAS you want to be the target for Threshold information to be uploaded to, if you use the new Threshold Advisor product. You only need to target one CAS per CASPLEX (group of connected CASs) for Threshold Advisor to communicate with, and that CAS will be able to deploy Dynamic Thresholds to all other CASs that Threshold Advisor has elements for.

  You will also need to install on a Windows server, the MainView Threshold Advisor product, and the Capacity Database (CDB) web-services. The CDB is used in conjunction with MainView Threshold Advisor to store downloaded interval data, and to perform the necessary analytics to produce recommended threshold values. 

 

Once Threshold Advisor is installed, you should decide which set of MainView Best Practice metrics you want to work with to calculate recommended thresholds. Threshold Advisor will require 3 weeks of data before it can complete a study and recommend Thresholds, so my advice is to start this activity as soon as possible.

 

You can also perform the following activities to get ready for Phase 2:

  • Set up your business week by defining Calendar Periods for which you would like to calculate different Threshold values. These Calendar Periods would normally define times where your workload is noticeably different than at other times of the day, so you would expect that different Threshold Values would allow better management, i.e. fewer false alarms.

 

MVI 6.1

Threshold Advisor – suggested customization phase 1
  1. Select a data element (metric) that you are interested in. 
    1. One that changes significantly during the test period and one where it may vary across the entire range of Threshold Values (Info, Warn, Minor, Major, Critical). This would allow you to see the full range of results. 
    2. CPUBsy% may be a good one.
  2. Define a set of Thresholds on the metric at the View Level and watch the metric change colors as it varies across the range of values. You may need to pick Threshold Levels much lower than in production to see all of the severity levels, such as CPU = 10, 20, 30, 40, and 50. You will need this View Level Threshold established to verify that the Dynamic Threshold has overridden the View Level Threshold. 
    1. You could set all Threshold results to show the value as "green". 
    2. In Dynamic Thresholds, you could set all Threshold results to show as "red" and prove that the Dynamic Threshold has overridden the View Level Threshold.

  3. Define a set of Calendar Periods that you will use for testing. 

  1. Initially the test Calendar Periods should be short (2 – 5 minutes) so you can verify that different Threshold values are in effect for different Calendar Periods. It should not be necessary to wait for hours to observe this transition. 
  2. Later you may change the Calendar Periods to times that represent what you would actually like to use in your environment.

4. Define a Threshold Set on a data element (metric) you are interested in.

  1. Define a second Threshold Set with different Threshold Values that you can associate with a different Calendar Period. This will allow you to verify that you have Dynamic Thresholds in effect, and you have different Threshold Values in effect at different times of the day.

  5. Define a Threshold Selection and assign each Threshold Set to a different Calendar Period. 

6. Now you can verify several things:

  1. As you watch the transition of time from one Calendar Period to another, you should see different Threshold Values in effect if the Threshold Selection has been set up that way. 
  2. If the View Level Thresholds were set to always show "green", and the Dynamic Threshold is in effect and set to always show "red", then the metric on the view should now be red. This would show that the Dynamic Threshold is in effect and overriding the View Level Thresholds.

7. Validate that other views that contain this metric are "red".

  1. This will show that Dynamic Thresholds are active in ALL views.

  8. Go to one view with the metric and update the Threshold definition for the view so that it specifies that on this view, the View Threshold is to override the Dynamic Threshold. 

  1. Result: all views should have the metric showing as "red" from the Dynamic Threshold definition, but this view should show the metric as "green".

9. Repeat this test scenario for Alarms.

 

Threshold Advisor – Phase 2

By now, you will have collected 3 weeks of sampled data from MainView, for the Best Practice metrics that you selected.

  1. At this point you will run the statistical analysis of the data you have collected. 
  2. This will produce recommended Threshold Values for the metrics you selected, and they will be correct for the time periods you selected for your calendar periods. You will also receive reports and graphs showing the relationship of observations that were collected and the recommended Threshold Values. Use these to check that the Threshold Values produced made sense for your environment. 
  3. When you are sure the recommended Thresholds make sense, you can PUSH them to the mainframe from your PC (Threshold Advisor). 
  4. After the PUSH completes, go to the mainframe and from the MainView product, check to be sure the thresholds you PUSHed have arrived correctly.

 

Thanks to Rich Comeau fro providing this information.

 

I am looking forward to feedback on how you are using Threshold Advisor and Dynamic Thresholds.

 

Regards,

 

Martin

Share This:

 

Threshold Advisor and Dynamic Thresholds generate intelligent alarms based on your business processing lifecycle, freeing you from actively observing your environment. Here’s how to use them.

 

MainView Infrastructure 6.1 introduces you to two powerful new features: Threshold Advisor and Dynamic Threshold. In this article, I’ll give you an overview of these features and advice on how to perform your initial customization.

 

Overview - Threshold Advisor

Threshold Advisor provides the ability to extract "Best Practice" metric values from the different MainView monitoring products, currently:

  • MainView for z/OS
  • CMF MONITOR
  • MainView for CICS
  • MainView for DB2
  • MainView for IMS
  • MainView for WebSphere MQ

Threshold Advisor stores the threshold value for each metric on an interval basis. This data is downloaded to a Window’s based server and loaded into a Threshold Management Database (TMD). After a period of time (2-3 weeks), you can start reviewing the threshold for the Best Practice metrics. The Threshold Advisor performs a statistical analysis and produces a recommended threshold. The GUI is used to review, trend, accept, and define the threshold values for their Best Practice metrics values for the data elements that it has been told to collect. It then allows you to upload these threshold values to the mainframe to use as dynamic thresholds.

 

You can define Calendar Periods and Threshold Sets in Threshold Advisor. Threshold Advisor will perform a statistical analysis, produce recommended threshold values, and provide guidance on your calendar periods (this is the business week tuning option).

 

If you start with Threshold Advisor and use it to define Calendar Periods and Threshold Sets, then allow it to produce recommended Threshold Values and upload them to the mainframe, those Threshold Sets and calendar periods are displayed in MainView Infrastructure Dynamic Threshold views. You can use the Dynamic Threshold views to manage your Thresholds whether they were built manually or uploaded from Threshold Advisor.

 

 

13 .jpg

 

Overview Dynamic Thresholds:

 

Dynamic Thresholds provide the ability to dynamically change the value of a Threshold for a particular metric automatically.

Thresholds determine:

  1. Changes in color for data elements defined in views.
  2. When alarms are fired and the severity of the alarm.

 

Traditional thresholds:

  1. have been defined in view customization or when creating an alarm, but they can be difficult to find and update after they have been created.
  2. apply only to the view or alarm where they’re defined.
  3. are constant through the workday and the week, while your workloads change depending on time of day and day of week.
  4. a manual process.

 

The new Dynamic Thresholds improve the flexibility of thresholds by:

  1. allowing them to have different values on different days, and at different times of the day.
  2. being centrally managed, if a Dynamic Threshold is created for a data element such as CPUBsy%, the threshold values will be in effect for all views and alarms containing that data element (unless this is overridden at the view or alarm level).

 

14.jpg

 

This flexibility offers you a significant improvement in operational flexibility and ease of administration.

 

Components of Dynamic Thresholds

There are 3 steps to implementing Dynamic Thresholds and allowing them to change Threshold levels during the workday:

1. Set up a new Threshold Set using the MAKETHR command on a product view.

2. Set up a Calendar Period with time periods (hours of a day and days of a week) when you would like the Thresholds to be in effect. You have nearly unlimited flexibility in how many periods there are in a day. You will use the CALDEFS view.

3. Define a Threshold Selection, which tells MVI which Threshold Set is to be active in which Calendar Period, using the view THRSELS.

 

Here’s a simple example:

  1. Define 2 Calendar Periods, and call them AM and PM, where AM is defined as 08:00:00 to 12:00:00 and PM is defined as 12:00:00 to 18:00:00.
  2. Define two threshold sets, AMTHRESH and set CPUBsy% Critical threshold to 95, and PMTHRESH and set CPUBsy% Critical threshold to 90.
  3. Define a Threshold Selection and set Threshold Set AMTHRESH to be active during Calendar Period AM, and define Threshold Set PMTHRESH to be active during Calendar Period PM.

 

Now you have implemented a Dynamic Threshold for the data element CPUBsy% and it will be active in all views and alarms defined on this data element.

Please refer to the information for Dynamic Threshold in the MainView User Guide for use of these views.

 

System operation

All existing alarms will operate without change, so if you don’t create a Dynamic Threshold, nothing on your system will change. When you create your first Dynamic Threshold for a data element and it is enabled, all views containing that element by default will operate under the new Dynamic Threshold values, as well as alarms on that data element.

 

You can go into a view that has existing view level Thresholds for a data element that you have defined a Dynamic Threshold for, and override the Dynamic Threshold for that view only, so the view level Thresholds are honored. This may be desirable if Operations wants different Thresholds on a view than the system programmers want to see.

 

Installation

MainView Infrastructure 6.1 will be installed on the mainframe as it always has been, using the OZI installer and integrated customization tool. The customization tool will have a new phase called Infrastructure Setup that will install MainView Infrastructure 6.1 and RTCS.

New for the MVI 6.1 installation are:

  1. An additional component called UIM - our web server address space, to be installed.
  2. A requirement for a new product level RTCS registry file for each CAS with the DDNAME = CASPERM, that you will have to allocate, either in the OZI customization process or by the view CASPERM.
  3. A new OZI customization question for installing the UIM component, so you can specify which CAS you want to be the target for Threshold information to be uploaded to, if you use the new Threshold Advisor product. You only need to target one CAS per CASPLEX (group of connected CASs) for Threshold Advisor to communicate with, and that CAS will be able to deploy Dynamic Thresholds to all other CASs that Threshold Advisor has elements for.

You will also need to install on a Windows server, the MainView Threshold Advisor product, and the Capacity Database (CDB) web-services. The CDB is used in conjunction with MainView Threshold Advisor to store downloaded interval data, and to perform the necessary analytics to produce recommended threshold values.

 

Once Threshold Advisor is installed, you should decide which set of MainView Best Practice metrics you want to work with to calculate recommended thresholds. Threshold Advisor will require 3 weeks of data before it can complete a study and recommend Thresholds, so my advice is to start this activity as soon as possible.

 

You can also perform the following activities to get ready for Phase 2:

  • Set up your business week by defining Calendar Periods for which you would like to calculate different Threshold values. These Calendar Periods would normally define times where your workload is noticeably different than at other times of the day, so you would expect that different Threshold Values would allow better management, i.e. fewer false alarms.

 

MVI 6.1

Threshold Advisor – suggested customization phase 1
  1. Select a data element (metric) that you are interested in.
    1. One that changes significantly during the test period and one where it may vary across the entire range of Threshold Values (Info, Warn, Minor, Major, Critical). This would allow you to see the full range of results.
    2. CPUBsy% may be a good one.
  2. Define a set of Thresholds on the metric at the View Level and watch the metric change colors as it varies across the range of values. You may need to pick Threshold Levels much lower than in production to see all of the severity levels, such as CPU = 10, 20, 30, 40, and 50. You will need this View Level Threshold established to verify that the Dynamic Threshold has overridden the View Level Threshold.
    1. You could set all Threshold results to show the value as "green".
    2. In Dynamic Thresholds, you could set all Threshold results to show as "red" and prove that the Dynamic Threshold has overridden the View Level Threshold.

3. Define a set of Calendar Periods that you will use for testing.

  1. Initially the test Calendar Periods should be short (2 – 5 minutes) so you can verify that different Threshold values are in effect for different Calendar Periods. It should not be necessary to wait for hours to observe this transition.
  2. Later you may change the Calendar Periods to times that represent what you would actually like to use in your environment.

4. Define a Threshold Set on a data element (metric) you are interested in.

  1. Define a second Threshold Set with different Threshold Values that you can associate with a different Calendar Period. This will allow you to verify that you have Dynamic Thresholds in effect, and you have different Threshold Values in effect at different times of the day.

5. Define a Threshold Selection and assign each Threshold Set to a different Calendar Period.

6. Now you can verify several things:

  1. As you watch the transition of time from one Calendar Period to another, you should see different Threshold Values in effect if the Threshold Selection has been set up that way.
  2. If the View Level Thresholds were set to always show "green", and the Dynamic Threshold is in effect and set to always show "red", then the metric on the view should now be red. This would show that the Dynamic Threshold is in effect and overriding the View Level Thresholds.

7. Validate that other views that contain this metric are "red".

  1. This will show that Dynamic Thresholds are active in ALL views.

8. Go to one view with the metric and update the Threshold definition for the view so that it specifies that on this view, the View Threshold is to override the Dynamic Threshold.

  1. Result: all views should have the metric showing as "red" from the Dynamic Threshold definition, but this view should show the metric as "green".

9. Repeat this test scenario for Alarms.

 

Threshold Advisor – Phase 2

By now, you will have collected 3 weeks of sampled data from MainView, for the Best Practice metrics that you selected.

  1. At this point you will run the statistical analysis of the data you have collected.
  2. This will produce recommended Threshold Values for the metrics you selected, and they will be correct for the time periods you selected for your calendar periods. You will also receive reports and graphs showing the relationship of observations that were collected and the recommended Threshold Values. Use these to check that the Threshold Values produced made sense for your environment.
  3. When you are sure the recommended Thresholds make sense, you can PUSH them to the mainframe from your PC (Threshold Advisor).
  4. After the PUSH completes, go to the mainframe and from the MainView product, check to be sure the thresholds you PUSHed have arrived correctly.

 

With MainView Infrastructure 6.1 and the new components of Threshold Advisor and Dynamic Thresholds we believe you will generate more intelligent alarms and will allow you to move from managing your environment from observation to true exception management.

Share This:

You’re probably well-aware of MainView Explorer (MVE), the web browser interface that provides better graphic capabilities. It comes with your MainView and AutoOPERATOR product as part of the underlying MainView Infrastructure. Today we’ll discuss how to group different views and charts together using View Container. View Container is a special kind of view that can contain multiple query views and charts. You can have multiple view containers and they can be added to the stack of panes, or they can be detached (just like regular views). The views contained within a view container can be tiled, cascaded, or freeform. By default, they’re tiled, which is the easiest and most logical way to view them, because everything is automatically arranged and fully visible.

 

View Containers are saved in a configuration, along with all other views, whether they’re contained or not. If a configuration is exported to a local directory, View Containers will also be exported. This makes it possible for you to explicitly arrange multiple views (along with charts) within containers, set them all to refresh and publish data, save this as a mainframe configuration in BBCDEF, and also export this as a local configuration to a shared directory. Then subscribers (not needing a logon to the mainframe) can open an MVE Viewer with a parameter to this shared configuration file and see all the views automatically refreshing, arranged accurately in named view containers, on tabs or detached. It’s VERY (not an acronym) flexible! Finally, any 3270 saved Screen that is imported into MVE will now have its views placed in a View Container.

 

 

Creating Your View Containers

 

To create a View Container, use the File / Create View Container menu item or the  1 .jpgtoolbar icon on the main toolbar. This will ask you to give the View Container a name. Don’t worry, you can change this later change if you wish, using the Rename menu item which you’ll see when you right-click on the tab of the View Container.

To add views to a View Container, just right-click on any regular view’s tab and from the cascaded menu Move to Container, select the View Container where you wish to move it. You can also accomplish this with drag-and-drop. Simply click on the tab of the view you wish to move, drag it to the tab of a View Container, and drop it.

As you drag the view tab over the other tabs, you’ll notice the cursor change to one of four cursors: Move, Drop, NoEntry, or Insert (The Insert cursor indicates that you can move the tab to another position on the stack, which will be remembered in a configuration.). The cursor will change to a Drop cursor when it’s placed on a View Container tab. When you drop it, the container will immediately arrange itself, tiled or cascaded, with the dropped view placed last (though it can later be moved to a different position). If you have a detached View Container, you can drop the view anywhere within the detached View Container window. If a tabular view has a dependent chart, the view and chart will be moved as a pair. If you drop a tabular view without a chart in a View Container and then open a chart for it, the chart will take up a position within the View Container right after the view. Any view or alternate form opened from a view in a View Container will also open within that View Container. Make sense? You’ll see, it’s easier done than said.

In order to preserve as much space as possible for the visibility of the data, context information is moved from the status line to the internal frame title bar, and toolbars are automatically hidden for views and charts within the View Container. But right-clicking anywhere on the view will bring up a pop-up menu, which will show all the toolbar icons and functions (including a menu item to un-hide the toolbar). The command line also is hidden for query views, but if you’d like, it can be un-hidden using the pop-up menu. All the functionality of the view remains intact. Imported views can be distinguished from regular views by the presence of a leading asterisk.

2 .jpg

This is an example of a tiled View Container named "System" with three tabular views, each with a chart. Also showing is a pop-up menu after right-clicking within a view.

To remove any view from the View Container, just right-click within the contained view, select button 3 .jpgRe-attach this Fram, and it will be put back on the stack of panes. If the view has a dependent chart, the view and chart will be removed as a pair, whether you selected the view or its chart.

To move the position of the contained view up or down with the View Container, right-click inside the contained view, and select

4.png Move Up button or Move Down button. Again, if the view has a dependent chart, the view and chart will be moved up or down as a pair.

 

To remove all the view from the View Container, right-click on the View Container tab, select Re-attach all Frame (see example below), and they will all be put back on the stack of panes. This is also the default action that would take place if you were to simply close the View Container. If you would rather close all the views in the View Container, right-click on the View Container tab and select Close All Views before closing the View Container.

To refresh the data for all views within a View Container, right click on the View Container tab and select Refresh Data for All Views or press the

5.pngRefresh Data for All toolbar button.

 

 

To start or stop auto-refreshing with the same interval for all views within a View Container, right-click on the View Container tab and select Auto-Refresh (it's a toggle) or press the

  6.pngAuto-Refresh All toolbar button. To change the default auto-refresh interval (30 seconds), right-click on the View Container tab and select Set Auto-Refresh Interval.

To start or stop exporting data for all views within a View Container, right-click on the View Container tab and select Export All Views (another toggle) or press the

7.pngExport All Views toolbar button. This will not prompt you for files names, but will use default names, consisting of the viewname + underscore + context.

If any of the views within the container support interval history (or short-term history in the Viewer), the prev/Next arrow toolbar buttons 8.png will be enabled. When used, all views in the container that have a history will be updated with the previous or next interval. Pressing the center blue ball will reset all views to the current time.

Use the forward 9.pngand back

buttons on the toolbar to maximize the next/previous view within the container. Press the

11.png

 

 

 

When you save a configuration with View Containers, the explicit order of the views it contains is maintained, as well as the window arrangement style. And if the style is Freeform, the the relative bounds of the internal frames are saved as well. When a Freeform View Container is resized, the contained window will maintain their relative positions proportionally.

 

yellow button between the arrows to reset the container. You may also use the center button as a toggle to start cycling though the views, maximizing each on a regular interval (default: 15 seconds), which can be changed by right-clicking on the toolbar and selecting "Set Interval When Cycling".  When cycling, the button will be green, and when reset it will be red.

 

12 .jpg

This is an example of a View Container named "SystemF" with a Freeform window arrangement. It also shows the chart pop-up menu after right-clicking on one of the charts, which allows you to change the chart type.

 

Share This:
 

BMC offers two products that assist with the monitoring and operation of z/Enterprise machines. Each z/Enterprise machine has two Service Elements and one or more HMCs (Hardware Management Consoles).

 

1 .MainView AutoOPERATOR is an automation and management program operating within z/OS.

 

2. MainView Console Management is a LINUX based product that improves operator productivity and offers automation and management for z/Enterprise machines.

 

MainView AutoOPERATOR REXX EXECs can invoke the IMFEXEC HMC command to perform these tasks:

- Obtain the System z topology of the current interconnected Central Processor Complexes (CPCs) as well as the images, capacity records and activation profiles on a particular CPC.

- Query various CPC, image (LPAR), capacity record, and activation profile information.

- Set various configuration values related to CPC, image, and activation profiles.

- Issue commands against both the CPC and image (LPAR) to perform minor or even significant hardware- and software-related functions.

 

The IMFEXEC HMC capability may be interwoven with the existing automation to improve system throughput/reliability or reduce financial costs (eg. MSU based IBM charges).

 

MainView Console Management can improve operator and system programmer productivity (vs. the IBM HMC) by:

- Flexibly consolidating the displays from a user selected number of consoles onto one screen.

- Providing scroll-back of console messages, even to point before SYSLOG is operational, to the welcome screen before the IPL occurs.

- Organizing LPARs into user defined groups with tree navigation which helps to prevent IPLing the wrong LPAR.

- Granular security and auditing for operator actions, at a finer level than the IBM HMC.

- Secure remote operation, allowing operators to be at remote sites, or for them to operate multiple remote locations.

 

MainView Console Management also offers automation and monitoring capability:

- Rules that can monitor events and take specified actions.

- User scripts that can encapsulate complex sequence an actions, improving operator reliability.

- The event sources for Rules include HMC events, as well as generic SNMP traps such as those from FICON directors or other TCP/IP based devices.

MainView Console Management is supported on LINUX and may run on typical hardware or in a zLINUX VM guest machine.

 

Using IMFEXEC HMC in AutoOPERATOR REXX EXECs

 

Since this is a very powerful feature, in addition to the normal SAF controls, there is a special option which must be enabled in parameter member AAOEXPxx.

 

EXHMC=NO YES DEFAULT=NO

NO CONTROLS WHETHER IMFEXEC HMC IS AVAILABLE FOR

USE OR NOT

 

The IBM instructions on the RACF resources and permissions needed are in the MVS Callable Service manual in section 7 Base Control Program internal interface (BCPii). The BCPii communicates with the Service Element(s).

 

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2C171/CCONTENTS
 

It is recommended that read-only permissions be granted for your initial experiments ie. IMFEXEC HMC Cmd and IMFEXEC HMC Set are not allowed.

 

With these preliminaries out of the way, you may run your first IMFEXEC HMC sample to list your local machine resources.

 

/* REXX */

/* Example 1 HMC commands which do not require a Token */

ARG EXNAME P1 P2 .

"IMFEXEC HMC LIST(CPCS)"

"IMFEXEC MSG 'HMC LIST CPCS NUM="LINE.0 "CC="IMFCC "RC="IMFRC"'"

 

IF IMFCC = 0 THEN

DO I = 1 TO LINE.0

"IMFEXEC MSG 'LINE"I"="VALUE('LINE.'I)"'"

END I

"IMFEXEC HMC LIST(LOCALCPC)"

"IMFEXEC MSG 'HMC LIST LOCALCPC NUM="LINE.0 "CC="IMFCC "RC="IMFRC"'"

IF IMFCC = 0 THEN

DO I = 1 TO LINE.0

"IMFEXEC MSG 'LINE"I"="VALUE('LINE.'I)"'"

END I

"IMFEXEC HMC LIST(LOCALIMAGE)"

"IMFEXEC MSG 'HMC LIST LOCALIMAGE NUM="LINE.0 "CC="IMFCC "RC="IMFRC"'"

IF IMFCC = 0 THEN

DO I = 1 TO LINE.0

"IMFEXEC MSG 'LINE"I"="VALUE('LINE.'I)"'"

END I

"IMFEXEC MSG '."EXNAME "EID="IMFEID "ENDED'"

EXIT

 

The output below shows there are two machines IBM390PS.Alamo and IBM390PS.Goliad. The AutoOPERATOR is running on IBM390PS.Alamo (LocalCPC) in LPAR SJSC (LocalImage)

 

15:03:45 %HMC14

15:03:45 EM0026I EXEC HMC14 EID= 00001 STARTED ON 11-JUL-12 AT 15:03:45

15:03:46 EM1523I LIST CPCS

15:03:46 HMC LIST CPCS NUM=0002 CC=0000 RC=0000

15:03:46 LINE1=IBM390PS.ALAMO

15:03:46 LINE2=IBM390PS.GOLIAD

15:03:46 EM1523I LIST LOCALCPC

15:03:46 HMC LIST LOCALCPC NUM=0001 CC=0000 RC=0000

15:03:46 LINE1=IBM390PS.ALAMO

15:03:46 EM1523I LIST LOCALIMAGE

15:03:46 HMC LIST LOCALIMAGE NUM=0001 CC=0000 RC=0000

15:03:46 LINE1=SJSC

15:03:46 .HMC14 EID=00001 ENDED

15:03:46 EM0027I EXEC HMC14 EID= 00001 ENDED ON 11-JUL-12 AT 15:03:46

 

Querying and Altering the GroupProfileCapacity

 

This example EXEC demonstrates querying and altering the GroupProfileCapacity. It will flip-flop the GroupProfileCapacity between 899 and 900.

 

/* REXX */

/*

EXAMPLE:

%HMC27

flip GroupProfileCapacity between 899 and 900

need RACF Update permission to HWI.TARGET.ibm390ps.alamo.sjsd

*/

ARG EXNAME P1 P2 .

"IMFEXEC MSG '."EXNAME "EID="IMFEID "STARTED'"

TRACE N

CP1 = 'IBM390PS.ALAMO'

IM1 = 'SJSD'

"IMFEXEC HMC CONNECT( CPC("CP1") OUTTOKEN(CPC_TOKEN) )"

IF IMFCC /= 0 THEN EXIT

"IMFEXEC HMC CONNECT( IMAGE("im1") OUTTOKEN(IMG_TOKEN) )" ,

"TOKEN(CPC_TOKEN)"

IF IMFCC /= 0 THEN EXIT

call query10 'groupProfileCapacity'

if result = 900 then

capacity = 899

else

capacity = 900

call set10 'groupProfileCapacity' capacity

call query10 'groupProfileCapacity'

"IMFEXEC HMC DISC TOKEN(IMG_TOKEN)"

"IMFEXEC HMC DISC TOKEN(CPC_TOKEN)"

"IMFEXEC MSG 'HMC27 Set finished'"

exit

/* -------------------------------- */

query10:

arg p1

IF IMFCC /= 0 THEN EXIT

"IMFEXEC HMC CONNECT( IMAGE("im1") OUTTOKEN(IMG_TOKEN) )" ,

"TOKEN(CPC_TOKEN)"

IF IMFCC /= 0 THEN EXIT

call query10 'groupProfileCapacity'

if result = 900 then

capacity = 899

else

capacity = 900

call set10 'groupProfileCapacity' capacity

call query10 'groupProfileCapacity'

"IMFEXEC HMC DISC TOKEN(IMG_TOKEN)"

"IMFEXEC HMC DISC TOKEN(CPC_TOKEN)"

"IMFEXEC MSG 'HMC27 Set finished'"

exit

/* -------------------------------- */

query10:

arg p1

"IMFEXEC HMC QUERY("p1") TOKEN(IMG_TOKEN)"

HMC_CC = IMFCC

IF HMC_CC = 0 THEN

DO I = 1 TO LINE.0

"IMFEXEC MSG 'hmc27 query" p1 "LINE."I "="VALUE('LINE.'I)"$$'"

END I

else

"IMFEXEC MSG 'hmc27 query" p1 "imfcc="hmc_cc"'"

/* return the value - always on line.1 */

return value('line.1')

/* -------------------------------- */

set10:

arg p1 p2

"IMFEXEC HMC SET("p1","p2") TOKEN(IMG_TOKEN)"

HMC_CC = IMFCC

"IMFEXEC MSG 'hmc27 set" p1 p2 "imfcc="hmc_cc"'"

return

 

Changing the number of processors in a LPAR

 

This example EXEC changes the number of IFL processors from zero to one (or one to zero).

 

/* REXX */

/*

FOR TESTING IMFEXEC HMC

EXAMPLE:

%HMC26

set IFL count for the ImageActivation profile

*/

ARG EXNAME P1 P2 .

/*

"IMFEXEC MSG '."EXNAME "EID="IMFEID "STARTED'"

*/

TRACE N

CP1 = 'IBM390PS.GOLIAD'

IM1 = 'TEST2'

"IMFEXEC HMC CONNECT( CPC("CP1") OUTTOKEN(CPC_TOKEN) )"

IF IMFCC /= 0 THEN EXIT

 

"IMFEXEC HMC CONNECT( IMAGEACT("im1") OUTTOKEN(IMG_TOKEN) )" ,

"TOKEN(CPC_TOKEN)"

IF IMFCC /= 0 THEN EXIT

call query10 'numSharedIfl'

/*

if current number of processors = 0 then modify it to 1

if current number of processors = 1 then modify it to 0

*/

if result = 0 then

num_processors = 1

else

num_processors = 0

call set10 'numSharedIfl' num_processors

call query10 'numSharedIfl'

"IMFEXEC HMC DISC TOKEN(IMG_TOKEN)"

"IMFEXEC HMC DISC TOKEN(CPC_TOKEN)"

"IMFEXEC MSG 'HMC26 Set finished'"

exit

/* -------------------------------- */

query10:

arg p1

"IMFEXEC HMC QUERY("p1") TOKEN(IMG_TOKEN)"

HMC_CC = IMFCC

IF HMC_CC = 0 THEN

DO I = 1 TO LINE.0

"IMFEXEC MSG 'hmc26 query" p1 "LINE."I "="VALUE('LINE.'I)"$$'"

END I

else

"IMFEXEC MSG 'hmc26 query" p1 "imfcc="hmc_cc"'"

/* return the number of processors - always on line.1 */

return value('line.1')

/* -------------------------------- */

set10:

arg p1 p2

"IMFEXEC HMC SET("p1","p2") TOKEN(IMG_TOKEN)"

HMC_CC = IMFCC

"IMFEXEC MSG 'hmc26 set" p1 p2 "imfcc="hmc_cc"'"

Return

Share This:

Would you like to learn in just ten minutes how to mine for data to get the information from all tasks in all CICS regions from MainView for CICS? In this ten minute video, we’ll guide you through the process for using MainView for CICS to view task history, including summary intervals, Fast-Path commands, TIME command, web browser and 3270 interfaces.

 

Link:

http://www.bmc.com/support/support-videos/msmdemo-mv-cics-task-history.html - (BMC Support ID Required)

Share This:

Typically DFHSM has be setup to migrate old datasets that have not been referenced. This is a good thing, especially if the datasets are large and you want to re-use storage.

 

But what happens if the datasets are small? Wouldn’t you like to eliminate the overhead of migrating these smaller datasets? With MainView SRM Reporting you can detect unnecessary DFHSM migrations that squander your time and resources. Then you’ll be able to reduce DFHSM activity by tuning MainView to migrate large datasets only

 

Link:

http://www.bmc.com/support/support-videos/msmdemo-mv-srm-filter-dfhsm.html - (BMC Support ID Required)

Share This:

*Quick Course: Generate meaningful and comprehensive alerts
Prevent business outages with MainView AutoOPERATOR's rules processor by automating system events, alerts, and time-driven actions. (BMC Support login required.)
Watch the video ►

Share This:

*Quick Course: Automatically trigger alerts for quicker problem solving
See how you can use MainView Alarm Manager to automatically pass on alerts, open incident tickets, and notify staff when action is needed. (BMC Support login required.)
Watch the video ►

Share This:

 

And remember, with any mature proactive monitoring solution there’s the ability to automate remediation. AutoOPERATOR is an integrated solution, which utilizes MainView Explorer and the enhanced 3270 interfaces, to monitor automation processes as well as enable documentation standards to simplify the transition of re sponsibilities to less experienced technicians. AutoOPERA TOR shares the MainView Infrastructure and can run in the same address space to help reduce the complexity of maintaining and deploying your proactive environments. By utilizing AutoOPERATOR views like ARRULES and AREVENTS you can understand what automation is running and which events are being handled.

 

While competitive monitors have announced new features, they still lack some of the basic functionality required in today’s System z environments. What distinguishes BMC MainView most from a functional perspective is the common MainView infrastructure.

MainView is designed to be code efficient, and where possible, to enable our code to be eligible to be dispatched to zIIP engines. An example of efficiency - CMF MONITOR shares 100% of MainView for z/OS data collectors. MainView for z/Os shares 95% of its data collectors with CMF MONITOR, which significantly reduces the cost of monitor z/OS, compared with RMF and other z/OS monitors. This is an example of MainView’s efficiency that no competitor can match. If you do have a zIIP engine, then the reported range of it GP resources than can be offloaded to zIIP for the CMF MONITOR - MainView for z/OS address space is 35-70%. And, while competitors have announced zIIP offloads, their offload percentages are nowhere near MainView’s.

The MainView infrastructure is engineered to help manage many entities as one. This helps simplify access to performance data, operational information, and to quickly discover and manage exceptions. We call this Single System Image (SSI). With SSI, you can see all MainView infrastructure sysplexes, systems, and subsystems in one 3270 display or through the MainView common web browser interface (MainView Explorer). SSI is also customizable, so you can group several systems, subsystems, CICSplexes and Sysplexes together, based on your requirements. You can quickly identify who in a Parallel Sysplex is holding a lock in the data sharing environment, or you can look at all CICS transaction arrival rates across your CICS regions, spanning multiple sysplexes. The choice is yours.

While a competitor has just announced an enhanced 3270, since 1993 MainView’s infrastructure has the capability to customize its "Windows" displays on the 3270. You can have multiple windows viewing multiple systems or subsystems data, in real-time, interval-based, or historical time frames. You can use the out-of-the-box hyperlinks to point and shoot to more detailed data, or even customize where you want to go by simply changing the hyperlinks.

With MainView Explorer – a web browser graphical user interface, there is no need for any software to be pre-configured on your PC, other than the Java Runtime (JRE). Nor are there requirements for any distributed system servers. You simply address a URL to your host mainframe, and assuming that you have valid logon credentials, you’re set. You can even set up MainView Explorer to provide easy access to views and charts of mainframe data to interested parties without requiring a logon to the mainframe.

 

The common MainView infrastructure also provides MainView Alarm Manager to provide proactive monitoring of your environment. Alarm Manager can be used with all MainView monitoring products as well as with CMF MONITOR and AutoOPERATOR in Windows mode. It is easy to setup via its wizard-type interface that allows you to fill in the blanks. You can maintain your alarms on one z/OS image and deploy to many. Alarm Manager also has "Persistence Checking" measuring, not just when utilization hits a threshold, but also – more importantly – of the time spent at the threshold. This allows you to conclude whether what you’re seeing is a blip or a trend. If an alarm is generated, it is an intelligent alert – that is it will be processed by automation as an alert. But if you select the message, you will automatically hyperlink to the area of your system that generated the alarm. This will great reduce your mean time in isolating the cause and performing any corrective actions.

 

Mainview.jpg

MainView Explorer showing AutoOPERATOR Rules and Events.

AutoOPERATOR is also tightly integrated with BMC event and impact management as part of our overall Business Service Management strategy.

Thank you for running MainView and I hope this information reminds you of the excellent choice you made.

 

Share This:

  *Quick Course: Easily identify problems and take action

Check out BMC MainView Explorer – the GUI interface that helps you monitor what you want to monitor and take steps to correct problems. MainView Explorer is part of MainView Infrastructure and can be used with MainView and with AutoOPERATOR. (BMC Support login required.) Watch the video ►

Filter Blog

By date:
By tag: