Introduction to Entire Net-Work

Entire Net-Work for BS2000, z/OS, and z/VSE provides transparent connectivity between client and server programs running on different physical or virtual machines, with potentially different operating systems and hardware architectures. The currently supported set of server programs includes Adabas, Entire System Server, EntireX Communicator, and any other software program that participates in cross-address communications defined by Software AG. A range of client programs are supported, including those written in Natural, the commonly used 4GL provided by Software AG, web-based applications such as Software AG's Jadabas and Tamino, and currently existing Adabas applications.

At its lowest level, Entire Net-Work accepts messages destined for targets or servers on remote systems and delivers them to the appropriate destination. Replies to these requests are then returned to the originating client application, without any change to the application. Entire Net-Work establishes these connections either through its line drivers or, on z/OS systems if the database is UES-enabled, through Entire Net-Work.

The method of operation and the location and operating characteristics of the servers are fully transparent to the user and the client applications. The servers and applications can be located on any node within the system where Entire Net-Work is installed and communicating. The user's view of the network targets and servers is the same as if they were located on the user's local node. Note that due to possible teleprocessing delays, timing of some transactions may vary.

This section covers the following topics:


How Entire Net-Work Operates

Entire Net-Work provides transparent support for remote and distributed server processing by supporting the existing Adabas database interface. A user call to Adabas invokes the environment-specific Adabas Link Routine (ADALNK). This routine issues an interregion call to Adabas through the Adabas router (in z/OS and z/VSE, the router is the Adabas SVC). The router, in turn, locates the Adabas nucleus operating in a separate address space or partition, and adds the user call to the Command Queue (CQ). The Adabas nucleus then selects commands from the Command Queue and performs its normal processing.

Because there is no inter-system database communication, this configuration cannot support a user on one system and a database located on one or more other systems. The router was not designed to pass a request across the network to a remote database nucleus or other service on another system.

This section explains how Entire Net-Work solves this problem by simply extending the existing client/server interface:

Entire Net-Work Establishes the Connections

Entire Net-Work establishes its connections using two possible mechanisms:

  • An Entire Net-Work line driver can be installed on each machine. Line drivers establish a connection with each other through the appropriate access method services. This configuration supports two-way transfer of requests and replies between these two systems, as well as topology and server broadcasting. The line drivers available for Entire Net-Work are: CTCA, DCAM, FCTC, IUCV, SSL, TCP/IP, TCPX, VTAM, and XCF.

    Note:
    For more information about Encryption for Entire Net-Work (including the SSL line driver), contact your Software AG sales support representative. The documentation for Encryption for Entire Net-Work is delivered separately from the other Entire Net-Work documentation.

  • Adabas UES-enabled databases can be connected through Entire Net-Work. For more information, read Connecting to UES-Enabled Databases through Entire Net-Work.

  • Adabas UES-enabled databases can be connected through ADATCP -- a direct TCP/IP link to the Adabas nucleus from web-based applications such as Software AG's Jadabas. For more information, read Connecting to UES-Enabled Adabas Databases and Connecting to a UES-Enabled Database through ADATCP .

Nodes Exchange Information

A node is defined by the Entire Net-Work NODE statement. There is one node per router and at least one router per machine. Each node in a network contains one copy of Entire Net-Work, which monitors any active servers (or targets) on that router and exchanges information with other Entire Net-Work nodes located on the same or on other machines. The Entire Net-Work nodes exchange information about targets accessible to them by means of broadcast messages. This information is maintained in tables by each Entire Net-Work node. Entire Net-Work also identifies itself to the system so that it receives all client requests for locally unavailable servers. Thus it can transport requests to remove servers or determine that a given server is currently not active anywhere. Client programs use server identifiers to direct their requests and are totally insensitive to the actual location of the servers.

The User Issues an Adabas Call

To begin the process, the user issues an Adabas (or any other supported) call. The call is presented to the local router by the Adabas Link Routine, which finds that the requested service is not available locally. Instead of returning Response Code 148 to indicate "service not available", the router passes the call to the locally executing Entire Net-Work communicator.

Entire Net-Work Handles the Call

After accepting the call, Entire Net-Work determines whether the requested service is available on the network. If it is not available, the local Entire Net-Work communicator returns Response Code 148 to the user to indicate "service not available".

If the target is active somewhere on the network, the call (including all required buffers) is packaged as a message and sent across the network to the target node by the line drivers. If necessary and the network topology allows, the message may be routed through many intermediate systems before it reaches its final destination.

Receiving Communicator Accepts the Message

On the target node, the receiving communicator accepts the message and presents the contained call to the locally running service through the router. The actual server regards the Entire Net-Work call as equal to any other call issued from within its own local environment and returns any required reply in the normal manner through the local router.

Reply is Passed to the Requestor

The router passes the reply information to the requestor, which is the local Entire Net-Work communicator, in the same way it passes reply information to a local request. The reply information is then packaged for the return trip to the originating node's communicator, which uses its local router to pass the reply to the user's request back to the client application.

Entire Net-Work Components

Entire Net-Work is installed on each participating host or workstation system requiring client/server capability. The configuration for a given system includes the following components:

  • an Entire Net-Work control module;

  • control module service routines;

  • any required line driver; and

  • ADATCP -- a direct TCP/IP link to Adabas UES-enabled databases from web-based applications such as Software AG's Jadabas.

Each system with Entire Net-Work installed and running becomes a node in the network. Each node has one or more line drivers that define the node's identity on the machine or host where data can be received. Each line driver has one or more links that contain the driver identifier for sending data to other Entire Net-Work nodes on the same or other machines.

