The Makers of FDR®

FDRViEWS Technical Detail

FDRViEWS can be installed and operational within a very short period of time and is comprised of 4 separate components:
  • The Data Pump – a z/OS started task, which is created as part of the z/OS installation process. The Data Pump collects information about the z/OS storage environment, at both the volume and data set level.

  • The Collector – a Windows service or application that maintains a schedule of when and where the collections are taken.

  • The Datastore – an SQL database where the collections are stored

  • The Viewer – the main FDRViEWS GUI interface where users pose their questions and get their answers.
1. The Viewer (GUI Interface)

The Viewer is the most visible part of FDRViEWS from the user’s perspective, and it’s through the Viewer that the user can pose an almost limitless number of questions. Formulating a question is a simple 3-step process:
  • In the “Collections” pane, choose the collection(s) that you wish to report on. This is the raw data collected by the z/OS Data Pump.

  • In the “Groupings” pane, choose the default or user-defined grouping on which you wish to report. A grouping can generally be thought of as the “input” to a question, or an identifiable subset of the raw data. Default groupings include Users, Storage Groups, DASD Volumes, UCBs, Device-Types etc.

  • In the “Questions” pane, you choose the question you wish to have answered. Over 80 questions are supplied and they contain values or operators that you can change if required, e.g. change 40 percent to 80 percent, or change the greater than (>) to less than (<).

The Viewer (GUI Interface)

Once you have selected the collection(s) you wish to work with, you’ve chosen the grouping that you wish to report on, and you’ve selected the question you wish to simply hit the “Answer Question” button to have your question answered.

Answer Question

Since the data has already been collected in the SQL Datastore (described below) the “answer” to your question will only take a few seconds to run. It will come in the format of a multi-sheet Excel spreadsheet, which contains a number of fixed sheets or sections, such as “Pie Chart”, “Usage Bar”, “Calculation View” and “Data View”.

Some of these sheets are for visual reporting and others show the formulas and the actual data that was used for answering your question. The content of the sheets is determined by the type of question being asked.

Once you are viewing your answer in Excel, you have at your disposal all of the standard Excel features, which allow you to view, manipulate, save and even export the data as required.

2. The Data Pump (z/OS)

The FDRViEWS Data Pump runs as a started task on each z/OS LPAR on which you wish to analyze and report with FDRViEWS. The Data Pump collects information about the storage environment, at both the volume and data set level.

The length of time required to take a collection varies on the amount of z/OS storage being analyzed, but most collections typically take only a few minutes. The speed and low overhead of these collections means that they can be taken whenever and as frequently as your reporting needs dictate. The actual time and frequency of the collections is controlled by another component of FDRViEWS – the Collector.

3. The Collector (Windows)

Each z/OS Data Pump “self configures” itself to the FDRViEWS Collector, which runs on a Windows PC either as a service or an application. The FDRViEWS Collector maintains a schedule of when and where the collections are to be taken. In the following example, a collection has been scheduled to take place across all registered LPARs at 06:40 on a Saturday.

The Collector (Windows)

4. The Datastore

The collections that are transmitted from the z/OS Data Pump(s) to the Collector are then stored in fourth and final component of FDRViEWS – a standard SQL database called The Datastore.

The collections stored in the datastore can be viewed though a “Snapshots Collected” window:

Snapshots Collected window

The datastore retains the collections based on a user-supplied retention policy, which can be set either as the number of days a collection is to be kept, or the overall number of collections to be kept.

return to top