PQO: Overview of Parallel Query Option/204

From m204wiki
Jump to navigation Jump to search

Overview

Parallel Query Option/204 (PQO) is a Model 204 distributed processing facility that allows the sharing of data between two or more copies of Model 204.

PQO provides SOUL applications access to remote files. A single SOUL transaction can read and/or update multiple remote files.

PQO features

PQO allows a SOUL request to access data that is owned by other copies of Model 204. You can use the same SOUL statement syntax for remote files as for local files. You can horizontally partition your data. You can access data physically stored on multiple nodes in the network as if the data were contained in a single database on a single node.

In addition, PQO processing provides the following capabilities:

  • Update access to remote data, limited to one node per transaction
  • Read access to remote data in transactions that can read local data
  • Access to remote data from ad hoc requests
  • Access to remote data from application subsystems for precompiled and non-precompiled requests
  • Error handling and recovery
  • Synonyms for data files
  • Symbolic references to network location
  • File groups comprised of members from multiple copies of Model 204
  • Scattered groups (file groups that include remote files)
  • Application subsystem support for client and server applications
  • Trust definitions for application subsystems, to control remote user access by using definitions on the service node

PQO does not allow:

  • Local access to or execution of SOUL procedures stored in a remote file
  • Remote execution of updating data definition language (DDL), Model 204 commands that define or modify files or fields

Communicating between versions of PQO

PQO V6R3.0 and later cannot communicate with PQO V6R1.0 or earlier. If you attempt this, Model 204 issues the following message:

M204.2327: PQO VERSION INCOMPATIBILITY WITH REMOTE NODE: location

Location transparency

Location transparency refers to the ability to access objects without knowledge of their location. PQO offers two location transparency options for local or remote files. You can define your own names for files and for the Onlines where the files reside. Your names are called symbolic names in this guide. Using them allows you to simplify your naming conventions and saves you from having to update all your file references if PQO partners change names or shift data.

System requirements

Each system that participates in a PQO network must provide the necessary support structure. The following components are required for PQO network support:

  • z/OS, z/VM, or z/VSE operating system
  • TCP/IP or SNA Communications Server (formerly VTAM) for z/OS, z/VSE, and SNA Communications Server and Inter-User Communication Vehicle (IUCV) for z/VM
  • Model 204 base product, Version 6 Release 1.0 or later
  • The LU 6.2 communications feature of Model 204's Horizon facility, Version 6 Release 1.0 or later

PQO is incorporated directly into the core of Model 204 by default. Using PQO, application subsystem definitions and requests can refer to remote files or scattered groups. You have the opportunity to try PQO without additional expense. The number of threads is limited to two. If you want additional threads, please notify Technical Support.

Network communications

To support a PQO network, you must set up an underlying communications layer. This layer is governed by TCP/IP or the Systems Network Architecture (SNA) logical unit (LU) session type 6.2 conversation rules. PQO uses the Model 204 LU 6.2 interface provided with the Horizon facility. PQO: Defining a PQO network describes how to define this layer.

In the PQO network, a node is typically synonymous with a Model 204 Online. Communication is between two or more nodes: one client and at least one server. The client issues the request to open a remote file or group. The server responds to the client's request and provides access to a file residing on the server. If files on other nodes are involved in the request, those other nodes become servers and provide access to the requested files.

Note: In the PQO network, a node can function as a client only, as a server only, or as both a client and server.

An LU 6.2 conversation between client and server is started when a remote file is opened. PQO processing shows the basic components of PQO network processing. System A is defined as a client and System B is defined as a server in the network. A procedure that is stored on System A is executed. The procedure references a file that resides on System B.

When the OPEN FILE command is executed, the links connecting the two nodes are activated and an LU 6.2 conversation is initiated.

PQO processing

PQO ch1 1.gif

Basic setup and operation

Perform these basic steps to set up and use a PQO network.

  1. Set up the network:
    • Prepare the PQO network definitions and CCAIN parameters for each copy of Model 204 in the PQO network.
    • Prepare the SNA Communications Server definition or allocate a TCP/IP port number for each copy of Model 204 in the PQO network.

    See PQO: Defining a PQO network for details.

  2. For each network location:
    • Activate the SNA Communications Server definition, unless using TCP/IP, and bring up the Model 204 Online to support PQO communications.
    • Log in to Model 204.
    • Open a PQO communications line. Each node must open its PQO communications link (OPEN LINK).
  3. A client system initiates communications in the network. At the application level, from within a SOUL procedure:
    • Issue a command to open a remote file or files (OPEN FILE or OPEN GROUP). This starts an LU 6.2 conversation between the client and each server system that contains one of the files. It also starts a service thread (IODEV=51) on each server that contains one of the files.

      A second OPEN command for another file on a remote system involved in the first OPEN uses that existing conversation and service thread.

    • Begin a request that refers to the remote file(s).
    • The request is compiled and execution begins.
    • After a FIND statement is executed, a FOR EACH RECORD loop is entered. A buffer full of found records is shipped from the server to the client. The records are stored in the client's CCATEMP file.

      Each iteration of the FOR EACH RECORD loop gets the next record from CCATEMP until all buffered records are exhausted. A call is made to the service thread for another buffer of records.

    • If the FOR EACH RECORD loop contains an update statement, the records buffered at the client are updated, and a call is made to the server to apply the same update to the records there.
    • The request ends; other requests may follow.
    • The client closes the remote file or group (CLOSE command). When the last remote file is closed on a server, its service thread for that client is logged out automatically, and that LU 6.2 conversation ends.

PQO topics

The PQO documentation consists of the pages listed below. This list is also available as a "See also" link from each of the pages.