NatQuery is comprised of three primary components:

To communicate with the remote Natural Server Environment, NatQuery utilizes architecture based on automated FTP (for OS/390, VSE or UNIX platforms) or automated File Copy operations (for Windows Server platforms).  Further information on how NatQuery can be automatically integrated to a remote server can be found on the NatQuery Connectivity Architecture page.

The general architecture of the three primary NatQuery components is graphically depicted below.

Administrative Component
The Administrative Component is designed for use by a designated administrator, and it serves to capture basic categories of information about any given application’s file structure; information that is essential for intelligent extraction program generation.

The Administration process begins by customizing templates that will allow for “batch” interaction against the remote Natural Server Environment.  For OS/390 or VSE platforms, this batch interaction will be accomplished through the use of JCL templates, for UNIX or Windows, batch interaction takes place through Script templates.  Through these JCL / Script templates, NatQuery will gain the ability to both use and make requests against the remote Natural environment.

With JCL / Script templates configured, NatQuery is then given Data Definition Modules (DDMs) that contain the basic field information for each of the files that will be opened to extraction or PLOG Processing, with NatQuery being able to either automatically download needed DDMs through batch requests, or through the ability to import DDMs.  Once DDMs are imported into NatQuery, an Administrator then utilizes specific administrative functions of NatQuery to define further required information that is based on these DDMs.  Specific functions allow for the definition of: :

With the above information provide once, NatQuery is given "application intelligence" - an intelligence that can be equated to that of a skilled Natural programmer who understands the complexity of a given database application file structure.  This intelligence then allows for the generation of optimized single and multi-file data extract programs on demand, in a manner that completely shields the user from the complexities of Natural, ADABAS data structures, JCL / Script or nuances of the Natural / ADABAS platform.

How the Administrative Component interacts with the other two components can be seen in the following graphic:

[Back To Top]



End-user Component
With Administration functions completed, the problem of resolving a given user's extraction requirements is reduced to its most basic elements:

The end-user component supplies the graphical means of capturing the above information, and with this information a Query Specification is created. Query Specifications can be handled in typical Windows fashion, with the standard functions of Open, Save, Save As, Delete, etc.

Once a Query Specification is created, the user simply requests that the Query be Sent to the Server, at which time the user will indicate where the output is desired.  Currently, the following targets and processing are supported:

[Back To Top]



Generation Component
The Generation Component is where the “magic” happens, as it is the Generation component that converts a User’s Query Specification into a ready-to-execute extraction process.

From a Query Specification, the Generation Component applies built-in Natural programming intelligence to information obtained through the Administration Component to generate complete, ready-to-execute data extraction requests from ADABAS.  The generation capabilities include:

Whenever a Natural program is generated, the Natural program is generated as Natural 2 structured code that is “Performance Sensitive”.  “Performance Sensitive” means that the NatQuery generation engine has the intelligence to:

With an extraction process generated, NatQuery can then automatically submit the generated process directly to the remote Natural / ADABAS server platform where it can be automatically executed - with the requesting user then being able to remotely monitor, and then automatically download data requests.

To learn more about how NatQuery integrates to a remote Natural / ADABAS server platform, please refer to the NatQuery Connectivity Architecture page.


[Back To Top]
[Back to the NatQuery Information Page]

NatQuery General Architecture


United We Stand