With the NOMAD Interface for DB2 for z/OS you can take full advantage of all the power in DB2 by supplementing its basic query and updating facilities with NOMAD's comprehensive fourth-generation language and relational database management capabilities.

First introduced in 1986, NOMAD's interface to DB2 has been cited by industry experts as providing the tightest coupling of a fourth-generation language productivity tool with the DB2 engine. As a result, the NOMAD Interface for DB2 offers the functionality, power and efficiency to meet the complete range of reporting and application development needs, including production-level application requirements.

Application developers quickly benefit from NOMAD's complete non-procedural language for fast prototyping, its built-in decision-support functions and its fully integrated programming language with functionality comparable to PL/I and COBOL. In addition, the product offers an array of tools and templates for quickly generating report requests, forms, menus and maintenance procedures.

The NOMAD Interface for DB2 provides you with the ability to use both dynamic and static SQL access to DB2 data. This makes it equally well suited for highly generalized, ad hoc applications, as well as production applications where performance and program authorization are key requirements.

The NOMAD Interface for DB2 enables users to access DB2 data from both TSO and MVS batch. Additionally, when used with the NOMAD Session Manager, non-TSO access is available from CICS and VTAM.

Integration with the DB2 Engine

When used to access DB2 dynamically, the interface translates NOMAD commands into SQL requests, passing off as much work as possible to DB2. Sorting and aggregation triggered by NOMAD's LIST command for reporting are performed by DB2, with only the columns needed to fulfill the data request shipped back to NOMAD.

Selective data listing can be handled efficiently through SELECT and LIST WHERE commands. Global data maintenance is handled by passing set calls for CHANGE and DELETE as a single transaction. Access rights are granted directly through DB2. Additional security can be provided with NOMAD passwords, database profiles, retrieval and update procedures.

Concurrent access by multiple users and data sharing are handled by DB2. DB2 tables can be created by NOMAD's data definition language using a single command, SCHEMA NEW. Conversely, SCHEMGEN provides an automated facility for describing DB2 tables to NOMAD. SCHEMGEN can also be used to describe DB2 system catalog information to NOMAD. The database administrator (DBA) can then easily report from catalog information, which helps to provide better control over data resources.

Relational Enhancements

NOMAD interfaces efficiently with DB2 because NOMAD itself is designed on a relational model. In addition, NOMAD provides important relational features not found in DB2:

Complete Outer Join Support

NOMAD's MERGE MATCHING for outer joins and EXTRACT ALL MATCHING for left-hand outer joins provide this support. There is no limit on the number of tables that can be joined using NOMAD.

Extended Data Type Support

NOMAD has additional data types for fixed and varying arrays, time-series and text data.

Enhanced Referential Integrity

Complete support for referential integrity was available in NOMAD more than two years before it was provided by DB2. NOMAD continues to offer additional features in this area that are still not provided in DB2, including:

Static SQL Access to DB2

For the variable inquiries often associated with ad hoc reporting and analysis, the names of tables, columns and views to be accessed are often unknown until the request is made. NOMAD's use of dynamic SQL allows the user to specify the objects at the time of request. The entire NOMAD language is available to the user, who may not even know the data is stored in DB2 tables. These characteristics are also ideal for the application developer, where this flexibility is especially desirable.

For applications where the referenced DB2 objects are known and can be fully described during the application development phase, as is frequently the case with production systems, static SQL access provides the needed control and efficiency. Here, static SQL queries passed to DB2 can be generated, precompiled and bound into a DB2 application plan in advance. At run time it is only necessary for NOMAD to execute the pre-bound SQL query. This also provides tighter control over the data, as the application user only needs authorization to execute the application plans generated by NOMAD.

To facilitate the design of applications with static SQL, NOMAD provides an automated Plan Generator.

The Plan Generator is a windowed pick-and-choose environment for selecting the DB2 objects for which static access is desired, and the operations to go against the data. The tool generates a NOMAD description of the objects, as well as the Assembler source code with embedded SQL. The Plan Generator also produces the JCL for the program preparation (precompile, assemble, link-edit) and for binding the application plan.

DRDA Support

The NOMAd Interface for DB2 supports IBM's Distributed Relational Database ARchitecture (DRDA), allowing transparent access to data across multiple DRDA-compliant DB2 subsystems. DRDA allows access to remote tables as if they were local. SQL becomes the standard language that provides compatibility across environments.