Entire Net-Work Each Entire Net-Work node maintains a request queue for incoming requests. This queue is similar to the command queue used by Adabas; it allows the node to receive Adabas calls from locally executing user/client programs, which Entire Net-Work then dequeues and transports to the nodes where the requested services reside.

Each local Entire Net-Work node also keeps track of all active network services, and therefore can determine whether the user's request can be satisfied or must be rejected. If the request can be serviced, the message is transmitted; otherwise, Entire Net-Work advises the calling user immediately with Response Code 148, just as the Adabas router would do for a local database request.

Actual network data traffic is controlled by Entire Net-Work line drivers, which are interfaces to the supported communications access methods, such as VTAM, IUCV, DCAM, XCF, SSL, TCP/IP, and TCPX, or directly to hardware devices, such as channel-to-channel adapters (CTCAs or FCTCs). Each Entire Net-Work node contains only those line drivers required by the access methods active at that node. In addition, each line driver supports multiple connections to other nodes; this modular line driver design permits easy addition of new access method support to the system.

Summary of Entire Net-Work Features

The following is an overview of Entire Net-Work features:

  • Distributed transaction processing
    With Software AG's Adabas Transaction Manager, a server for coordinating "two-phase commit processing" in distributed Adabas environments, users query and modify resources under the control of one or more database management systems (DBMSs) operating in one or more system images distributed physically across multiple Entire Net-Work nodes.

  • Operating system-independent architecture
    Like Adabas, Entire Net-Work consists of many operating system-independent routines, allowing faster and easier adaptation to new operating system versions.

  • Adabas compatibility
    Entire Net-Work uses Adabas-dependent service routines for the operating system interface as well as for interregion communication, thus avoiding incompatibility.

  • Adabas-like "look and feel"
    The similarity between Entire Net-Work and Adabas means that the job control statements for running Entire Net-Work are much like those needed to run Adabas. For example, the EXEC statement invokes the ADARUN program for Entire Net-Work just as it does for Adabas, and the ADARUN parameters for Entire Net-Work are a subset of Adabas parameters.

  • Multiple communication access methods supported
    Access method support is implemented in the form of line drivers. If multiple access methods are needed on a node, supporting line drivers can be added without major reconfiguration of the node itself. Adding a new access method generally requires adding only the line driver module to the library and including the required configuration statements. With this implementation, a client request could be received from a VTAM partner and sent across to another machine using a channel-to-channel or TCP/IP connection for server processing.

  • Access for UES-enabled mainframe databases
    Adabas UES-enabled databases can be connected through Entire Net-Work. For more information, read Connecting to UES-Enabled Databases through Entire Net-Work.

  • Automatic target status updating
    All targets and services establishing or terminating communication with the network cause status information to be broadcast to all nodes, eliminating the need to maintain or refer to database or target parameter files at a central location.

  • Unique target ID enforcement
    Entire Net-Work enforces the Adabas requirement that each enterprise-wide target be assigned a unique target ID. (With Adabas, local targets that are introduced may have non-unique IDs.)

  • Remote processing of client/server request
    A request can be made from within a Software AG or third party application client program to a server (typically Adabas) located on a remote system, as if the server were running locally with no client changes.

  • One Entire Net-Work per node
    Allowing only one Entire Net-Work task on each node enforces control over the network topology by maintaining all required information in one place. This avoids confusion in network operation and maintenance. If, however, more than one Entire Net-Work task is required, this can be accomplished by installing additional routers.

  • Single request queue for all remote targets
    Each Entire Net-Work node maintains only one request queue and one attached buffer pool for economical use of buffer storage.

  • Transmission of relevant buffers only
    Entire Net-Work eliminates from transmission all buffers that are not required for the particular command. In addition, only those portions of the Record Buffer and ISN Buffer that have actually been filled by the server are returned to the user on a database reply. Software AG still recommends that you set the correct buffer sizes in the control block when coding direct calls; otherwise, unnecessary data may be transmitted.

  • Selectable message blocking and compression
    Some Entire Net-Work line drivers allow specification of message blocking or message compression. In access methods where a large physical block size is possible, blocking can improve performance during peak message load times by reducing the number of transmissions and requests made to the access method service routines. Similarly, compressing messages reduces transmission line loading and improves blocking statistics, but increases CPU consumption within Entire Net-Work.

  • All buffer sizes allowed
    Buffer size support in Entire Net-Work is comparable to that in Adabas, ensuring that all buffer sizes that are valid for Adabas can also be transmitted to remote nodes.

  • Entire Net-Work communication in heterogeneous systems
    Some line drivers support communication between systems with different hardware architectures, e.g., VTAM and TCP/IP. This allows for client/server communications to and from Entire Net-Work on Windows, OpenVMS, UNIX, and OS/400 operating systems.

  • User exit interface
    Some Entire Net-Work line drivers support an interface to an optional user exit. The user exit can encrypt or compress data before transmission and decrypt or decompress data after reception. It can decide to accept or reject a connection from a host that is not predefined to Entire Net-Work; when accepting such a connection, it has the ability to select the correct model link parameters.

  • Model Links
    The "model" link facility allows users to code one or more model links with parameter values that serve as default values for many partners, instead of coding one LINK statement for each partner. As each partner connects, new control blocks are allocated and initialized from the model link.

  • Additional operator commands
    Entire Net-Work's CTCA, FCTC, IUCV, VTAM, TCPI, TCPX , SSL, and XCF line drivers have the ability to process operator commands that are directed to a specific link or directly to the driver. Some driver and link parameters can be modified with the ALTER operator command while the driver or link is open, thus allowing dynamic reconfiguration of the network. Refer to the specific parameter description for information on possible restrictions about modifying the parameter using the ALTER command.