NOMAD One Pass

NOMAD is a mainframe product that provides the most powerful reporting capabilities available today. NOMAD's reporting command, LIST, is continually fine tuned and optimized so it provides not only powerful reporting capabilities, but highly efficient operation as well.

With the use of NOMAD One Pass, a performance optimizer, NOMAD delivers reporting power with even greater efficiency. One Pass processes several LIST requests at once with a single pass through a database. As a result, it addresses the constant data processing need for minimizing mainframe resource usage. One Pass is ideal for sites where the costs associated with data access are an important consideration due to either the complexity or volume of data, and where many reports are run frequently from the same set of data.

NOMAD One Pass is a proven tool for reducing execution time, CPU and I/O. In documented testing, NOMAD One Pass reports achieved as much as an 80% reduction in execution time and 86% in CPU and I/O usage.

In addition, product documentation offers guidelines for identifying the LIST requests that will benefit most by their processing with One Pass.

NOMAD One Pass can be used with any data accessible by NOMAD, including QSAM, ISAM, VSAM, IMS, IDMS and the SQL engines DB2, SQL/DS and Teradata.

What NOMAD One Pass Does

One Pass accesses data once while delivering multiple reports, thus saving much of the processing time and resources associated with reporting.

To use One Pass to its best advantage, it helps to understand the process of a NOMAD LIST request and how the data is stored. There are three steps in processing a LIST request: SET UP, ACCESS and REPORT.

  SET UP
In the Set Up phase, LIST command components are analyzed to decide which parts of the database should be read.
  ACCESS
During the Access phase, the databases are read, based on the information saved during the Set Up phase. Data selection options, such as SELECT, WHERE and IF parameters, are evaluated to minimize the number of records read and DEFINEd items are also evaluated. For each instance of data that passes the selection criteria, records are saved in one or more sort files.
  REPORT
In the Report phase, records from sort files are read and merged, and data is formatted and written to the printer or report file.

One Pass Processing

To use NOMAD One Pass, multiple LIST requests are grouped in a One Pass "package," which begins with a ONEPASS SAVE command and ends with a ONEPASS REPORT command.

When NOMAD encounters a ONEPASS SAVE command it goes through a Set Up phase similar to that for a single LIST request, analyzing each request in the package and storing pertinent information for each one.

The ONEPASS REPORT command triggers the Access phase, which is where most One Pass processing occurs. NOMAD searches the database, instance by instance, releasing instances to the appropriate sort files for each report as it goes. If there are SELECT commands in effect, NOMAD tests to see to which sort files, if any, a record should be released. A record may be used for multiple reports, or none at all.

After NOMAD processes the entire database and creates the sort files for all the reports, the Report phase begins, using the information saved during the Set Up phase to format the reports.

LIST also provides a BANNER option to add a banner page between reports. This makes it easy to identify the various reports in the One Pass package output.

Saving Resources

NOMAD One Pass produces resource savings in three primary areas: DASD I/O, Shared DEFINEs and message traffic.


One Pass significantly reduces DASD I/O for LIST requests, because it navigates the database only once, regardless of the number of LIST requests in the One Pass package.



One Pass evaluates shared DEFINEs, the same DEFINE used in more than one LIST within the package, only once per instance, regardless of how many reports use them. If the same DEFINEs are used in many reports, this can offer significant resource savings in CPU and execution time.



One Pass also greatly reduces the message traffic when accessing foreign, non-SQL database engines, such as IMS and IDMS, or VSAM and QSAM file structures.
Analyzing Results with NOMAD One Pass

NOMAD provides dynamic measurement tools for analyzing report performance. These measurement tools, OPTION LISTSTATS and NAPA (NOMAD Application Performance Analyzer), can be used to demonstrate how a set of LIST requests executed singly compares to One Pass in resource usage.

OPTION LISTSTATS

OPTION LISTSTATS is a powerful analysis tool that is part of mainframe NOMAD. OPTION LISTSTATS will show all the sort files created for a single LIST or for a One Pass package, and the number of records in each sort file. Other information provided includes the CPU time for the different phases of LIST and the CPU time for data retrieval _an important statistic to note for system performance.

