| |
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.
|
|
|