Analyzing LISTSTATS provides a solid measure of the savings achieved by including a LIST request in a One Pass package.

NAPA

The NOMAD Application Performance Analyzer (NAPA) is an optional NOMAD product that is a powerful tool for measuring all relevant resources, especially CPU usage, I/O counts, number of instances read and elapsed time.

Testing NOMAD One Pass

To demonstrate performance improvements using One Pass, a series of LIST requests were developed for the following examples. Reports from a database with a single master and an accompanying lookup table were requested. The database has 40,000 instances of data with five instances in the lookup table master. SELECT options were not used for the analyzed reports.
  Package 1
The first One Pass package contained eight LIST requests, where all instances were listed for different BY-items.

The major improvement is in I/O, where I/Os are 43.6% of those for a single LIST. The One Pass case runs in seven CPU seconds less than single LIST. Compression of data is not performed. The number of instances are as expected. There are 40,000 instances of data (plus five lookup instances), no SELECTs in place and eight LIST requests being run. Therefore, the total instances for single LIST was eight times the total for One Pass, or 320,000 (plus the five instances for the lookup table). Clock time was the same.

Package 2
The next set of LIST requests included a summation for the same BY-item.

With this package, not only is I/O saved, but significant elapsed time as well. Package 2 performs data compression with the SUM function, so additional performance gains are expected with One Pass. CPU difference is still seven seconds less for One Pass, but this represents a higher percentage of the total CPU time to run the reports. One Pass I/Os have dropped to approximately 13.5% of those for single LIST. The instances counts compare as before, while clock time shows the One Pass case to be one-fourth the time necessary to run the same reports with a single LIST.

Package 3
The last set of requests also performed summations and included calculations on a series of DEFINEd items that were slices of a time-series array.

This shows the most impressive gains. The I/Os and instances show little or no change from the prior test. Yet total CPU and clock time show dramatic improvement with One Pass. Because One Pass performed the calculations on the DEFINEs only once for all reports, it uses seven minutes and 13 seconds less total CPU time than single LIST, and runs in approximately one-fifth the time.

NOMAD One Pass and the SQL Engines

One Pass can also be used to improve efficiency when reporting against data stored in mainframe SQL database systems to which NOMAD interfaces: DB2, SQL/DS, and Teradata. In these cases there are some additional considerations when doing the preliminary analysis.

During single LIST processing, the NOMAD SQL Interface minimizes cost by maximizing the tasks of selection, aggregation, projection and sorting done by the SQL engine. One Pass, on the other hand, is designed to access a table only once for multiple reports. Therefore, when accessing data stored in SQL tables, it generates a single SQL SELECT for all data in a table, rather than an individual SQL SELECT for each sort file in the package. No projection is done, and all columns in the target table are returned to NOMAD. The rows returned, however, can be restricted by using the SELECT NAMED ONEPASS command to limit the data access to a subset of the data. SELECT NAMED ONEPASS generates an SQL WHERE clause on the SQL SELECT passed over for processing, and is an important command for using One Pass with SQL data effectively.

Table 2 contains the results for running the same set of One Pass packages against data stored in DB2 tables. The structure of the database was identical to the one used in the NOMAD test, while the number of rows was 20,000, or one-half the number stored in the previous test.

The results show that when data is retrieved from SQL systems, One Pass provides performance gains. Here, as in the first set of tests, Package 3 has the greatest savings. This package contained the SUM function used on DEFINEd items that appear in multiple LIST requests in the package. The results show that when this is the case, the savings are significant, whether the data is stored in SQL tables or in NOMAD. These test results confirm that NOMAD One Pass significantly improves efficiency across NOMAD's entire range of file structures.
Learn More
To find out more about how Select Business Solutions can help you either Contact Us, or visit our Product Resources area for all the latest related downloads.
Datasheets

NOMAD (1.2mb)

NOMAD Reporting

NOMAD Interface for DB2

NOMAD Interface for VSAM
Useful Links
IBM DB2
IBM Mainframe servers
IT Toolbox - Database Knowledge Base
Teradata